前言
在Redis中，hashtable 被称为字典（dictionary）,它是一个数组+链表到结构。每个键值对都会有一个dictEntry
OBJ_ENCODING_HT
这种编码夯实内部才是真正的哈希表结构，或称为字典结构，其可以实现O(1)复杂度的读写操作，因此效率很高。
在Redis内部。从OBJ_ENCODING_HT：
编码格式
redis6
ziplist
hashtable
ziplist
ziplist 压缩列表是一种紧凑编码格式，总体思想是花时间来（压缩，解压）获取节约空间，即以部分读写性能为代价，来换取极高的内存空间利用率，因此只会用于字段个素少，且字段值也比较小的场景。压缩类标内存利用率极高的原因与其连续内存的特性是分不开的。
ziplist为了节约内存开发的，他是由连续内存卡组成的顺序型数据结构，优点类似于数组。
zi plist是一个特殊编码的双向链表，他不存储指向前一个链表节点prev和执行下一个链表节点的指针next.
而是存储上一个节点长度和当前节点长度。通过牺牲部分读写性能，来换取高效的内存空间利用率，节约内存，是一种时间换空间的思想。
zplist 中 的zlentry
对比java hashMap中 Map.entry<K,V>
static class Node<K,v> implements Map.entry<K,V>{
final K key;
V value;
Node<K,V> next;
}
而 zap中是zlEntry
zipList 的存取
zlentry 属性解析
压缩列表zlentry 节点结构： 每个zlenrty由前一个节点的长度，encoding和entry-data三部分组成
前节点： （前节点占用的内存字节数）表示前1个zlentry的长度，privious_entry_lengthy有两种取值情况： 1字节和5字节。取值1字节时，表示上一个entry的长度小于254字节。虽然1字节的值能表示0到255，但是压缩列表中zlend到的取值默认时255，因此就默认使用255表示整个压缩列表的结束，其他表示疮毒的地方就不能使用255这个值了。所以上一个长度小于等于254字节时，pre_len取值为1字节，否则为5字节。记录长度的好处：暂用内存小，1或者5个字节
encoding:记录节点的context保存的类型和context的长度
zlentry 为什么要这么设计？
privious_entry_length,encoding长度都可以根据编码方式推算，正在变化的是context,而context长度记录在encoding里，因此entry的长度就知道了
entry的总长度= privious_entry_length字节数+encoding字节数+context字节数。
链表在内存中，一般是不连续的，遍历相对比较慢，而zipList可以很好的解决这个问题。如果知道当前的起始地址，因为entry是连续的，entry后一定是另一个entry,想知道下一个entry的地址，只要将当前的起始地址加上当前entry的总长度。如果还想知道下一个enrty,则继续上一步的操作。
结构
hash-max-ziplist-entries: 使用压缩列表保存时哈希集合中的最大元素个数
hash-max-ziplist-value: 使用压缩列表保存时哈希集合中单个元素的最大长度。
结论
1.哈希对象保存的键值对数量小于512个；
2.所有的键值对的键和值的字符串长度都小于等于64byte(一个英文字符一个字节，一个数字一个字节)
3. ziplist 升级到hash table 可以，hashtable变为ziplist不可用，在节省内存空间方面hashtable没有zi plist高效
