Redis 基础数据结构（String/Hash/List/Set/ZSet）

• 五种数据结构的命令与典型使用场景
• 每种结构对应的底层编码（SDS、listpack、hashtable、skiplist、intset、quicklist）
• 编码随数据规模动态切换的机制

String 底层用 SDS（简单动态字符串），支持 bit 操作、数值自增，是最通用的结构；Hash 底层是小数据时用 listpack（ziplist），数据量大后切换为 hashtable（字典）；List 底层用 quicklist（双向链表 + listpack 节点）或 listpack；Set 底层在小整数集合时用 intset，否则用 hashtable；ZSet 底层用 ziplist/listpack 存储有序小集合，数据量大后切换为 skiplist + hashtable 组合。Redis 通过对象编码（encoding）字段动态选择最小内存但功能足够的底层实现，并在数据规模跨过阈值时原地格式转换。

多种编码是为了在小数据量时节省内存（紧凑连续存储、无指针），在数据量增大时用哈希表/跳表保证 O(1)/O(logN) 的访问性能，体现"内存换性能"与"性能换内存"的权衡。

• 各编码类型对应的底层结构
• 切换阈值与触发条件
• OBJECT 命令的使用

int 表示字符串值为整数可直接用 long 存储；embstr 表示不足 44 字节的短字符串，与 redisObject 头一次性分配内存；raw 表示长字符串用 SDS 分配；listpack 是紧凑的连续内存列表；hashtable 是基于拉链（链地址）法的字典；skiplist 关联哈希表用于 ZSet；quicklist 是 listpack 节点组成的双向链表。当存储元素数量或单个元素长度超过 hash-max-listpack-entries、zset-max-listpack-entries 等配置阈值时，编码会从 listpack 升级为 hashtable/skiplist。用 OBJECT ENCODING key 可查看当前编码，OBJECT HELP 查看命令用法。

编码切换是"阈值触发、不可逆升级"（listpack→hashtable/skiplist 一般不会降回），目的是在数据量小时用紧凑布局降低内存，数据量大时保证查询性能。

• ziplist 的 prevlen 字段与连锁更新触发条件
• 连锁更新的最坏时间复杂度
• listpack 的设计如何规避连锁更新

ziplist 中每个节点通过 prevlen 字段记录前一个节点的字节长度，当 prevlen 小于 254 字节时用 1 字节编码，否则用 5 字节。若插入或修改一个节点使其长度从 253 变为 254，会导致后续节点 prevlen 字段从 1 字节扩为 5 字节，进而使该节点自身长度增加，又可能触发下一个节点扩容，形成连锁效应，最坏情况需 O(N²) 次操作。listpack 不再用 prevlen 记录前驱长度，而是每个条目记录"本条目的总长度"（entry-len），并单独记录整个 listpack 的总字节数，从而通过"从尾部向前用 entry-len 回溯"实现反向遍历，彻底避免连锁更新，因为修改一个条目不会影响其他条目的长度字段。

连锁更新的本质是"前驱长度耦合进后继布局"，listpack 把长度信息从"影响后继"改为"记录自身"，切断耦合，从而以固定开销完成遍历，消除了 O(N²) 的退化风险。

• listpack 相对 ziplist 的改进
• 遍历安全性（无连锁更新）
• Redis 7 编码迁移的配置

Redis 7 将 Hash、ZSet、List 等小对象编码从 ziplist 全面迁移到 listpack，因为 listpack 更紧凑（省去 prevlen 的连锁更新开销）、遍历更安全（无 O(N²) 退化）、且实现更简单统一。内存布局上 ziplist 由 prevlen+encoding+data 组成，通过前驱长度前后向遍历；listpack 由总长度+条目组成，每个条目含自身长度标记，通过记录总长度与条目自身长度实现反向回溯。两者都适合小数据量，但 listpack 修改更安全、性能更稳定。

