Redis哈希对象的ziplist编码实现了O(1)复杂度吗

问题：Redis中哈希对象有两种编码方式，分别是ziplist、hashtable方式。哈希对象，总得体现哈希算法，使得基本操作达到O(1)的效率。hashtable编码方式使用字典，也即是Java中hashMap的方式，这个我可以理解。但是，z...

问题：Redis中哈希对象有两种编码方式，分别是ziplist、hashtable方式。哈希对象，总得体现哈希算法，使得基本操作达到O(1)的效率。hashtable编码方式使用字典，也即是Java中hashMap的方式，这个我可以理解。但是，ziplist方式所有元素都是紧挨的，它是怎么实现hash，并使得查询等操作有O(1)的时间效率的呢？

让我们从方法调用开始分析。我们都知道，获取哈希对象中某个元素的命令是“HGET”，当哈希对象的编码方式是ziplist时，它的执行过程如下：

• 首先调用ziplistFind函数，在压缩列表中查找指定键对应的节点。
• 然后调用ziplistNext函数，将指针移动到键节点旁边的值节点，最后返回值节点。

从HGET命令在ziplist编码下的执行过程可以看出，问题的关键在ziplistFind方法中。
ziplistFind方法在Redis源码的src/ziplist.c中：

从黄建宏先生的源码注释（ 源码看不懂:) ）可以看出，该方法通过遍历列表实现查找，花费O(N²)时间。由此可以得到我们的结论：

使用ziplist编码方式的哈希对象不能实现O(1)复杂度的基本操作，而是通过遍历来查找元素。sat培训班不过，ziplist编码方式只有在所有键值长度小于64字节，且哈希对象保存的键值对数量小于512个时才使用，因此，它对效率的影响并没有想象中的那么大。

当Redis哈希对象使用另一种编码——hashtable编码时它保证了基本操作O(1)复杂度吗？
是的，它提供了。hashtable编码方式使用字典（类似于Java中的HashMap）作为底层数据结构，当进行查找时，调用的是dictFind方法，它的源码如下：

可以看到，它实现了O(1)的查找复杂度。