共计 1309 个字符，预计需要花费 4 分钟才能阅读完成。
一、前言
Redis 提供了 5 种数据类型：String（字符串）、Hash（哈希）、List（列表）、Set（汇合）、Zset（有序汇合），了解每种数据类型的特点对于 redis 的开发和运维十分重要。
<p align=”right”> 原文解析 </p>
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 的底层实现
下节持续 …