listpack 解决了 ziplist 在极端情况下（大量 253-254 字节边界节点）的连锁更新性能抖动，同时内存占用更低，因此 Redis 7 将其作为通用的小对象紧凑编码。

• Streams 作为日志型消息队列的数据模型
• XADD 追加消息、XREAD 独立读取、XREADGROUP 消费组读取
• 与 List/发布订阅的差异

Streams 是 Redis 5.0 引入的仅追加日志型数据结构，每条消息由唯一 ID 与 field-value 键值对组成。XADD 追加一条消息并返回 ID；XREAD 按关键字直接读取消息（可带阻塞、可指定起始 ID）；XREADGROUP 以消费组身份读取并可配合 ACK 实现消息确认，支持待确认列表（PEL）。相比 List 的简单队列，Streams 支持多消费者组、消息持久化与消费确认，是功能最接近消息队列的内置结构。

Streams 弥补了 List/发布订阅在可靠消息消费上的不足，支持持久化、消费组、待确认重投，适合作为轻量 MQ 或事件总线。

• 切换阈值配置（hash-max-listpack-entries / hash-max-listpack-value）
• 切换的触发条件与过程
• 切换对内存和性能的影响

Hash 在元素数量少于 hash-max-listpack-entries（默认 128）且每个元素的 key/value 长度都小于 hash-max-listpack-value（默认 64）时，使用 listpack 紧凑编码以节省内存；当任一条件不满足时，编码原地升级为 hashtable（字典），以 O(1) 查找换取大数据量下的性能。listpack 顺序扫描的复杂度是 O(N)，因此数据量增大后必须切换为哈希表。

切换阈值反映"内存与查询复杂度"的平衡：小集合用连续内存扫描即可，大集合必须用哈希表分摊查找成本。该切换是单向的，升级后一般不会降回。

• quicklist 的结构（双向链表 + listpack 节点）
• 为什么用 quicklist 而非单一链表
• 相关配置（list-max-listpack-size）

Redis 3.2 起 List 底层使用 quicklist，它是一个双向链表，其中每个节点内部是一个 listpack（早期为 ziplist）。这样既保留链表插入删除头尾 O(1) 的优势，又通过每个节点内紧凑 listpack 减少节点数量、指针开销与内存碎片。每个 listpack 节点能容纳的条目或字节数由 list-max-listpack-size 配置控制。Redis 7 中 List 的深度小对象也直接使用单个 listpack 编码。

quicklist 是"链表 + 压缩块"的混合结构，兼顾大批量列表的插入性能与紧凑存储，避免纯链表每个条目一个 malloc 带来的大量指针与内存碎片。

• SDS 的结构（len、alloc、flags、buf）
• 对比 C 字符串：O(1) 长度、二进制安全、杜绝缓冲区溢出、预分配
• 空间预分配与惰性释放

SDS 由三部分组成：长度 len、分配容量 alloc、标志 flags 和字符数组 buf。相比 C 字符串以 '\0' 结尾、长度需 O(N) 遍历、不能存储二进制数据、追加时可能缓冲区溢出，SDS 通过 len 记录长度实现 O(1) 获取长度、二进制安全（可存储任意字节）、追加时自动扩容并按需预分配空间、惰性释放避免频繁内存分配。字符串以 '\0' 结尾便于兼容 C 字符串函数。

SDS 是 Redis 高吞吐与安全性的关键：O(1) 长度、二进制安全、内存预分配，让 String 既能存普通文本也能存序列化对象、图片等二进制数据。

• 哈希表用于 O(1) 按成员查分数
• 跳表用于按分数排序与范围查询
• 为什么用跳表而非红黑树

ZSet 在数据量大时底层是"字典 + 跳表"的组合：字典（哈希表）以 member 为 key、score 为 value，实现 O(1) 的按成员查找分数与更新；跳表以 score 排序、member 为附加值，支持 O(logN) 的按分数范围查询、排名计算与顺序遍历。两者共享同一批成员对象，通过两个结构协同保证"按成员 O(1) + 按分数 O(logN)"。

