Redis 哈希：压缩列表与哈希表，一场内存与速度的华尔兹 💃
各位观众老爷们，晚上好！欢迎来到今晚的 "Redis 奇妙夜"！我是你们的老朋友，也是你们的导游——代码界的吟游诗人，今晚咱们要聊聊 Redis 里面的哈希（Hash）数据结构，特别是它的两种编码方式：压缩列表（ziplist）和哈希表（hashtable）。
哈希，就像一个迷你版的数据库，能让你存储键值对，而且速度快的飞起。想象一下，你有个小本本，上面记录了朋友们的各种信息：姓名、电话、住址等等。这个小本本就是哈希，姓名是键（key），电话、住址是值（value）。
但是，这个小本本怎么实现呢？不同的实现方式，效率可是天差地别。这就是我们今天的主题：ziplist 和 hashtable，两种截然不同的实现，一场内存与速度的华尔兹。
第一幕：压缩列表（ziplist）—— 小而美的芭蕾舞者 🩰
首先，让我们请出第一位舞者——压缩列表（ziplist）。 压缩列表，顾名思义，就是为了压缩而生的。它就像一个紧凑的数组，元素一个挨着一个，就像沙丁鱼罐头里的沙丁鱼一样，挤得满满当当，丝毫没有浪费的空间。
1. 压缩列表的结构：一个紧凑的乐高积木
压缩列表的结构可以用乐高积木来形容，虽然简单，但却巧妙地将多个元素紧密地堆叠在一起。它主要由以下几个部分组成：
| 字段 | 类型 | 描述 |
|---|---|---|
zlbytes |
uint32_t |
整个压缩列表占用的总字节数。通过这个值，我们可以快速定位到列表的末尾，而无需遍历整个列表。 |
zltail |
uint32_t |
列表尾节点的偏移量。有了这个值，我们可以直接跳到列表的最后一个元素，这对于从后往前遍历列表非常有用。 |
zllen |
uint16_t |
列表包含的节点数量。这个值不能超过 65535 (2^16 – 1)。如果超过了这个限制，我们需要遍历整个列表才能知道元素的数量。 |
entry1...entryN |
任意类型 | 列表中的节点。每个节点都包含 prevlen (记录前一个节点的长度) 和 encoding (记录当前节点的编码方式) 两个部分。节点可以存储字符串或整数。 |
zlend |
uint8_t |
特殊值 0xFF (255)，用于标记列表的末尾。 |
举个例子，假设我们有一个压缩列表，存储了三个字符串："hello"， "world"， "redis"。 它的结构可能如下：
[zlbytes=28][zltail=21][zllen=3][entry1="hello"][entry2="world"][entry3="redis"][zlend=0xFF]2. 压缩的秘诀：变长编码
压缩列表之所以能压缩，关键在于它使用了变长编码。对于较小的整数或者较短的字符串，它会使用较少的字节来存储。就像你跟朋友聊天，如果只说一个字 "嗯"，就没必要发一大段话，对吧？
- 整数编码: 压缩列表会根据整数的大小，选择不同的编码方式。例如，如果整数小于 128，只需要一个字节就可以存储。这比传统的
int类型（通常是 4 个字节）节省了不少空间。 - 字符串编码: 字符串的长度也会影响编码方式。较短的字符串可以使用较短的编码头，从而减少存储空间。
3. 压缩列表的优点与缺点：天使与魔鬼的结合
压缩列表的优点显而易见：
- 节省内存: 这是它最大的优势。对于存储小数据量的哈希来说，压缩列表可以极大地减少内存占用。
- 缓存友好: 由于数据紧凑存储，可以提高缓存命中率，从而提升性能。
但是，压缩列表也有它的缺点：
- 修改成本高: 如果在列表的中间插入或删除元素，可能需要移动大量的元素，这会非常耗时。想象一下，你在一个拥挤的地铁里，想往中间挤进去，那简直就是一场噩梦 😫。
- 连锁更新: 由于每个节点都记录了前一个节点的长度，如果前一个节点的长度发生了变化，可能会导致后续的节点都需要更新。这种连锁更新的情况，在极端情况下会影响性能。
4. 适用场景：小而美，快如闪电
所以，压缩列表适合存储小数据量的哈希。例如，存储一个用户的少量信息，或者一个商品的简单属性。在这种情况下，压缩列表的优势可以充分发挥，而缺点可以忽略不计。
第二幕：哈希表（hashtable）—— 气吞山河的交响乐团 🎻
现在，让我们请出第二位舞者——哈希表（hashtable）。 哈希表，就像一个庞大的交响乐团，可以容纳大量的元素，并且能够快速地找到它们。
1. 哈希表的结构：一个高效的索引目录
哈希表的结构相对复杂，但它却能提供高效的查找性能。它主要由以下几个部分组成：
- 哈希函数: 哈希函数就像一个翻译器，它可以将任意的键（key）转换成一个整数，这个整数就是索引，用于定位元素在哈希表中的位置。一个好的哈希函数应该尽可能地将键均匀地分布到哈希表的各个位置，以避免冲突。
- 哈希表数组: 哈希表数组是一个数组，每个元素都是一个桶（bucket）。桶可以存储一个或多个键值对。
- 冲突解决: 当不同的键被哈希到同一个桶时，就会发生冲突。哈希表需要一种机制来解决冲突，常见的解决方法有链地址法和开放地址法。在 Redis 中，哈希表使用链地址法来解决冲突，也就是在每个桶中维护一个链表，将所有哈希到同一个桶的键值对都放在这个链表中。
2. 哈希冲突：不可避免的难题
哈希冲突是哈希表不可避免的问题。即使你使用再好的哈希函数，也无法保证所有的键都被哈希到不同的位置。就像世界上没有完全相同的两片叶子一样，总会有一些键会发生冲突。
3. 动态扩容与收缩：伸缩自如的变形金刚 🤖
为了保证哈希表的性能，当哈希表中的元素数量达到一定比例时，就需要进行扩容。扩容会增加哈希表数组的大小，从而减少冲突的概率。相反，当哈希表中的元素数量减少到一定比例时，就可以进行收缩，以节省内存。
Redis 的哈希表使用了渐进式 rehash 的策略来进行扩容和收缩。 所谓渐进式 rehash，就是将 rehash 的过程分摊到多次操作中进行，而不是一次性完成。这样做可以避免在 rehash 期间出现性能瓶颈。
4. 哈希表的优点与缺点：力与美的完美结合
哈希表的优点非常明显：
- 查找速度快: 在理想情况下，哈希表的查找时间复杂度是 O(1)，也就是说，无论哈希表中有多少个元素，都可以以常数时间找到目标元素。
- 可以存储大量数据: 哈希表可以动态扩容，因此可以存储大量的数据。
哈希表也有它的缺点：
- 占用内存多: 哈希表需要维护哈希表数组和链表，因此会占用较多的内存。
- 哈希冲突影响性能: 如果哈希冲突严重，会导致查找速度下降。
5. 适用场景：海纳百川，有容乃大
哈希表适合存储大量数据的哈希。例如，存储一个网站的所有用户信息，或者一个大型电商平台的所有商品信息。在这种情况下，哈希表的优势可以充分发挥，即使哈希冲突比较严重，也可以通过调整哈希函数或者增加哈希表的大小来提高性能。
第三幕：华尔兹的节奏：编码转换的艺术 🎨
Redis 并没有一成不变地使用某一种编码方式。它会根据哈希中存储的数据量以及数据的特性，动态地选择合适的编码方式。 这就像一位经验丰富的舞者，能够根据音乐的节奏和舞伴的特点，选择最合适的舞步。
1. 编码转换的规则：精打细算的管家
当哈希对象满足以下两个条件时，Redis 会使用压缩列表编码：
- 哈希对象保存的所有键值对的键和值的字符串长度都小于
hash-max-ziplist-value配置项的值（默认是 64 字节）。 - 哈希对象保存的键值对数量小于
hash-max-ziplist-entries配置项的值（默认是 512 个）。
如果哈希对象不满足以上两个条件，Redis 就会使用哈希表编码。
2. 编码转换的触发：灵活应变的舞者
当哈希对象使用压缩列表编码时，如果出现以下情况，Redis 就会将编码方式转换为哈希表：
- 某个键或值的字符串长度超过了
hash-max-ziplist-value配置项的值。 - 键值对的数量超过了
hash-max-ziplist-entries配置项的值。
这种动态编码转换的机制，使得 Redis 能够根据实际情况选择最合适的编码方式，从而在内存占用和性能之间取得平衡。
3. 编码配置：量身定制的礼服
你可以通过修改 Redis 的配置文件来调整 hash-max-ziplist-value 和 hash-max-ziplist-entries 这两个配置项的值，从而控制哈希对象的编码方式。 这就像为舞者量身定制礼服，可以根据舞者的身材和舞蹈的风格，选择最合适的款式和材质。
总结：内存与速度的完美平衡 ✨
好了，各位观众老爷们，今天的 "Redis 奇妙夜" 就到这里了。 我们一起探索了 Redis 哈希的两种编码方式：压缩列表和哈希表。
- 压缩列表，小而美，节省内存，适合存储小数据量的哈希。
- 哈希表，气吞山河，查找速度快，适合存储大量数据的哈希。
Redis 会根据实际情况，动态地选择合适的编码方式，从而在内存占用和性能之间取得平衡。 这种灵活应变的策略，正是 Redis 能够成为高性能 NoSQL 数据库的关键之一。
希望今天的分享能够帮助你更好地理解 Redis 哈希的编码优化，并在实际应用中发挥它的优势。 感谢大家的收看，我们下期再见！ Bye bye! 👋