关于 Redis 压缩列表的疑问，有没有懂的老鸟给科普下

[mitu9527]

Redis 底层实现了压缩列表这种数据结构，并且会作为列表、哈希和有序集合的底层实现之一。

压缩列表的好处不用多说，可以省内存。

但是缺点也很明显，顺序存储结构的那些缺点它都有，另外其内部 entry 还是非固定长度的，所以其大部分操作都是 O(n) 级别的，这在列表结构还算可以，哈希表和有序集合中这明显不行。

我们平时优化都是以空间换时间，压缩列表这种以时间换空间的反向操作是不是有问题啊？感觉有些仗着内存存储速度快在瞎搞。 另外，Redis 默认都是在数据元素比较短或者数量比较少的时候才会使用压缩列表，元素短且少，这能省的内存说明就很少。如果省不了太多内存，那使用它的意义不就没了？

有没有懂的老哥给科普下压缩列表是否真的有价值，我现在感觉它的价值真的很低。

[JerryX]

我并不觉得单一的思想可以一以贯之地持续下去，反而是融合、折衷、变化这类方式更加的有效。空间换时间只是一个主要的思路，在遇到障碍的时候还是需要变通一下，比如
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
超过了就换成 dict 嘛。在我们的实际场景里，有相当多的时候是达不到这个数字吧

[mitu9527]

@JerryX 我觉得一般情况下我不会选择时间换空间，况且节省的空间很有限，但是很多操作的时间复杂度却从 O(1) 越过 O(logN)直接变成了 O(N)。有机会我去试试把这些参数都调成 0 或者 1 这样的值，尽可能不用压缩列表和整数集合，测试一下性能和内存情况，说不定会有收获。

[JerryX]

@mitu9527 不过……换到设计者的思路去想一想，既要满足多种场景，还要做到快速，所以通过配置化的形式，把选择权交给了使用者，改改配置就可以让中间件按照自己的预期去运行。大概，这才是作为一个设计者高明的地方吧。
当然可以去尝试，不过我相信网上已经有人去做压测了(^_^)

[documentzhangx66]

1.题主你说対了一半，那就是这功能明显就是拿时间来换空间的。

2.但有一点你错误了，就是你觉得这功能没价值。

世界千奇百怪，你很难想象出其他的 Redis 用户，会有多奇葩的业务场景。

我举个例子，机械硬盘慢吧？但有些人就是不买固态硬盘，并且为了解决机械硬盘慢的问题，他宁愿去买阵列卡。

所以，我觉得，对于这种问题，更好的选择是：功能都做上去，谁要用谁开。楼主你内存大，你要高性能，那你就别开这个功能。

[LeegoYih]

好消息，新版本已经弃用 ZIPLIST 了

#define OBJ_ENCODING_ZIPLIST 5 /* No longer used: old list/hash/zset encoding. */

https://github.com/redis/redis/blob/6686c6d774fcf71fffbaeff798c997ab3eff80de/src/server.h#L840

[akira]

平衡 平衡 还是 平衡 。。空间和时间本来就没有绝对的好坏的，都是要看实际场景来决定如何使用

[mitu9527]

@LeegoYih 赶上好时候了，也不用在纠结了，以后也用不了了。

[Juszoe]

新版本引入的 quicklist 和 listpack 取代了 ziplist ，但本质上 quicklist=双向链表+ziplist ，listpack 也只是把 ziplist 简单修改了一下。解决的是连锁更新的问题。
假设能省 10%内存，规模上去了，就是有价值的。不符合你的业务场景，配置关掉这功能就行了。