单一结构无法同时满足两种查询：哈希表能做精确查找但无法排序，跳表能排序但查找成员需要 O(logN)。组合两者以满足 ZSet 的 API 语义（ZSCORE 与 ZRANGEBYSCORE）。

• intset 编码（有序整数数组，二分查找）
• hashtable 编码（元素为 key）
• 切换触发条件（元素是否为整数、数量）

Set 在元素全部为整数且数量不超过 set-max-intset-entries（默认 512）时，使用 intset 编码：一个有序的整数数组，用二分查找判重，内存紧凑。当元素不是整数或数量超过阈值时，升级为 hashtable 编码，元素作为字典的 key（value 为 null），利用哈希表 O(1) 判重与查找。

intset 用紧凑有序数组 + 二分查找在小整数集合上兼顾内存与性能；一旦出现非整数或元素过多，哈希表提供更通用的 O(1) 语义。intset 升级也是单向的。

• PEL 记录已读取未确认的消息
• 消费者崩溃恢复与消息重投
• XACK 从 PEL 移除

PEL（Pending Entries List）是 Streams 中每个消费者（consumer）维护的待确认消息列表，记录该消费者已通过 XREADGROUP 读到但尚未 XACK 确认的消息 ID。它由 XACK 与 XPENDING 命令配合使用：XPENDING 查看 PEL 中未确认消息，XAUTOCLAIM/XCLAIM 可将超时未确认的消息转交给其他消费者重投。消费者崩溃后可通过 PEL 恢复未处理消息，保证"至少一次"语义。

PEL 是 Streams 可靠投递的核心：它把"已投递"与"已确认"分开，未确认就会留在 PEL 中可查询、可重投，从而支持消费者故障恢复与消息补偿。

• 消费组、消费者与 last-delivered-id
• XREADGROUP 读取与 XACK 确认
• 消息分发与重投（XCLAIM）

消费组在 Streams 中是一个逻辑实体，包含多个消费者（consumer），并维护 last_delivered_id 记录已投递到哪条消息。XREADGROUP 以组身份读取，组内消息会分发给不同消费者；每个消费者读取后消息进入其 PEL，处理完成后用 XACK 确认，确认后消息从 PEL 移除。消费组不支持消费者权重，消息按线性分配，未确认消息可通过 XCLAIM/XAUTOCLAIM 转移给其他消费者重投。

消费组把"一条消息"与"多个消费者协作处理"解耦，通过 PEL + ACK 实现可靠消费与负载均衡，是 Streams 相较发布订阅的核心增强。

• Valkey 与 Redis 的协议与命令兼容性
• Valkey 8 的命令集与 Redis 8 OSS 的差异
• 性能对比与多线程 IO

Valkey 是基于 Redis 7.2.4 代码 fork 出来的、采用 BSD-3-Clause 许可的开源分支，与 Redis RESP 协议及 CLI 完全兼容，绝大多数命令（含 Lua、Streams、Cluster、模块 API）保持一致，可直接替换 Redis 客户端与运维工具。Valkey 8.0 在兼容 Redis 7 命令集的基础上新增少量命令与选项（如 SCRIPT SHOW、CLUSTER SLOT-STATS、ZSCAN ... NOSCORES 等），并保留 RESP3。性能上 Valkey 与 Redis 处于同一量级，Valkey 8 对 IO 多线程、内存子分配等方面做了优化，部分基准场景略有优势。差异主要在许可与社区治理，而非协议功能。

Valkey 定位为许可开放、社区治理的 Redis 替代品，协议与命令集的高度兼容是其迁移成本低的关键；对用户而言，选择 Valkey 还是 Redis 更多是许可与治理考量而非功能差异。

• Redis 8 将部分模块能力内置
• 内置 vs 模块化（Stack）的差异
• 对部署与生态的影响

