技術乾貨分享：Redis五大數據類型詳解

關於Redis的五大數據類型，它們分別為：String、List、Hash、Set、SortSet。本文將會從它的 底層數據結構 、 常用操作命令 、一些 特點 和 實際應用 這幾個方面進行解析。對於數據結構的解析，本文只會從大的方面來解析，不會介紹詳細的代碼實現。

String

1.實現結構

String是Redis中最常用的一種數據類型，也是Redis中最簡單的一種數據類型。首先，表面上它是字符串，但其實他可以靈活的表示 字符串、整數、浮點數 3種值。Redis會自動的識別這3種值。那麼，String的底層數據機構又是怎樣的呢？由於Redis是使用c語言實現的，而c語言中沒有String這一數據類型，那麼就需要自己實現一個類似於String的 結構體 。它的名字就叫做SDS(simple dynamic string)，下面是它的代碼結構。

1 typedef struct sdshdr {
2 // buf中已經占用的字符長度
3 unsigned int len;
4 // buf中剩餘可用的字符長度
5 unsigned int free;
6 // 數據空間
7 char buf[];
8 }

如果有了解過Java集合框架類的朋友都知道，這種結構與集合中 動態數組結構 類似，那麼就會涉及到一系列的擴容判斷和操作，但這些具體的做法在這裡不深入講解。不過有一點比較重要的就是String的value值最大可以存放 512MB 的數據，所以有時候它不僅僅可以存放字符，還可以存放位元組數據。

2.實際應用

在講實際應用之前，要聲明的是Redis是基於 單線程IO多路復用 的架構實現的NoSql，意味著它的操作都是 串行化 的，所以在命令操作上不會出現線程安全問題，基於這個特性可以有很多應用。

1. 分布式鎖。 利用Redis的串行化特性，可以輕鬆的實現分布式鎖，其中用到的命令有： setnx key value , expire key time , del key ，其中第一個setnx是指在key不存在時能賦值成功，expire 來設置key的存活時間來防止程序異常而沒有及時del到key值的情況。但是程序也有可能在expire沒有執行時就已經掛掉的時候，這是可以來一個增強版 set key value NX EX time。這裡的NX就是表示if not exist，而Ex表示時間單位秒，Px代表毫秒。
2. 分布式session 。這裡僅僅是利用Redis的資料庫功能，把分布式應用的session抽取到Redis中，普通的get、set，命令即可完成。
3. 商品秒殺實現。 把需要銷售的商品提前放入Redis，通過redis的 incr 和 decr 命令安全的增加和減少庫存。
4. 限時驗證。 expire key time ，判斷exists key在簡訊驗證時，當redis中存在數據則不允許再次請求驗證發送。

List

1.實現結構

首先，List的主要存取操作有 lpush、lpop、rpush、rpop， 有點像是雙向隊列。List的實現是靈活多樣的，它分別有ziplist（壓縮鍊表）、LinkedList（雙向鍊表）兩種實現方式。

1.ziplist

如下圖所示，它是基於連續內存實現（ 類似數組 ）。當然， 它的每一個entry的大小可能不是一致的，這就需要特殊的控制手段去解決 ，所以才叫壓縮表。那麼數組有的特性它都會有，比如在lpush、lpop的時候就會有數據的搬移，時間複雜度是O(n)。所以，一般在 數據元素較少 時使用ziplist結構實現。

2.LinkedList

則與我們日常所學的雙向鍊表相差無異，同樣也保留則頭尾指針、數據長度等數據，這裡就不再詳細說明，需要了解的去讀一讀Java的LInkedList源碼也不錯。

2.實際應用

1. 消息隊列。 使用lpush，brpop兩個命令可以模擬一個消息隊列。其中 brpop key time 為阻塞式彈出，當隊列中為空時會阻塞當前操作，該操作需要添加超時參數，單位為秒。
2. 有限集合。 使用ltrim key start end操作可以獲取一個固定位置的數據，可以快速實現一個有限的集合。

Hash

1.實現結構

