大家好，今天咱们聊聊 Redis 里面的一个很有意思的现象：ziplist 和 hashtable 之间“身份切换”的故事。 就像咱们人类一样，数据在不同的场景下也需要不同的“活法”，Redis 为了极致的性能和内存效率，就搞出了这么一套灵活的编码转换机制。 开场：Redis 的“双面”数据结构 Redis 里面的数据结构，比如 Hash，List，Set，Sorted Set，表面上看起来就那么几个，但实际上，它们内部可没那么简单。为了在不同的场景下达到最佳的性能和内存占用，Redis 偷偷地给它们披上了不同的“马甲”，也就是内部对象编码。 举个例子，一个 Hash，可能一开始用的是 ziplist（压缩列表）来存储，但随着数据的膨胀，它又会“变身”成 hashtable（哈希表）。这种“变身”可不是随便发生的，它是有条件的，今天咱们就来扒一扒 Hash 在 ziplist 和 hashtable 之间切换的那些事儿。 主角登场：ziplist 和 hashtable 在深入转换条件之前，咱们先来简单认识一下今天的主角：ziplist 和 hashtable。 ziplist（压缩列 …
Redis `ziplist` 压缩列表原理：小数据集合的内存极致优化
各位观众，各位朋友，欢迎来到今天的“Redis数据结构奇妙夜”！今天我们要聊的是Redis里一个非常低调但又极其重要的角色——ziplist，也就是压缩列表。 别看它名字里带“压缩”两个字就觉得它很复杂，其实啊，它就是Redis为了节省内存，对小数据集合进行极致优化的一种数据结构。简单来说，如果你的列表或者哈希只存几个小猫小狗，Redis就懒得给你动用重量级的链表或者哈希表了，直接用ziplist伺候着，省钱！ ziplist：小身材，大智慧 想象一下，你有一个小杂物间，里面就放了几件东西。如果专门为了这几件东西搭个钢筋混凝土的房间，是不是有点浪费？ziplist就相当于这个杂物间，它把数据紧凑地排列在一起，不搞多余的指针，能省一点是一点。 ziplist的结构 ziplist本质上就是一段连续的内存空间，里面存储着一系列的节点（entry）。它的结构可以用下图来简单概括（别嫌弃，这可是纯文字版架构图）： <zlbytes> <zltail> <zllen> <entry1> <entry2> … <entryN&g …