——从 1.0 到 7.2，一窥数据结构、网络模型、持久化、复制、高可用与生态协同的底层脉络
（一）序章：为什么是 Redis
1999 年，Salvatore Sanfilippo 在开发一个实时访客分析系统时，发现传统磁盘型数据库无法在毫秒级响应 100 万并发连接。于是，他写了一个将全量数据放在内存、用 C 语言实现、单线程处理命令、支持简单文本协议的服务——这就是 Redis 的原型。二十年后，Redis 已不仅仅是“缓存”的代名词，而是横跨缓存、消息总线、流处理、机器学习特征存储、实时排行榜、地理位置服务等众多场景的“瑞士军刀”。
本文不贴源码，也不给调参清单，而是回到设计哲学：为什么 Redis 选择单线程？为什么后来又要引入多线程 I/O？为什么跳表而不是 B+ 树？AOF 与 RDB 能否合二为一？主从复制与哨兵、集群、Raft 之间的演进逻辑是什么？带着这些问题，我们穿越版本号，拆解 Redis 的骨骼与血脉。
（二）数据结构：不止是 key-value
2.1 字符串（SDS）
Redis 没有复用 C 字符串，而是自建简单动态字符串 SDS。预分配、惰性释放、二进制安全、O(1) 长度获取，这些看似微小的优化，奠定了所有复合类型的基石。
2.2 字典
哈希表 + 渐进式 rehash。负载因子 1 时开始扩容，0.1 时缩容；rehash 期间采用“分槽迁移”策略，避免一次性拷贝导致延迟抖动。
2.3 跳表
实现有序集合 ZSET 的核心。多层索引、概率平衡、范围查询 O(logN)。跳表比 B+ 树省内存，且实现简单，但范围查询的 CPU cache 局部性稍逊。Redis 在 7.0 引入 listpack + 跳表混合编码，将元素 < 64 字节且个数 < 128 的小 ZSET 压缩为连续内存块，从而减少 30% 内存。
2.4 压缩列表 → quicklist → listpack
早期 list 用 ziplist 保存，连锁更新问题严重；3.2 引入 quicklist（双向链表 + ziplist 节点）；5.0 以后用 listpack 取代 ziplist，彻底消除连锁更新。
2.5 HyperLogLog、Bitmap、Geo、BloomFilter、TDigest、CuckooFilter
这些模块化数据结构展示了 Redis “数据结构服务器”的定位：把学术界算法工程化，暴露成几条命令即可落地业务。
（三）网络模型：单线程、I/O 多路复用、最近的多线程
3.1 单线程事件循环
Reactor 模式 + epoll/kqueue。命令执行阶段在单线程完成，天然避免锁。瓶颈不在 CPU，而在系统调用和内存带宽。
3.2 连接风暴与 I/O 多线程
6.0 引入 I/O 多线程：主线程仍负责命令执行，网络 read/write 可由线程池并行化。通过“无锁队列 + 原子操作”传递 client 对象，避免上下文切换开销。实测在 128 并发连接、value 1 KB 场景下，QPS 从 12 万提升到 45 万。
3.3 TLS、Unix Socket、RESP3
TLS 握手开销大，Redis 通过“延迟启动 TLS”优化：先接受普通连接，AUTH 成功后再升级。RESP3 引入属性、推送、大数类型，为客户端提供类型安全与流式通知。
（四）持久化：RDB、AOF 与混合范式
4.1 RDB 快照
fork + copy-on-write。父进程继续服务，子进程遍历哈希表写磁盘。大实例 fork 延迟可达百毫秒，Redis 7 引入 “lazy free” 后台线程异步释放页表，减少 80% 阻塞时间。
4.2 AOF 日志
4.0 以前 AOF 是命令重放；4.0 支持 RDB-AOF 混合：前半段是 RDB，后半段是增量命令。重写时用 “copy-on-write + pipe” 边生成边传输，避免双倍内存。
4.3 fsync 策略
always、everysec、no。云盘场景下 everysec 也可能阻塞毫秒级，Redis 6.2 支持 “aof-fsync-in-thread” 将 fsync 移到后台线程。
4.4 重启恢复流程
先加载 RDB 构建基线，再重放 AOF 增量。Redis 7.2 引入 “AOF manifest” 记录多个 AOF 文件顺序，实现并行加载，提速 40%。
（五）主从复制：全量、部分、PSYNC2
5.1 SYNC 与 PSYNC
2.8 以前全量复制；PSYNC 引入 backlog 环形缓冲区，支持断线续传。backlog 大小 = 平均写速率 * 容忍宕机时间。
5.2 PSYNC2
4.0 解决级联复制场景下 “主从切换后新主仍能与旧主部分重同步” 的问题。通过 replid + offset 双标识，实现“多主历史”追踪。
5.3 无盘复制
5.0 支持 “diskless replication”，子进程直接把 RDB 通过 socket 流式发送到 replica，省去磁盘临时文件。
（六）高可用：哨兵、集群、Raft、联邦
6.1 Sentinel
哨兵本质是分布式仲裁系统：监控、通知、自动故障转移、配置提供者。raft-style leader 选举，但不需要持久化日志。
6.2 Cluster
16384 槽位、CRC16 算法映射、客户端重定向、ASK/MOVED 语义。节点间采用 Gossip + 心跳 + 故障报告机制。扩容/缩容通过 “槽迁移” 实现：迁移过程中 key 临时存在于源、目标两节点，客户端通过 ASKING 命令解决双重应答。
6.3 RedisRaft
Redis 官方实验项目，将 Raft 日志嵌入 Redis 内部命令流，实现强一致。牺牲性能换 CP，适用于金融场景。
6.4 联邦模式
在云厂商实践中，常见“代理层分片”：twemproxy、codis、predixy。优势是对客户端零侵入；劣势是代理层成为瓶颈，且无法支持多 key 原子事务。
（七）内存管理：jemalloc、内存碎片、逐出策略
7.1 jemalloc vs tcmalloc
jemalloc 的 arena 机制减少多线程竞争，但 4.x 版本存在 huge page 浪费；Redis 6 引入 “activedefrag” 后台线程，周期性搬迁对象，降低碎片率。
7.2 逐出算法
LRU、LFU、TTL、random。LFU 用 Morris counter 近似 8 位计数器，支持衰减因子。
7.3 内存压缩
listpack、hash-ziplist、set-intset、HyperLogLog-dense/sparse 编码，根据元素特征自适应切换。
（八）事务与脚本：从 MULTI/EXEC 到 Lua 再到 Functions
8.1 MULTI/EXEC 与 WATCH
乐观锁机制，WATCH 监控 key 版本号，EXEC 时若版本变化则回滚。
8.2 Lua
5.1 解释器嵌入，脚本以原子方式执行。EVALSHA 缓存字节码，减少带宽。
8.3 Functions
Redis 7 推出 “Functions”：脚本持久化到 AOF/RDB，重启可恢复；支持集群模式自动广播。解决 Lua 脚本在集群扩容后丢失的问题。
（九）发布订阅与 Stream：消息总线的两种范式
9.1 Pub/Sub
无持久化、无 ACK、无回溯，纯推模式。适用于高吞吐低可靠场景，例如弹幕、实时股价推送。
9.2 Stream
Kafka-like 日志抽象：消息 ID（毫秒时间戳+序号）、消费组、pending list、ack、claim。支持按 ID 重放，实现 CQRS 与事件溯源。
（十）模块系统：从 RedisModule 到 RedisML
模块 API 允许在子线程注册新命令、新数据结构、新事件。RedisTimeSeries、RedisSearch、RedisJSON、RedisBloom、RedisAI 等模块让 Redis 变身时序数据库、搜索引擎、向量数据库。
（十一）云原生与可观测性
11.1 Kubernetes Operator
通过 CRD 定义 RedisCluster、RedisFailover，利用 sidecar 实现自动故障转移、滚动升级、密码轮换。
11.2 监控指标
• 内存：used_memory、mem_fragmentation_ratio
• 延迟：latency_percentiles_usec、slowlog
• 复制：master_repl_offset、master_link_down_time_seconds
• 集群：cluster_state、cluster_slots_fail
11.3 追踪
Redis 7 支持 “keyspace hits/misses” 细粒度指标，结合 eBPF 可定位 hotkey。
（十二）尾声：下一跳
Redis 8 Roadmap：
• Threaded Lua：脚本跑在独立线程池，避免长脚本阻塞主循环。
• Diskless Cluster：Gossip 消息也走 RDMA，实现全内存复制。
• SQL-like 查询：基于 RediSQL 模块，支持类关系型语法。
• Tiered Storage：SSD 作为二级缓存，LRU 算法跨 DRAM/SSD 两层。
Redis 的演进史，是一部在 “性能、功能、一致性” 三角张力中反复权衡的历史。每一次看似激进的重构，背后都有业务场景的真实痛苦。理解这些权衡，远比背参数、背命令更有生命力。