首先，Hash的特性我們可以想像為 Java集合中的HashMap ，一個hash中可以有多個field:value(鍵值對)。關於hash的實現同樣有 兩種情況 。一種是基於ZipList，一種是基於HashTable實現。

1.ZipList

這裡的的ZipList與List當中的ZipList其實是相差無幾的，唯一的特點就是Hash存儲的時候，它的entry數量是成對增加的，同時也是 成對存在 的，所以它的長度一定是2的整數倍。filed值放在前面，value放在後面的形式存放。當然採用ZipList操作時，它的查找刪改查的時間複雜度就會變為O（n），所以ZipList適合在數據較少的情況下使用。

2.HashTable

雖然說Hash與Java中的HashMap 功能類似 ，但在HashTable這個結構上還是有一定的不同點的。要想了解HashTable的實現，需要了解三個結構。它們分別是： dict 、 dictht 、 entry 。entry和前面list中提到的類似，下面列出前面兩個結構的定義:

 1 // 哈希表（字典）數據結構，Redis 的所有鍵值對都會存儲在這裡。其中包含兩個哈希表。
 2 typedef struct dict {
 3 // 哈希表的類型，包括哈希函數，比較函數，鍵值的內存釋放函數
 4 dictType *type;
 5 // 存儲一些額外的數據
 6 void *privdata;
 7 // 兩個哈希表
 8 dictht ht[2];
 9 // 哈希表重置下標，指定的是哈希數組的數組下標
10 int rehashidx; /* rehashing not in progress if rehashidx == -1 */
11 // 綁定到哈希表的疊代器個數
12 int iterators; /* number of iterators currently running */
13 } dict;
14 
15 typedef struct dictht { 
16 //槽位數組
17 dictEntry **table; 
18 //槽位數組長度
19 unsigned long size; 
20 //用於計算索引的掩碼,可以理解為hash函數 
21 unsigned long sizemask;
22 //真正存儲的鍵值對數量
23 unsigned long used; 
24 } dictht;

關係可以總結為下面這幅圖：

2.實際應用

1. 存放對象Object。 你可能會發現，從宏觀上來說，這種一個key , field1 : value1 ，field2 : value2 一個鍵值對應多個欄位field的格式非常適合用於描寫一個對象。所以，hash一般會用於 描述一個對象 ，但其實我們在實際中也有可能會用一個 Json格式的字符串 來描述一個對象。那麼這兩種方法都可行的情況下，會有什麼優缺點呢？利用hash描述一個對象：可以做到序列化開銷小，可以單獨修改某一個欄位而不用讀出全部數據，但是使用比較複雜。而使用json描述對象，使用簡單但需要耗費額外的序列化開銷。需要使用什麼形式，具體情況需要具體分析。
2. 結合Json描述對象的集合。 例如，在商城應用中，可以利用Hash的key來描述一個用戶的id，而field用於描述用戶的購物車列表中的一個物品的詳細信息。

Set

Set是一個不允許重複的，無順序的數據集合。值得注意的是，這裡說的無順序其實還是有一點歧義的，那麼到底是怎麼回事呢？接下來的博文就會有提到這個差異。

1.實現結構

1.IntSet。

這裡的IntSet是一種在滿足特定情況下所使用的數據結構。這種情況就是當 全部value都為整型時，redis會使用IntSet這種結構。在這個情況下它是有序的。這是為什麼呢？先從結構開始說起，為了平衡空間的性能的消耗，Redis在數據都為整型的時候使用了一種基於 動態數組 的結構體，同時在存放元素時保正元素的大小順序，這樣就可以使用 二分查找 以時間複雜度O(logn)來完成增刪改查的操作。這樣就節省了很多空間。至於增和刪操作，同樣會涉及到數組的數據搬移操作。下面為它的結構體代碼：

1 typedef struct intset {
2 // 編碼方式
3 uint32_t enconding;
4 // 集合包含的元素數量
5 uint32_t length;
6 // 保存元素的數組 
7 int8_t contents[];
8 } intset;

2.HashTable

