Redis 版本变更的变化

以下是 Redis 主要版本的清单及其核心功能变化的梳理，按时间顺序整理关键版本演进 8版本没有整理：

Redis 1.0 (2009)

初始版本：发布首个稳定版本，支持基本键值存储。
核心特性：
- 支持字符串（String）、列表（List）、集合（Set）数据类型 。
- 简单持久化（基于快照的 RDB）。
  - RDB（Redis Database）是 Redis 默认的持久化方式，通过生成内存数据的二进制快照文件（如 dump.rdb）实现数据持久化。其核心原理是周期性地将内存中的数据集以压缩的二进制格式保存到磁盘，重启时通过加载 RDB 文件快速恢复数据
  - 工作原理
    - 触发机制
      - 手动触发 ：通过 SAVE（阻塞主进程）或 BGSAVE（后台异步）命令生成快照
      - 自动触发 ：根据 redis.conf 中 save 配置（如 save 60 10000 表示 60 秒内 10,000 次写操作触发快照）
      - 其他触发：主从复制时主节点自动触发、服务关闭时若未开启 AOF 也会触发
    - 生成过程
      - Redis 主进程调用 fork() 创建子进程，子进程负责写入数据到临时文件
      - 子进程遍历内存数据并序列化为二进制格式，写入临时 RDB 文件
      - 完成后替换旧 RDB 文件，保证原子性
      - 写时复制（Copy-On-Write）：父进程继续处理请求，子进程仅复制修改前的数据页，减少内存占用
    - 恢复流程
      - Redis 启动时自动检测并加载 RDB 文件，将数据载入内存
  - 缺点与限制(痛点)
    - 数据丢失风险：若两次快照间发生宕机，可能丢失最后一次快照后的数据
    - 资源消耗:
      - 内存：fork() 子进程时，数据集过大会占用额外内存（尤其在写操作频繁时）
      - CPU：大规模数据序列化可能影响性能
    - 版本兼容性：不同 Redis 版本的 RDB 文件格式可能不兼容
- 工作流程图

‍

Redis 2.0 (2010)

主要改进：
- 新增 哈希（Hash） 和 有序集合（Sorted Set/ZSet） 数据类型。
- 支持 主从复制（Replication）。
  - Redis 2.0 版本正式将主从复制（Master-Slave Replication）作为核心功能引入，奠定了其高可用架构的基础。以下是该机制的核心特性和实现原理：
    - 核心机制
      - 异步单向复制
        
        数据流动方向为主节点（Master）→ 从节点（Slave） ，主节点处理写操作，从节点仅支持读操作（读写分离）。
        
        复制过程默认异步执行，主节点无需等待从节点确认即可继续处理新请求
      - 全量复制（Full Resynchronization）
        
        首次同步流程：
        
        从节点发送 PSYNC ? -1 命令请求全量数据；
        
        主节点执行 BGSAVE 生成 RDB 快照文件，期间新写入命令存入 Replication Buffer；
        
        RDB 文件传输至从节点 ，从节点清空旧数据并加载快照；
        
        主节点将缓冲区中的增量命令发送给从节点，完成最终同步
      - 增量复制（Partial Resynchronization）
        
        断点续传机制：
        
        主节点维护 Repl Backlog Buffer （环形缓冲区，默认 1MB），记录最近的写命令
        
        从节点断线重连后，通过 PSYNC <runid> <offset> 携带断点偏移量，主节点从缓冲区提取差异命令发送
    - 优势与局限性
      - 核心优势
        
        高可用性： 主节点故障时可手动切换从节点为新的主节点
        
        读写分离：从节点分担读请求压力，提升系统并发能力
        
        数据冗余：实现热备份，降低单点故障风险
      - 主要局限性
        
        数据一致性延迟：异步复制导致从节点数据可能短暂落后主节点
        
        主节点单点瓶颈：所有写操作集中在主节点，高并发写场景易成性能瓶颈
        
        运维复杂度：故障恢复需人工干预或依赖哨兵机制（Redis 2.8 后引入 Sentinel))
    - 流程图
- 引入 虚拟内存（Virtual Memory，后弃用）。

Redis 2.6 (2012)

重要功能：
- 支持 Lua 脚本（原子性执行）。
  - 后续补充基础知识
