在實際開發，Redis使用會頻繁，那麼在使用過程中我們該如何正確抉擇資料型別呢？哪些場景下適用哪些資料類型。而且在面試中也很常被面試官問到Redis資料結構方面的問題：
當我們分析了解Redis資料結構，可以為了我們在使用Redis的時候，正確抉擇資料型別使用，提升系統效能。 【相關推薦：Redis影片教學】
Redis底層資料結構Redis 是一個記憶體鍵值key-value 資料庫，且鍵值對資料保存在記憶體中，因此Redis基於記憶體的資料操作，其效率高，速度快；
其中，Key是String類型，Redis 支援的value 類型包括了String、List 、 Hash 、 Set 、 Sorted Set 、BitMap等。 Redis 能夠之所以能夠廣泛地適用眾多的業務場景，基於其多樣化類型的value。
而Redis的Value的資料型別是基於為Redis自訂的物件系統redisObject實現的，
typedef struct redisObject{
//类型
unsigned type:4;
//编码
unsigned encoding:4;
//指向底层实现数据结构的指针
void *ptr;
…..
}redisObject除了記錄實際數據，還需要額外的內存空間記錄數據長度、空間使用等元數據信息，其中包含了8 字節的元數據和一個8 位元組指針，指針指向具體資料型別的實際資料所在位置：
#其中，指標指向的就是基於 Redis的底層資料結構儲存資料的位置，Redis的底層資料結構：SDS，雙向鍊錶、跳表，雜湊表，壓縮列表、整數集合實現的。
那麼Redis底層資料結構是怎麼實現的呢？
我們先來看看Redis比較簡單的SDS,雙向鍊錶，整數集合。
SDS、雙向鍊錶和整數集合SDS，使用len欄位記錄已使用的位元組數，將取得字串長度複雜度降低為O(1)，而且SDS是惰性釋放空間的，你free了空間，系統把資料記錄下來下次想用時候可直接使用。不用新申請空間。 
整數集合，在記憶體中分配一塊位址連續的空間，資料元素會挨著存放，不需要額外指標帶來空間開銷，其特點為記憶體緊湊節省記憶體空間，查詢複雜度為O(1)效率高，其他操作複雜度為O(N)；
雙向鍊錶 ， 在記憶體上可以為非連續、非順序空間，透過額外的指標開銷前驅/後驅指標串聯元素之間的順序。
其特性為節插入/更新資料複雜度為O(1)效率高，查詢複雜度為O(N)；
Hash哈希表哈希表，其實類似是數組，數組的每個元素稱為一個哈希桶，每個哈希桶中保存了鍵值對數據，且哈希桶中的元素使用dictEntry結構，
#因此，雜湊桶元素保存的並不是鍵值對值本身，而是指向具體值的指針，所以在儲存每個鍵值對的時候會額外空間開銷，至少有增加24個字節，特別是Value為String的鍵值對，每一個鍵值對就需要額外開銷24個位元組空間。當保存資料小，額外開銷比資料還大時，這時為了節省空間，考慮換資料結構。
那來看看全域雜湊表全圖：
雖然雜湊表操作很快，但Redis資料變大後，就會出現一個潛在的風險：哈希表的衝突問題和rehash開銷問題，這可以解釋為什麼哈希表操作變慢了？
當到哈希表中寫入更多資料時，哈希衝突是不可避免的問題， Redis 解決哈希衝突的方式，就是鍊式哈希 ，同一個哈希桶中的多個元素用一個鍊錶來保存，它們之間依次用指針連接，如圖所示：
過程怎麼樣執行的呢？
Rehash為了使#rehash 操作更有效率，使用兩個全域哈希表：哈希表1和哈希表2，具體如下：
但由於表1和表2在重新映射複製時資料大，如果一次把哈希表1 中的資料都遷移完，會造成Redis
Redis 採用了漸進式
rehash
。
在理解完Hash雜湊表相關知識點後，看看不常見的壓縮清單和跳表。
壓縮清單與跳表壓縮清單
，在陣列基礎上，在壓縮清單在表頭有三個欄位zlbytes、zltail 和zllen，分別表示列表長度、列表尾的偏移量和列表中的entry 個數；壓縮列表在表尾還有一個zlend，表示列表結束。| 優點： | 記憶體緊湊節省記憶體空間，記憶體中分配一塊位址連續的空間，資料元素會挨著存放，不需要額外指標帶來空間開銷；找出定位第一個元素和最後一個元素，可以透過表頭三個欄位的長度直接定位，複雜度是O(1)。|
|---|---|
| 例如查詢33 | |
| 綜上所述，可以得知底層資料結構的時間複雜度： | |
| 資料結構類型 | ##時間複雜度|
| 雜湊表 | O(1) |
| 整數陣列 | O(N) |
Redis自訂的物件系統類型即為Redis的Value的資料類型，Redis的資料類型是基於底層資料結構實現的，那資料型態有哪些呢？
String、List、Hash、Sorted Set 、Set比較常見的類型，其與底層資料結構對應關係如下：
| 資料類型 | #資料結構 |
|---|---|
| String | SDS(簡單動態字串) |
| List | #雙向鍊錶 壓縮清單 |
| Hash | 壓縮清單 雜湊表 |
| Sorted Set | 壓縮清單 跳表 |
| #Set | 哈希表 整數陣列 |
資料型態對應特性跟其實現的底層資料結構差不多，性質也是一樣的,且
String，基於SDS實現，適用於簡單key-value儲存、setnx key value實作分散式鎖定、計數器(原子性)、分散式全域唯一ID。
List， 按照元素進入List 的順序進行排序的，遵循FIFO(先進先出)規則，一般使用在 排序統計以及簡單的訊息佇列。
Hash， 是字串key和字串value之間的映射，十分適合用來表示一個物件訊息，特點添加和刪除操作複雜度都是O(1)。
Set，是String 類型元素的無序集合，集合成員是唯一的，這表示集合中不能出現重複的資料。基於哈希表實現的，所以添加，刪除，查找的複雜度都是 O(1)。
Sorted Set， 是Set的類型的升級， 不同的是每個元素都會關聯一個 double 類型的分數，透過分數排序，可以範圍查詢。
那我們再來看看這些資料類型，Redis Geo、HyperLogLog、BitMap？
Redis Geo， 將地球看為近似為球體，基於GeoHash 將二維的經緯度轉換成字串，來實現位置的分割跟指定距離的查詢。特點一般使用在跟位置有關的應用。
HyperLogLog， 是一種機率資料結構，它使用機率演算法來統計集合的近似基數 ， 錯誤率大概在0.81%。當集合元素數量非常多時，它計算基數所需的空間總是固定的，而且還很小，適合使用做 UV 統計。
BitMap ，用一個位元位元來映射某個元素的狀態， 只有0 和1 兩種狀態，非常典型的二值狀態，且其本身是用String 類型作為底層資料結構實現的一種統計二值狀態的資料類型 ，優勢大量節省記憶體空間，可是使用在二值統計場景。
在理解上述知識後，我們接下來討論一下根據哪些策略選擇相對應的應用場景下的Redis資料類型？
Redis資料類型策略#在實際開發應用程式中，Redis可以適用於眾多的業務場景，但我們需要怎麼選擇資料類型儲存呢？
主要依據就是時間/空間複雜度，在實際的開發中可以考慮以下幾個點：
#當資料量比較大，資料本身比較小，使用String就會使用額外的空間大大增加，因為使用雜湊表儲存鍵值對，使用dictEntry 結構保存，會導致保存每個鍵值對時額外保存dictEntry的三個指標的開銷，這樣就會導致資料本身小於額外空間開銷，最終會導致儲存空間資料大小遠大於原本資料儲存大小。
可以使用基於整數陣列和壓縮列表實作了List、Hash 和Sorted Set ，因為整數數組和壓縮列表在記憶體中都是分配一塊位址連續的空間，然後把集合中的元素一個接一個地放在這塊空間內，非常緊湊，不用再透過額外的指針把元素串接起來，這就避免了額外指針帶來的空間開銷。而且採用集合類型時，一個 key 就對應一個集合的數據，能保存的數據多了很多，但也只用了一個 dictEntry，這樣就節省了記憶體。
Redis集合類型統計模式常見的有：
Set;Redis中List 和Sorted Set是有序集合，List是依照元素進入 List 的順序進行排序的，Sorted Set 可以依照元素的權重來排序；Bitmap 本身是用String 類型作為底層資料結構實現的一種統計二值狀態的資料類型， Bitmap透過BITOP 按位元與、或、異或的操作後使用BITCOUNT 統計1 的個數。 HyperLogLogLog 是一種用於統計基數的資料集合類型，統計結果是有一定誤差的，標準誤算率是0.81% 。需要精確統計結果的話，用 Set 或 Hash 類型。 
Set類型，適用統計使用者/好友/追蹤/粉絲/有興趣的人集合聚合操作，例如
#Redis中List#和Sorted Set是有序集合，使用應對集合元素排序需求，例如
#Bitmap二值狀態統計，適用資料量大，且可以使用二值狀態表示的統計，例如：
HyperLogLogLog 是一種用於統計基數的資料集合類型，統計一個集合中不重複的元素個數，例如
Redis中List 和Sorted Set是有序集合支援範圍查詢，但是Hash是不支援範圍查詢的
訊息佇列，使用Redis作為訊息佇列的實現，要訊息的基本要求訊息保序、處理重複的訊息和保證訊息可靠性，方案有如下：
| 基於List | 基於Strems | |
|---|---|---|
| 訊息保序 | 使用LPUSH/RPOP
|
使用XADD/XREAD
|
| 阻塞讀取 | #使用BRPOP
|
使用XREAD block
|
| 重複訊息處理 | #生產者自行實作全域唯一ID | Streams自動產生全域唯一ID |
| 訊息可靠性 | 使用BRPOPLPUSH
|
使用PENDING List自動留存訊息 |
適用場景訊息總量小
以上是詳解Redis中的資料結構的詳細內容。更多資訊請關注PHP中文網其他相關文章！