Redis 8 OSS 将原先需要 Redis Stack 模块（RediSearch、RedisJSON、RedisTimeSeries、RedisBloom）提供的 JSON、TimeSeries、Search、Vector 等能力纳入内置，作为一等公民的命令与数据结构，无需额外加载模块。相比传统模块化方式，内置数据结构具备：开箱即用（无需安装模块）、更好的类型系统与命令集成、与核心数据结构一致的持久化/复制/Cluster 语义；模块化方式则更灵活、可独立升级、由社区按需选择。差异主要在于"内置的稳定性一致性"与"模块的灵活性"之间的取舍。

内置这些结构降低了多模块部署的复杂度与版本兼容问题，也提升了数据结构间的互操作能力；但模块化仍保留了对定制与独立演进的支持。用户需根据是否依赖 Redis 官方内置语义来做选择。

• Bitmap 基于 String 的位操作、SETBIT/BITCOUNT
• HyperLogLog 的概率基数统计、PFADD/PFCOUNT
• GEO 的 geohash 编码、GEOADD/GEOSEARCH

Bitmap 本质是 String 的位数组，SETBIT 设置某一位、BITCOUNT 统计置 1 个数，适合布隆过滤器、每日签到、在线状态等大规模布尔统计，内存极省。HyperLogLog 用哈希与概率计数（寄存器占位）近似统计基数，PFADD 添加、PFCOUNT 返回去重基数，误差约 0.81%，适合 UV 统计，恒定内存约 12KB。GEO 通过 geohash 将经纬度编码为一维整数存入有序集合，GEOADD 写入、GEOSEARCH 按范围/半径查询，适合附近的人、LBS 检索。

三者都是"用特定编码换取内存或近似精度"的扩展结构：Bitmap 用位压缩布尔数据，HyperLogLog 用概率牺牲精度换恒定内存，GEO 用 geohash 把二维坐标映射到一维有序集合实现高效范围查询。

• listpack 替代 ziplist、quicklist 节点用 listpack
• 大 Key 的危害
• 大 Key 识别（--bigkeys、MEMORY USAGE）与治理（拆分、压缩、惰性删除）

Redis 7.x 全面用 listpack 替代 ziplist 作为小对象编码，quicklist 的节点也由 listpack 构成，消除了连锁更新与内存浪费。大 Key 指单个 key 的 value 过大（如超大 List/Hash/Set 或大字符串），会导致阻塞主线程、内存碎片、主从同步放大、扩容困难。识别手段包括 redis-cli --bigkeys（SCAN 采样统计）、MEMORY USAGE key、DEBUG OBJECT。治理手段包括：拆分为多个小 key（时间/业务分片）、用 hash 而非大 string、压缩序列化对象、对超大 key 惰性删除（UNLINK）避免阻塞。

大 Key 治理的核心是"避免单 key 承载过大数据"，从存储结构（拆分、用紧凑结构）与运维（识别、惰性删除）两方面入手，降低主线程阻塞与内存/同步放大风险。

• 大 Key 识别：--bigkeys、SCAN 采样、MEMORY USAGE
• 热 Key 识别：monitor、redis-cli --hotkeys（4.0+）、客户端统计
• 治理：拆分、压缩、多级缓存、本地缓存

大 Key 通过 redis-cli --bigkeys（对全库 SCAN 采样统计各类型最大 key）、SCAN 手动遍历 + MEMORY USAGE 精确测量识别；热 Key 通过 redis-cli --hotkeys（依赖 LFU 命中统计）、MONITOR 观察命令频率、或在客户端统计 key 访问次数识别。治理上，大 Key 用拆分（按业务/时间分片、Hash 替代大 String）、压缩（序列化压缩）、惰性删除（UNLINK）处理；热 Key 用本地缓存（Caffeine）、多级缓存、热点 key 复制分片、限流与降级缓解。