- 新增 BITCOUNT、BITOP 等位操作命令。
  - BITCOUNT 命令
    - 功能：统计位图（Bitmap）中值为 1 的二进制位数量
    - 语法：BITCOUNT key $start end$
    - 参数：start 和 end 为字节偏移量（非位偏移），用于指定统计范围
    - 核心应用场景：
      - 用户行为统计
        例如统计用户每月签到次数（每个位代表一天是否签到)
      - 在线用户数统计
        用位图记录用户在线状态，通过 BITCOUNT 快速获取在线人数
      - 数据压缩与聚合
        将布尔型数据（如是否点击广告）压缩为位图，统计总触发次数
  - BITOP 命令
    - 功能：对多个位图进行按位运算（AND、OR、XOR、NOT），结果存储到目标键
    - 语法：BITOP <AND|OR|XOR|NOT> destkey key [key ...]
    - 限制：NOT 操作仅支持单个输入键
    - 核心应用场景
      - 用户行为交叉分析
        例如通过 BITOP AND 计算两日共同活跃用户
      - 布隆过滤器实现
        合并多个哈希函数生成的位图，快速判断元素是否存在
      - 数据合并与筛选
        如统计某商品在不同促销活动中被点击的用户（OR 运算）
- 客户端超时控制（CLIENT KILL）。

Redis 2.8 (2013)

关键更新：

PSYNC 机制：优化主从复制断点续传。

AOF 重写优化 ：子进程生成 AOF 文件，减少阻塞。

基本概念

AOF（Append Only File）是 Redis 的一种持久化机制，通过记录所有写操作命令的日志文件 实现数据持久化。与 RDB 的快照方式不同，AOF 以追加写入文本日志的形式保存数据变更历史，重启时通过重放日志中的命令恢复数据
核心特点：
- 实时性 ：支持秒级甚至毫秒级数据持久化，降低数据丢失风险
- 可读性：日志文件为文本格式，可直接查看操作记录

工作原理

AOF 的工作流程分为四个阶段
1. 命令追加：
  - 所有写操作（如 SET、DEL）执行后，命令会被追加到内存中的 AOF 缓冲区 （aof_buf）。
2. 文件同步：
  - 根据配置的同步策略（appendfsync），将缓冲区内容写入磁盘的 AOF 文件：
    - always：每条命令立即同步到磁盘，数据零丢失，但性能差。
    - everysec（默认）：后台线程每秒同步一次，最多丢失 1 秒数据，性能与安全性平衡。
    - no：由操作系统决定同步时机，可能丢失较多数据，性能最佳。
3. 文件重写（Rewrite）：
  - 目的：压缩 AOF 文件体积，去除冗余命令（如多次修改同一键的操作合并为最终状态）。
  - 触发条件：
    - 手动触发：执行 BGREWRITEAOF 命令。
    - 自动触发：根据 auto-aof-rewrite-percentage（如增长 100%）和 auto-aof-rewrite-min-size（如 64MB）配置。
  - 过程：
    - Fork 子进程生成新 AOF 文件，主进程继续处理请求并将新命令写入 重写缓冲区，子进程完成后合并新旧数据。
4. 数据恢复：
  - Redis 重启时优先加载 AOF 文件，按顺序重放所有命令恢复数据。
优缺点分析
- 优势：
  - 数据高可靠 ：默认配置（everysec）最多丢失 1 秒数据，适合对数据一致性要求高的场景。
  - 操作可追溯：日志文件便于审计和误操作恢复（如删除错误命令后重启）。
- 劣势：
  - 文件体积大：文本日志占用空间远大于 RDB 二进制快照。
  - 恢复速度慢 ：重放大量命令耗时较长，尤其在大数据量场景下。
应用场景与建议
- 推荐场景：
  - 对数据丢失容忍度低（如金融交易日志）。
  - 需要记录完整操作历史的场景（如审计追踪）。
- 实践建议：
  - 启用混合持久化：结合 RDB 和 AOF 优势，提升恢复效率。
  - 监控与维护 ：定期检查 AOF 文件大小 ，避免磁盘空间不足；使用 redis-check-aof 工具修复损坏文件。

aof 和 rdb简单对比

特性	AOF	RDB
数据安全性	高（秒级同步）	较低（依赖快照周期）
文件体积	较大（文本日志）	较小（二进制压缩）
恢复速度	慢（命令重放）	快（直接加载快照）
适用场景	高数据一致性需求	大规模数据备份、快速恢复

结构图

