Redis链表结构那些事儿，怎么用才能既省空间又高效存储

说到Redis里的链表,咱们得先搞清楚它到底是个啥玩意儿，Redis自己实现了一个叫“双向链表”的结构，你可以把它想象成一串珍珠项链，每一颗珍珠就是一个数据节点，但和普通项链不一样的是，这颗珍珠上不仅穿着下一颗珍珠的线，还穿着上一颗珍珠的线，这意味着什么呢？意味着你可以从前往后找，也可以从后往前找，非常灵活，根据《Redis设计与实现》这本书里的描述，这种结构让在链表的头部和尾部进行增加、删除操作变得特别快，速度是恒定的，不管链表有多长，都像处理一个节点一样快。

那这种链表通常用在哪儿呢？一个最经典的用法就是Redis的列表（List）数据类型，当你用LPUSH、RPUSH、LPOP、RPOP这些命令来操作一个列表时，底层可能就是用的这种链表，实现一个消息队列，生产者用LPUSH从左边塞入消息，消费者用RPOP从右边取出消息，效率非常高。

问题来了,这种“珍珠项链”式的链表虽然操作快，但它有个挺明显的缺点，不省地方”，每一颗“珍珠”（节点）除了要存放你真正想存的数据本身，还得额外拿出两个小房间，分别存放指向前一颗珍珠和指向后一颗珍珠的“地址纸条”（也就是前后节点的指针），在64位计算机系统里，这两个指针就要占去16个字节的空间，如果你存的数据本身很小，比如只是一个短短的字符串“hello”，那为了存这几个字母，额外付出的指针空间成本就显得非常高了，有点“买椟还珠”的感觉，装东西的盒子比东西本身还贵。

正因为意识到了这个空间浪费的问题,Redis在后续的版本中引入了一个更节省空间的“压缩列表”（ziplist）结构，来作为列表（List）等数据类型在特定情况下的底层实现，根据Redis官方文档的说明，压缩列表的设计目标就是为了提高内存使用效率，它不再是那种一颗颗独立的珍珠了，而是像一根长长的、紧密排列的香肠，所有数据（包括数据本身以及一些必要的控制信息）都是一个接一个地、紧凑地存储在这一大块连续的内存里，这样一来，就彻底省掉了那些昂贵的指针所占用的空间，对于存储大量小数据的情况，内存节省效果非常显著。

Redis是怎么智能地在这两种结构之间做选择的呢？它并不是固定使用某一种，而是给了使用者一个灵活配置的权利，你可以在Redis的配置文件里，针对列表（List）这类数据类型，设置一些“切换规则”，你可以设置两个阈值：

1. list-max-ziplist-entries：这个表示当列表中的元素个数超过这个数值时，就从压缩列表转换为标准的双向链表。
2. list-max-ziplist-value：这个表示当列表里任何一个元素的值的长度（比如一个字符串的长度）超过这个字节数时，也进行转换。

这背后的逻辑非常实在,就像《Redis开发与运维》这本书里提到的，压缩列表在元素少、元素内容也小的时候，优势巨大，非常省内存，它的操作（比如在中间插入或删除一个元素）时间复杂度不是恒定的，最坏情况下可能需要重新分配内存并拷贝大量数据，当数据量变大或者单个元素变长时，这种操作的代价就会很高，性能会下降，而传统的双向链表，虽然每个节点多占了点指针空间，但插入删除操作的速度是稳定且快速的。

要想让你的Redis链表既省空间又高效,关键就在于合理地配置上面提到的那两个参数，你需要根据自己实际的数据特征来找到一个平衡点，如果你的应用场景99%的情况下列表都只存放几十个短的文本标签，那你完全可以把list-max-ziplist-entries设得大一些，比如512，让Redis在绝大多数情况下都使用节省内存的压缩列表，反之，如果你的列表经常要存储几万个元素，或者经常需要存放很大的文本块或二进制数据，那么就应该设置一个较小的阈值，让Redis尽早地切换到双向链表，以保证操作的效率，避免因为一次插入操作导致整个压缩列表重构而引发的延迟尖峰。

Redis已经为我们提供了两种不同特点的“武器”：空间紧凑但修改可能慢的压缩列表（适合小规模数据），和空间开销稍大但修改速度稳定的双向链表（适合大规模或大元素数据），我们的任务就是通过配置，告诉Redis在什么“兵力规模”和“单兵装备”下该切换武器，没有一成不变的最佳配置，最佳配置永远取决于你的数据是什么样的，以及你对性能和内存的侧重程度，定期检查Redis的内存使用情况和你业务操作的响应时间，是调整这些参数、找到最佳平衡点的唯一途径。