當存在 非整型 數據的時候，Redis會 自動把IntSet轉換為HashTable 的結構存放數據，但HashTable不能轉換為IntSet。這裡的HashTable與上面Hash結構提到的HashTable沒有太大的差別。唯一的差別就在於Set存放在HashTable中只有Key值，沒有value值，所以在HashTable的Entry中， Enrty的value永遠為null。

2.實際應用

1. 記錄唯一的事物。 如ip值，身份證等。
2. 隨機用戶抽獎。 通過srandmember key 隨機返回一個set中的數據。
3. 用戶標籤。 當用戶在使用某個產品的時候，後台可能會記錄該用戶對某個東西的喜好，從而在該標籤中記錄該用戶。同時，可以利用sinter key1 key2、sunion、sdiff返回標籤中的交集、並集、差集。這樣就可以輕鬆得出用戶的共同喜好、所有喜好、非共同喜好等數據。

SortSet

SortSet是一個實現了 數據有序且唯一的鍵值對 集合。其中，Entry的鍵為string類型，值為整型或浮點型，表示權值score。其中 SortSet的順序就是通過Score的值來確定 的。

1.實現結構

SortSet的實現結構同樣有兩種，一種是ZipList結構實現，適用於較少數據的情況。另一種是 SkipList+HashTable 的形式，使用與數據較多的情況，其中 SkipList 是在 保證有序 的情況下 優化範圍查找 的時間複雜度，而 HashTable 則是 優化增刪改查 的時間複雜度。

1.ZipList

SortSet的ZipList和Hash中的數據結構類似，同樣也是存放鍵值對，但是它維護了基於Score的有序性（ 默認從小到大 ），這裡就不再贅述。

2.SkipList+HashTable

首先來說明主要的SkipList（跳表），跳表是一種基於 有序鍊表 ，通過建立 多層索引 ，以 空間換時間 的方式實現 平均查找效率為O(logn) 複雜度的一種數據結構。下面給出一個跳表的基本形式圖：

可以看到在根據數據的權值Score進行查找的時候，從最頂層的索引開始查找。當找到數據在某個範圍後，在往下一層的索引查找，然後就這樣一路縮小查找的範圍。看上去是不是有點 像二分查找 ？至於跳表的具體介紹和實現，可以參考這篇文章： 為什麼Redis要用跳表實現有序集合？

上面可以看到，基於跳表的實現的有序集合可以完成增刪改查實現O(logn)的時間複雜度，那麼有沒有更加快的方式來實現O(1)的時間複雜度呢？通常說起O(1)的時間複雜度都會想起HashTable這個數據結構。Redis就利用HashTable+SkipList的組合數據結構， HashTable來實現增刪改查的時間複雜度為O(1)的同時SkipList保證數據的有序性 ，可以方便的獲取一個範圍的數據。

至於HashTable的實現與前面談到的一致，下面用一張圖來說明兩個數據結構結合是什麼樣子的。

上圖中，每一個節點可以看成 一個跳表的節點 同時也是 HashTable中的一個節點 。

1. 在看跳表的時候，我們需要忽略hnext指針，每個節點通過雙向鍊表來保證有序性。
2. 在看HashTable的時候，可以忽略prev指針和next指針。看上去就是一個用拉鏈法解決衝突的HashTable，而hnext就是指向下一節點的指針。

這樣，當我們需要增刪改查的時候，利用HashTable的特性實現時間複雜度為1的操作，當我們需要基於權值Score進行範圍查找的時候可以通過SkipList進行時間複雜度為O(logn)的查找。

2.實際應用

1. 排行榜。 使用 zrange key start end 。根據熱度、積分、評論等可以衡量的權值Score進行排行，其中score排序為從小到大，用 ZRERANGE 實現 從大到小 排序。
2. 獲取某個權值範圍的用戶。 例如在應用中獲取積分為80到100的用戶，可以使用ZRANGEBYSCORE key 80 100 WITHSCORES來輸出score在80到100間的用戶。

end：如果你覺得本文對你有幫助的話，記得關注點贊轉發，你的支持就是我更新動力。