Redis 不使用 B+ Tree 作为存储数据结构
ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花
Redis 不使用 B+ Tree 作为存储数据结构，核心原因是 B+ Tree 的设计初衷与 Redis 的核心定位、使用场景完全不匹配，Redis 更侧重内存中的高效读写、低延迟操作，而 B+ Tree 是为优化磁盘 IO 设计的结构，二者适配场景存在本质差异，具体原因如下：
- 设计目标与场景适配性不符：B+ Tree 是为磁盘存储场景设计的平衡多路查找树，其核心优势是通过“非叶子节点仅存索引、叶子节点链表连接”的结构，减少磁盘 IO 次数，适配数据库（如 MySQL）等需要频繁进行磁盘读写、大范围数据存储的场景。而 Redis 是内存优先的键值数据库，数据主要存储在内存中，无需考虑磁盘 IO 的瓶颈，B+ Tree 针对磁盘优化的核心优势在 Redis 中完全无法发挥，反而会因冗余结构增加内存开销。
- 操作效率与性能需求不匹配：B+ Tree 为维持自身平衡，在插入、删除数据时需要执行复杂的节点分裂、合并操作，这些操作会增加计算开销，影响操作速度。而 Redis 的核心需求是高并发、低延迟，要求读写操作尽可能高效，其选择的存储结构（如哈希表、跳表、压缩列表等）无需复杂的平衡调整，插入、删除、查询的效率更契合 Redis 的性能诉求——例如跳表实现简单，无需旋转、分裂操作，平均查询、插入复杂度均为 O(logN)，且并发环境下更易优化。
- 数据结构灵活性不足：B+ Tree 更适合单一的有序存储场景，难以适配 Redis 多样化的核心数据结构（字符串、哈希、列表、集合、有序集合）。Redis 针对不同数据类型的特性，采用了更灵活的复合结构：例如有序集合（Zset）在数据量较小时使用压缩列表节省内存，数据量较大时使用“跳表+哈希表”的组合，既通过哈希表实现 O(1) 单点查询，又通过跳表实现高效的范围查询，这种灵活性是 B+ Tree 无法提供的。
- 内存利用率较低：B+ Tree 的节点需要存储索引、指针等额外信息，且为保证平衡会存在一定的空间冗余，在内存存储场景中，这种结构会浪费宝贵的内存资源。而 Redis 选用的结构（如压缩列表、listpack）采用连续内存存储，结构紧凑，能最大限度节省内存；哈希表、跳表也无需冗余的平衡结构，内存利用率更高，更适配 Redis 内存存储的核心定位。
补充说明：Redis 并非完全不涉及磁盘操作（如持久化），但即便在持久化场景（RDB、AOF）中，其核心存储依赖的仍是内存中的哈希表、跳表等结构，B+ Tree 因自身特性，始终无法适配 Redis 对高效、灵活、省内存的核心需求。
Redis 核心存储结构与 B+ Tree 操作效率细节对比
为更直观呈现二者差异，以下针对核心操作（查询、插入、删除），结合 Redis 主要存储结构（哈希表、跳表，覆盖高频场景）与 B+ Tree 进行细节对比，明确效率差异及底层原因：
单点查询（按键查找） | 哈希表：平均时间复杂度 O(1)，最坏 O(n)（哈希冲突极端情况），无额外平衡操作，直接通过哈希计算定位数据，内存中直接访问，延迟极低；跳表：O(logN)，通过层级索引快速定位，无需遍历全量数据。 | 时间复杂度 O(logN)，需从根节点逐层向下遍历索引，即使内存中存储，也需经过多轮指针跳转，且节点存储额外索引信息，访问效率低于哈希表。 | Redis 哈希表单点查询效率远超 B+ Tree，跳表略优于 B+ Tree（无节点跳转冗余），均无需复杂计算开销。 |
范围查询（如有序集合排序、区间筛选） | 跳表：O(logN + k)（k 为查询范围内的数据量），通过层级索引定位区间起始位置，后续可顺序遍历，无需回溯；哈希表不支持有序范围查询，需配合其他结构（如跳表）实现。 | O(logN + k)，通过叶子节点的链表连接实现范围遍历，但需先从根节点遍历到区间起始叶子节点，且节点指针跳转较多，遍历效率低于跳表。 | 二者时间复杂度一致，但 Redis 跳表遍历更简洁（无冗余索引跳转），延迟更低；B+ Tree 需额外处理节点间的指针关联，效率略低。 |
插入操作 | 哈希表：平均 O(1)，仅需计算哈希值、插入对应位置，哈希冲突时采用链地址法，无需调整结构；跳表：O(logN)，随机生成节点层级，插入时仅需修改对应层级的指针，无需分裂、合并节点。 | O(logN)，插入时需从根节点向下查找插入位置，若节点满则需执行分裂操作（可能连锁分裂），维持树的平衡，计算开销大，操作延迟高。 | Redis 插入操作无平衡调整开销，操作速度远快于 B+ Tree；B+ Tree 的节点分裂的操作会显著增加插入延迟，不适合高并发插入场景。 |
删除操作 | 哈希表：平均 O(1)，找到对应哈希位置后直接删除，冲突链表仅需调整指针；跳表：O(logN)，找到节点后修改对应层级指针，无需合并节点，仅极端情况下清理空层级。 | O(logN)，删除节点后需检查节点是否为空，若为空则需执行合并操作（可能连锁合并），维持树的平衡，操作逻辑复杂，延迟较高。 | 与插入操作类似，Redis 删除操作无平衡调整开销，效率高于 B+ Tree；B+ Tree 的节点合并操作会增加删除延迟，且逻辑更复杂。 |
补充说明：Redis 针对不同数据量还会动态切换存储结构（如小数据量用压缩列表、listpack），进一步优化内存利用率和操作效率，而 B+ Tree 结构固定，无法根据数据量动态适配，进一步拉大了与 Redis 存储结构的效率差距。
ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花
Redis 作为高性能键值数据库，核心在于丰富的数据结构。本专栏聚焦String、Hash、List、Set、ZSet、Bitmap、HyperLogLog 等常用类型，从底层原理、使用场景到实战示例，清晰讲解每种结构的优缺点与最佳实践。帮你快速掌握如何用对数据结构，提升缓存、限流、排行榜、消息队列等业务场景的开发效率，写出更稳定、高效的 Redis 应用。
