当 key 或 value 很大时，为什么 redis hash 从 ziplist 转换为 hashtable？答案

【问题标题】：Why redis hash convert from ziplist to hashtable when key or value is large?当 key 或 value 很大时，为什么 redis hash 从 ziplist 转换为 hashtable？
【发布时间】：2017-12-19 22:34:44
【问题描述】：

redis中hash的数据结构有两个配置：hash-max-ziplist-entries和hash-max-ziplist-value。

很容易理解，当条目太多时应该转换为哈希表，因为get命令会花费太多时间。

但是为什么当值很大时它会转换为哈希表？据我了解，由于 ziplist 的条目中有一个“长度”字段，因此一个条目是 1 位还是 100 位无关紧要，只需移动整个条目即可获得下一个。

【问题讨论】：

标签： redis

【解决方案1】：

为了向前和向后遍历，doubly linked list 必须为每个条目保存两个指针（即 64 位机器上的 16 个字节）。如果入口数据很小，比如 8 个字节，就会非常内存效率低下：数据只有 8 个字节，而额外的指针占用 16 个字节。

为了解决这个问题，ziplist 使用两个variable length encoded 数字代替两个指针，并将所有条目保存在连续内存中。在这种情况下，如果所有条目的值都小于 64 字节，那么这两个 variable length encoded 数字只需要 2 个字节（如果我错了，请纠正我）。这是非常内存效率的。但是，如果入口数据非常大，比如 1024 字节，则此技巧不会节省太多内存，因为入口数据成本更高。

另一方面，由于ziplist 以紧凑的方式将所有条目保存在连续内存中，它必须为几乎每个写入操作重新分配内存。这非常 CPU 效率低下。还编码和解码那些variable length encoded 数字成本CPU。

所以如果入口数据/值很小，可以使用ziplist来实现内存效率。但是，如果数据很大，您将无法获得太多收益，同时会花费您大量的 CPU 时间。

【讨论】：