大 Key 影响内存与阻塞，热 Key 影响单节点负载均衡；识别手段分别面向"体积"与"访问频率"，治理分别面向"空间"与"流量"，两者都强调"拆分 + 分流 + 分层"。

• mem_fragmentation_ratio 的含义与正常范围
• 碎片成因（频繁增删、内存分配器、调整最大内存）
• 治理：activedefrag、合理 maxmemory、碎片整理

mem_fragmentation_ratio = used_memory_rss / used_memory，表示物理内存占用与逻辑内存的比值，正常约 1.0-1.5。比值过高说明内存碎片严重，成因包括频繁增删 key 导致内存块不连续、jemalloc 分配粒度与对象大小不匹配、maxmemory 调整后释放不及时。治理手段：启用 activedefrag yes（后台主动整理碎片，需 Redis 4.0+ 且开了内存上限）、合理设置 maxmemory 避免频繁触发淘汰、减少小对象高频增删、必要时重启或使用紧凑编码。

碎片率是"物理内存 vs 逻辑内存"的偏差，过高既浪费内存又可能在 maxmemory 下触发淘汰。治理重点是避免频繁分配/释放和合理配置内存上限，activedefrag 在后台渐进整理。

• 整数共享对象池（0-9999）
• 命令结果缓存（Redis 6.0+ 的缓存命令结果）
• 内存优化实践（紧凑编码、合理 TTL、避免大 key）

Redis 内置了整数共享对象池，将 0-9999 的整数复用为共享对象，避免为每个相同的整数创建副本，从而节省内存。Redis 6.0+ 支持客户端缓存（client-side caching），客户端可把热点读结果缓存在本地、由服务端推送失效通知，减少重复请求。工程上的内存优化实践包括：使用紧凑编码（listpack/intset）、设置合理 TTL 及时释放、避免大 key 与过多无效 key、用 Hash 结构存储对象字段、结合内存淘汰策略。

对象共享的思想是"减少重复对象的内存副本"，整数共享池针对小整数，命令缓存针对重复计算；配合紧凑编码与 TTL 管理，是 Redis 内存优化的主要手段。

• Streams 的能力边界（持久化、消费组、重投）
• Kafka/RocketMQ 的能力（分区、顺序、事务、削峰填谷）
• 选型依据（吞吐、可靠性、生态、运维复杂度）

Redis Streams 提供持久化、消费组、ACK 与重投，适合轻量级、低延迟、简单的事件总线与任务队列，部署简单、与 Redis 生态集成。但它在吞吐、分区并行、消息堆积、顺序保证、事务、削峰填谷（缓存背压）与多副本容灾上不如 Kafka/RocketMQ。Kafka 适合海量日志、高吞吐流式处理、分区并行与顺序消费；RocketMQ 适合事务消息、延迟消息、削峰填谷等强业务消息场景。取舍依据是吞吐量级、可靠性要求、数据规模与运维复杂度。

Streams 是"Redis 内置的够用 MQ"，适合中小规模与一体化部署；当吞吐、堆积、顺序、事务等成为硬需求时，应迁移到专业 MQ。这是"功能边界"与"性能/复杂度"的权衡。

• Valkey 8 的多线程 IO 与命令执行
• 对 Cluster 拓扑与客户端兼容性的影响
• 全局互斥与数据竞争的处理

Valkey 8 在保持命令执行串行化的前提下引入多线程 IO（读写/解析/序列化），线程模型变化主要影响内部并发控制，对 Cluster 拓扑与协议完全向后兼容：客户端、Cluster 命令、槽位分配、重定向（MOVED/ASK）语义不变。Valkey 用全局互斥锁保护共享状态、多线程只做无共享的 IO 操作，避免数据竞争。因此既有 Cluster 拓扑与客户端无需改动即可迁移，拓扑设计（槽位、副本布局）不受线程模型影响。

多线程化的目标是提升 IO 吞吐，而非改变命令语义或拓扑协议；Valkey 通过"仅 IO 多线程 + 状态串行化"保持兼容，使集群拓扑设计可平滑迁移。

