基数树专用于stream类型，按字典序索引消息id，支持o(log n)范围查找；quicklist是list默认结构，由双向链表串联ziplist节点，平衡内存与性能；raft非redis底层结构，原生集群使用gossip协议。
Redis 中的基数树（radix tree）和 QuickList 都是特定数据类型的底层实现结构，但它们的应用场景、设计目标和使用方式完全不同。Raft 则不属于 Redis 的底层数据结构——它是分布式一致性协议，Redis 官方集群不使用 Raft，而是基于 Gossip 协议 + 自定义故障检测机制；只有部分第三方 Redis 替代方案（如 Redis Enterprise 或某些自研代理层）可能引入 Raft，但原生 Redis 与 Raft 无关。
基数树（Radix Tree）在 Redis 中的实际应用
基数树仅用于 Stream 数据类型，是 Redis 5.0 引入消息流功能的核心索引结构：
-
作用是高效索引消息 ID：Stream 中每条消息都有一个严格递增的 ID（如
1622244890123-0），基数树按字典序组织这些 ID，支持 O(log N) 时间复杂度的范围查找（XRANGE）、反向遍历（XREVRANGE）和 ID 定位（XREAD指定 ID 起始）。 -
配合 listpack 存储内容：消息体本身不存于基数树中，而是用紧凑的
listpack编码序列化后存储在独立内存块里；基数树节点只保存指向对应 listpack 块的指针和元信息。 -
不暴露给用户直接操作：你无法用命令创建或查询基数树，它完全由 Redis 内部自动维护；调用
XADD/XTRIM等命令时，Redis 会同步更新基数树索引和 listpack 数据。
QuickList 在 Redis 中的实际应用
QuickList 是 List 类型从 Redis 3.2 开始的默认底层结构，用于平衡内存占用与操作性能：
- 本质是 ziplist 的链表封装：每个节点是一个压缩列表（ziplist），多个 ziplist 通过双向链表连接；这样既保留了 ziplist 的内存紧凑性，又避免单个 ziplist 过大导致插入/删除时频繁内存重分配。
- 支持两端高效操作：LPUSH、RPUSH、LPOP、RPOP 都能快速定位到首尾 ziplist 节点执行，时间复杂度接近 O(1)；而 LRANGE、LINDEX 等遍历类命令则需跨节点跳转，最坏 O(N)。
-
可配置压缩粒度：通过
list-max-ziplist-size（单个 ziplist 最大元素数）和list-compress-depth（首尾多少个节点不压缩）控制内存与性能权衡；例如设为 1 表示只压缩中间节点，首尾保持可快速修改。
Raft 和 Redis 的关系澄清
Raft 是一种分布式共识算法，常用于 etcd、TiKV、Consul 等系统保证多副本间数据一致。但 Redis 原生设计不采用 Raft：
- Redis Cluster 使用 Gossip 协议：节点间通过周期性交换心跳信息传播拓扑变化、故障状态和槽位分配，无中心协调者，也不依赖强一致日志复制。
-
主从复制是异步+半同步可选：主节点写入后立即返回客户端，再异步发送给从节点；可通过
WAIT命令要求至少 N 个从节点确认，但这不是 Raft 的 Leader 提交逻辑。 - 若你在 Redis 场景看到 Raft，通常是外围组件：比如用 etcd 存储 Redis 配置元数据、用 Raft-based proxy 做读写分离路由、或某些云厂商托管服务在其控制平面使用 Raft 管理实例生命周期——这些都不影响 Redis 实例内部的数据结构行为。
理解这三者的边界很重要：基数树解决 Stream 的高维 ID 索引问题，QuickList 解决 List 的内存与操作效率矛盾，而 Raft 并非 Redis 的组成部分，混淆它容易导致架构设计偏差。
