關於Redis的五大數據類型，它們分別為：String、List、Hash、Set、SortSet。本文將會從它的底層數據結構、常用操作命令、一些特點和實際應用這幾個方面進行解析。對於數據結構的解析，本文只會從大的方面來解析，不會介紹詳細的代碼實現。 String 1.實現結構 String是Red ...
關於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，意味著它的操作都是串列化的，所以在命令操作上不會出現線程安全問題，基於這個特性可以有很多應用。
- 分散式鎖。利用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代表毫秒。
- 分散式session。這裡僅僅是利用Redis的資料庫功能，把分散式應用的session抽取到Redis中，普通的get、set，命令即可完成。
- 商品秒殺實現。把需要銷售的商品提前放入Redis，通過redis的incr和decr命令安全的增加和減少庫存。
- 限時驗證。 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.實際應用
- 消息隊列。使用lpush，brpop兩個命令可以模擬一個消息隊列。其中brpop key time為阻塞式彈出，當隊列中為空時會阻塞當前操作，該操作需要添加超時參數，單位為秒。
- 有限集合。使用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.實際應用
- 存放對象Object。你可能會發現，從巨集觀上來說，這種一個key , field1 : value1 ，field2 : value2 一個鍵值對應多個欄位field的格式非常適合用於描寫一個對象。所以，hash一般會用於描述一個對象，但其實我們在實際中也有可能會用一個Json格式的字元串來描述一個對象。那麼這兩種方法都可行的情況下，會有什麼優缺點呢？利用hash描述一個對象：可以做到序列化開銷小，可以單獨修改某一個欄位而不用讀出全部數據，但是使用比較複雜。而使用json描述對象，使用簡單但需要耗費額外的序列化開銷。需要使用什麼形式，具體情況需要具體分析。
- 結合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.實際應用
- 記錄唯一的事物。如ip值，身份證等。
- 隨機用戶抽獎。通過srandmember key 隨機返回一個set中的數據。
- 用戶標簽。當用戶在使用某個產品的時候，後臺可能會記錄該用戶對某個東西的喜好，從而在該標簽中記錄該用戶。同時，可以利用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中的一個節點。
- 在看跳錶的時候，我們需要忽略hnext指針，每個節點通過雙向鏈表來保證有序性。
- 在看HashTable的時候，可以忽略prev指針和next指針。看上去就是一個用拉鏈法解決衝突的HashTable，而hnext就是指向下一節點的指針。
這樣，當我們需要增刪改查的時候，利用HashTable的特性實現時間複雜度為1的操作，當我們需要基於權值Score進行範圍查找的時候可以通過SkipList進行時間複雜度為O(logn)的查找。
2.實際應用
- 排行榜。使用zrange key start end。根據熱度、積分、評論等可以衡量的權值Score進行排行，其中score排序為從小到大，用ZRERANGE實現從大到小排序。
- 獲取某個權值範圍的用戶。例如在應用中獲取積分為80到100的用戶，可以使用ZRANGEBYSCORE key 80 100 WITHSCORES來輸出score在80到100間的用戶。
總結
太多東西記不住？來張思維導圖幫你記憶一下。
