《閑扯Redis四》List數據類型底層編碼轉換
一、前言
Redis 提供了5種數據類型：String（字元串）、Hash（哈希）、List（列表）、Set（集合）、Zset（有序集合），理解每種數據類型的特點對於redis的開發和運維非常重要。
Redis 中的 list 是我們經常使用到的一種數據類型，根據使用方式的不同，可以應用到很多場景中。
二、編碼轉換
上節《閑扯Redis三》Redis五種數據類型之List型 中說道，List類型有兩種實現方式：
1、使用壓縮列表（ziplist）實現的列表對象
2、使用雙端鏈表（linkedlist）實現的列表對象
並且，留下了一個疑問？Redis列表什麼時候會使用 ziplist 編碼，什麼時候又會使用 linkedlist 編碼呢？
參見了《Redis設計與實現》，得出了一個結論： ziplist 與 linkedlist 之間存在著一種編碼轉換機制，當列表對象可以同時滿足下列兩個條件時，列表對象採用ziplist編碼，否則採用linkedlist編碼
（1）列表對象保存的所有字元串元素的長度都小於64位元組；
（2）列表元素保存的元素數量小於512個；
注意 ：以上兩個條件的上限值可以在配置文件中修改 list-max-ziplist-value 選項和 list-max-ziplist-entries 選項，另外對於使用 ziplist 編碼的列表對象，當以上兩個條件中任何一個不能滿足時，對象的編碼轉換操作就會執行，原本保存在壓縮列表裡面的所有列表元素都會被轉移並保存到雙端鏈表裡面，對象的編碼也從 ziplist 變為 linkedlist 。
三、操作驗證
書中是這樣說的，但是還是要自己操作驗證一下的，go！
咦,什麼鬼，不是說 ziplist 和 linkedlist ，還有編碼轉換嗎，咋一個都不是，這個 quicklist 是什麼結構？看到這大家可能有一點懵逼，細品之後甚至想要動手：七哥，你TM是不是在忽悠我？
嗯，這個不要急，聽我繼續嗶嗶（ 假裝冷靜 ）
先來看一下操作的redis的版本：
./redis-server --version
版本顯示：
再看一下，黃建宏老師《Redis設計與實現》第二版中對應的redis版本：3.0，查閱資料發現 redis 在 3.2 版本的時候，考慮到redis的空間存儲效率和時間效率，引入了quicklist（快速列表）作為 list 的底層實現，原來是這樣啊！
這就能說的通了，哈哈哈，下節咱們就來看看這個 quicklist 究竟是個什麼啥，前面針對 3.0 版本的分析，看都看了，還能怎麼辦呢，權當做個了解了！
四、要點總結
（1）（Redis 3.2 版本前）列表對象底層實現的方式，壓縮列表（ziplist）與雙端鏈表（linkedlist）存在轉換
（2）（Redis 3.2 版本前）同時滿足兩個條件：列表對象保存的所有字元串元素的長度都小於64位元組；列表元素保存的元素數量小於512個；列表對象採用 ziplist 編碼，否則採用 linkedlist 編碼
（3）（Redis 3.2 版本）考慮到 Redis 的空間存儲效率和時間效率，引入了 quicklist（快速列表）作為 list 的底層實現
下節繼續…