新增 SCAN 命令（代替 KEYS，避免阻塞）： KEYS全量阻塞 ：一次性扫描整个数据库，时间复杂度为 O(N) ，在数百万级键值场景下会长时间阻塞主线程，SCAN非阻塞分片：通过游标（Cursor）分批次迭代，每次仅扫描少量键，分散 CPU 和内存压力。
- SCAN 和 KEYS 命令对比 后续展开
- SCAN 命令介绍：

Redis 3.0 (2015)

里程碑版本：
- Redis 集群（Cluster） ：支持分布式分片（16384 个 哈希槽 ），自动故障转移。
- 哨兵（Sentinel） 高可用方案：监控和自动故障转移。
- 新增 WAIT 命令（同步复制到指定副本数）。

Redis 3.2 (2016)

核心改进：
- 新增 GEO 地理空间数据类型 （支持 地理位置计算 ）。
- 支持 Lua 脚本调试。
- 内存优化 ：字符串类型支持更紧凑的存储格式（embstr）。

Redis 4.0 (2017)

重大升级：

模块化架构：允许通过动态加载模块扩展功能（如 RedisSearch、RedisGraph）。
混合持久化 ： RDB + AOF 结合 （重启时优先加载 RDB，再追加 AOF）。
内存回收优化 ：惰性删除（UNLINK 代替 DEL，异步释放内存）。
新增 MEMORY 命令，分析内存使用。

Redis 5.0 (2018)

关键特性：
- Stream 数据类型：支持消息队列模式（消费者组、消息持久化）。
- 集群代理（Redis Cluster Proxy） ：简化集群客户端访问。
- RDB 增强：支持存储副本的复制偏移量（Partial Resynchronization）。
- 弃用旧命令（如 SLAVEOF 改为 REPLICAOF）。

Redis 6.0 (2020)

革命性更新：
- 多线程 I/O：主线程处理命令，多线程处理网络 I/O（提升吞吐量）。
- SSL/TLS 支持：加密客户端与服务端通信。
- ACL 权限控制：细粒度用户权限管理。
- 客户端缓存（Client-side Caching） ：支持 CLIENT TRACKING 机制。
- RESP3 协议 ：更丰富的数据类型编码（如 HELLO 命令切换协议版本）。

Redis 6.2 (2021)

功能增强：
- OOM 错误改进：提供更详细的内存溢出诊断信息。
- 新增 STRALGO 命令（字符串比对算法，如 LCS）。
- 集群模式支持副本迁移（Replica Migration）。

Redis 7.0 (2022)

核心升级：
- Multi-Part AOF：将 AOF 拆分为多个文件，避免重写时阻塞。
- Sharded Pub/Sub：集群模式下支持分片发布订阅。
- FUNCTION 命令：支持在 Redis 中定义和执行 Lua 函数库。
- ACL 增强 ：支持基于 Key 的权限控制（如 %R~orders:* 表示正则匹配）。

Redis 7.2 (2023)

改进重点：
- Triggered 集群自动平衡 ： 动态调整分片分布 。
- 新增 HSTACK、HRANDFIELD 等哈希命令。
- 优化大 Key 删除性能（后台线程处理）。

Redis 7.4 (2024 Preview)

最新特性（截至当前）：
- Server-assisted 客户端缓存：更高效的客户端缓存失效通知。
- TLS 增强：支持 OCSP Stapling。
- 性能优化：进一步降低多线程 I/O 的延迟。

Redis 7.4 (2024 Preview)

最新特性（截至当前）：
- Server-assisted 客户端缓存：更高效的客户端缓存失效通知。
- TLS 增强：支持 OCSP Stapling。
- 性能优化：进一步降低多线程 I/O 的延迟。

版本演进趋势总结

性能提升：从单线程到多线程 I/O、后台删除、内存优化。
扩展性增强：集群模式、模块化架构、分片 Pub/Sub。
可靠性改进：混合持久化、AOF 多文件、PSYNC 断点续传。
安全性强化：ACL、TLS 加密、细粒度权限控制。
功能丰富化：Stream、GEO、函数库、客户端缓存等。

建议版本选择

生产环境 ：推荐使用 Redis 7.x（最新稳定版），享受性能优化和新功能。
旧系统升级：从 Redis 3.x/4.x 迁移到 6.x/7.x 以支持 TLS 和 ACL。
兼容性注意 ：部分命令在跨版本升级时可能被弃用（如 SLAVEOF → REPLICAOF）。

如需更详细的版本变更日志，可参考 Redis 官方 Release Notes。