关于redis中哈希的数据结构有两个配置：hash-max-ziplist-entries和hash-max-ziplist-value。
很容易理解它应该在条目太多时转换为哈希表，因为它会花费太多的时间来获取命令。
但是为什么当值很大时它会转换为哈希表？据我所知，由于ziplist条目中有一个“length”字段，如果一个条目是1位或100位，则无关紧要，只需移动整个条目即可获得下一个条目。
为了向前和向后遍历，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时间。