《閒扯Redis四》List數據類型底層編碼轉換

---

1、前言

Redis 提供了5種數據類型：String（字符串）、Hash（哈希）、List（列表）、Set（集合）、Zset（有序集合），理解每種數據類型的特色對於redis的開發和運維很是重要。

原文解析

Redis 中的 list 是咱們常常使用到的一種數據類型，根據使用方式的不一樣，能夠應用到不少場景中。

2、編碼轉換

 上節**《閒扯Redis三》Redis五種數據類型之List型** 中說道，List類型有兩種實現方式：

一、使用壓縮列表（ziplist）實現的列表對象 二、使用雙端鏈表（linkedlist）實現的列表對象

 而且，留下了一個疑問？Redis列表何時會使用 ziplist 編碼，何時又會使用 linkedlist 編碼呢？

參見了《Redis設計與實現》，得出了一個結論： ziplist 與 linkedlist 之間存在着一種編碼轉換機制，當列表對象能夠同時知足下列兩個條件時，列表對象採用ziplist編碼，不然採用linkedlist編碼

（1）列表對象保存的全部字符串元素的長度都小於64字節；

（2）列表元素保存的元素數量小於512個；

注意 ：以上兩個條件的上限值能夠在配置文件中修改 list-max-ziplist-value 選項和 list-max-ziplist-entries 選項，另外對於使用 ziplist 編碼的列表對象，當以上兩個條件中任何一個不能知足時，對象的編碼轉換操做就會執行，本來保存在壓縮列表裏面的全部列表元素都會被轉移並保存到雙端鏈表裏面，對象的編碼也從 ziplist 變爲 linkedlist 。

3、操做驗證

 書中是這樣說的，可是仍是要本身操做驗證一下的，go！

 咦,什麼鬼，不是說 ziplist 和 linkedlist ，還有編碼轉換嗎，咋一個都不是，這個 quicklist 是什麼結構？看到這你們可能有一點懵逼，細品以後甚至想要動手：七哥，你TM是否是在忽悠我？

 嗯，這個不要急，聽我繼續嗶嗶（ 僞裝冷靜 ）

 先來看一下操做的redis的版本：

./redis-server --version
複製代碼

 版本顯示：

再看一下，黃建宏老師**《Redis設計與實現》**第二版中對應的redis版本：3.0，查閱資料發現 redis 在 3.2 版本的時候，考慮到redis的空間存儲效率和時間效率，引入了quicklist（快速列表）做爲 list 的底層實現，原來是這樣啊！

這就能說的通了，哈哈哈，下節我們就來看看這個 quicklist 到底是個什麼啥，前面針對 3.0 版本的分析，看都看了，還能怎麼辦呢，權當作個瞭解了！

4、要點總結

（1）（Redis 3.2 版本前）列表對象底層實現的方式，壓縮列表（ziplist）與雙端鏈表（linkedlist）存在轉換

（2）（Redis 3.2 版本前）同時知足兩個條件：列表對象保存的全部字符串元素的長度都小於64字節；列表元素保存的元素數量小於512個；列表對象採用 ziplist 編碼，不然採用 linkedlist 編碼

（3）（Redis 3.2 版本）考慮到 Redis 的空間存儲效率和時間效率，引入了 quicklist（快速列表）做爲 list 的底層實現

下節繼續...