關于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排序為從小到大，用ZREVRANGE實作從大到小排序，
2. 獲取某個權值范圍的用戶，例如在應用中獲取積分為80到100的用戶，可以使用ZRANGEBYSCORE key 80 100 WITHSCORES來輸出score在80到100間的用戶，

總結

太多東西記不住？來張思維導圖幫你記憶一下，

標籤：NoSQL

上一篇：MYSQL資料庫優化（一）

下一篇：Redis自動化安裝以及集群實作