• Redis 许可变更历程与含义
• Redis 8 OSS、Valkey 8、Redis Enterprise 的定位差异
• 企业合规选择框架

Redis 自 7.4 起采用 RSALv2/SSPLv1 双许可（7.2 及更早版本为 BSD-3-Clause），限制云服务商以商业方式提供 Redis 托管服务；Redis 8 起增加 AGPLv3 三许可选项。企业选型需评估：Redis 8 OSS 提供官方维护与最新功能（内置 JSON/Search/TimeSeries 等），但需遵守许可限制（尤其大型云服务场景）；Valkey 8 是 BSD-3-Clause 许可、协议兼容、适合需要宽松许可或自研托管服务的场景；Redis Enterprise 是商业版，提供企业级高可用、多活、专业支持。判断框架：是否对外提供 Redis 托管服务、是否需要商业支持与 SLA、对许可宽松度与功能进化的要求、现有生态与运维成本。

许可合规的核心是"是否以商业方式再分发 Redis 服务"；普通企业内部自用三种都可接受，选型主要看功能需求、支持服务与许可宽松度。Valkey 适合在意许可的企业，Redis 8 OSS 适合跟官方功能与支持，Redis Enterprise 适合生产级高可用要求。

• 跳表 vs 红黑树的实现复杂度与锁
• 跨度字段用于快速排名计算
• 跳表支持范围查询与顺序遍历

Redis 选择跳表而非红黑树，主要因为：跳表实现简单、易调试、无需复杂的旋转与颜色维护；范围查询与顺序遍历实现自然；便于在节点上维护跨度（span）字段实现 O(logN) 排名计算。跨度字段记录当前节点到下一节点的距离（跳过的节点数），用于 ZRANGE/ZRANK 等需要排名的命令，通过累加跨度快速定位到第 N 个元素。红黑树虽然操作复杂度同样是 O(logN)，但实现复杂、不便于维护排名与范围遍历。

"跳表 + 跨度"的组合让 ZSet 既能按分数 O(logN) 查找，又能 O(logN) 计算排名，而红黑树难以高效支持排名与顺序遍历，故最终选跳表。

• RESP3 的新数据类型（push、map、null 等）
• 客户端缓存与失效通知（invalidation）
• 减少网络往返的原理

RESP3 是 Redis 6.0 引入、Redis 8 完善的协议，新增 push、stream、map、set、null 等类型，支持服务端主动推送（如客户端缓存失效通知、Pub/Sub 事件），并支持异步命令。客户端缓存（Client-Side Caching）允许客户端把热点数据缓存在本地，服务端通过 RESP3 的 push 消息在 key 被修改时主动通知客户端失效，从而大幅减少网络往返。客户端缓存有两种模式：默认模式（客户端声明要缓存的 key，服务端跟踪并推送失效）与广播模式（客户端主动刷新失效表）。

客户端缓存把热点读从网络层下沉到进程内，配合服务端失效推送保证一致性，显著降低 RTT 与吞吐负担；RESP3 的 push 类型是这一机制的基础。

• SDS 的空间预分配与压缩
• intset 的紧凑存储
• 小对象编码转换（listpack/intset）的阈值

SDS 通过记录长度、空间预分配与惰性释放减少字符串操作的内存分配与拷贝，同时紧凑存储避免浪费；intset 用有序整数数组 + 二分查找紧凑存储小规模整数集合，避免为每个整数分配独立对象。小对象编码转换由配置阈值触发：Hash/ZSet/List 元素少且值小时用 listpack，Set 全整数且量小时用 intset，超过阈值自动升级为 hashtable/skiplist。整个机制的核心是"小数据用紧凑布局，大数据用高效查询结构"。

内存优化来自"紧凑编码 + 预分配 + 对象共享"的组合，编码转换阈值则保证在数据增长时性能不退化。这是 Redis 内存效率与性能平衡的体现。