1. 主从复制 核心流程
前置基础
- Redis主从复制是所有高可用能力的根基，哨兵/集群的故障转移均依赖此流程
- 角色定义：主节点(Master) 支持读写，从节点(Slave/Replica) 默认只读，从节点数据完全同步主节点
- 核心模式：全量复制（首次同步）+ 增量复制（常态同步），全量仅执行1次，增量永久执行
- 触发条件：从节点配置
replicaof 主节点IP 端口（Redis6.0+），重启自动触发
完整执行流程
阶段1：全量复制（首次初始化同步）
- 从节点发送
PSYNC ? -1命令给主节点，发起全量同步请求； - 主节点执行
bgsave异步生成RDB快照文件，期间所有写命令缓存至「复制缓冲区」； - 主节点将RDB文件发送至从节点，从节点清空本地旧数据后加载RDB恢复数据；
- 主节点把复制缓冲区的缓存命令发送给从节点，从节点执行命令完成数据追平；
- 全量复制完成，进入增量复制阶段。
阶段2：增量复制（常态实时同步）
- 主节点执行任意写命令后，将命令写入「复制积压缓冲区」；
- 主节点通过TCP长连接，实时将命令同步至所有从节点；
- 从节点执行收到的写命令，保持与主节点数据一致，循环执行永不停止。
生产注意事项
- 从节点默认配置
replica-read-only yes，禁止写入，防止数据不一致； - 主节点
bgsave的fork操作会短暂阻塞主线程，建议低峰期做首次同步； - 主从存在毫秒级同步延迟，业务需容忍最终一致性；
- 主节点故障后，需手动执行
replicaof no one升格从节点，无自动切换能力。
2. 哨兵模式(Sentinel) 故障转移核心流程
前置基础
- 架构组成：
1主N从 + M个哨兵节点，哨兵为独立Redis进程，节点数必为奇数（3/5个） - 核心依赖：完全基于主从复制，核心能力是自动化故障转移，解决主从人工切主痛点
- 核心状态（分级防误判）：
- 主观下线(SDOWN)：单个哨兵PING主节点超时，自身判定主节点故障；
- 客观下线(ODOWN)：超半数哨兵判定主节点主观下线，全网共识故障，触发转移的唯一条件。
- 核心特性：中心化架构，故障转移指令由哨兵集群统一下发，RTO≤10秒。
完整执行流程（全自动化，无人工干预）
- 所有哨兵节点每隔1秒向主/从节点发送PING命令，实时监控健康状态；
- 某哨兵检测主节点PING超时，标记为主节点「主观下线」并广播状态；
- 其他哨兵核验状态，超半数达成共识后，标记主节点「客观下线」，启动故障转移；
- 哨兵集群基于Raft算法投票，选举最优从节点 为新主节点，选举优先级：
- 优先级1：
replica-priority数值越小优先级越高（0无竞选资格）； - 优先级2：与原主节点数据同步偏移量最大（数据最新）；
- 优先级3：运行时长更久、节点ID更小的从节点。
- 优先级1：
- 哨兵向新主节点发送
replicaof no one命令，完成升格； - 哨兵向其余从节点发送
replicaof 新主IP 端口，切换同步源； - 哨兵更新配置并发送告警，客户端无缝切换请求，故障节点修复后自动成为新主的从节点。
生产注意事项
- 核心坑点：脑裂问题 ，配置
min-replicas-to-write 1+min-replicas-max-lag 10，原主失联时拒绝写入； - 哨兵仅监控主节点，从节点故障仅标记下线，等待自愈即可；
- 哨兵集群所有节点存储全量数据，无法解决单机内存容量瓶颈。
3. Redis Cluster 集群故障转移核心流程
前置基础
- 架构核心：去中心化+哈希槽分片+主从副本，内置故障转移能力，无需独立哨兵进程
- 哈希槽规则：固定
16384个哈希槽，每个Key经CRC16(Key)%16384映射槽位，每个槽位对应1主N从 - 核心状态：与哨兵逻辑一致，PFail(疑似下线) =哨兵SDOWN，FFail(确定下线)=哨兵ODOWN
- 核心特性：故障转移粒度为哈希槽级别，仅影响故障主节点的槽位，其余服务不受影响
完整执行流程（全自动化，分片级故障转移）
- 集群所有节点每秒互发PING/PONG消息，监控健康状态+同步槽位映射信息；
- 节点检测到某哈希槽主节点无响应，标记为「PFail」并广播状态；
- 超半数节点达成共识后，标记该主节点为「FFail」，触发故障转移；
- 故障主节点的健康从节点发起竞选，获半数以上选票的从节点成为新主；
- 新主节点自动接管原主节点的所有哈希槽，并向集群广播槽位归属变更；
- 集群所有节点更新本地槽位映射表，客户端请求自动重定向至新主节点；
- 故障主节点修复重启后，自动作为新主的从节点归队同步数据。
生产注意事项
- 故障转移仅影响目标哈希槽，集群整体服务无感知，业务零中断；
- 集群去中心化设计，无单点故障，所有节点均具备监控/选举能力；
- 集群节点仅存储分片数据，解决单机内存瓶颈，支持TB级数据存储；
- 不支持跨哈希槽的事务/Lua脚本，无法保证跨节点原子性。
Redis 底层+持久化+运维核心流程
1. Redis 单线程命令执行核心流程（高性能底层根源）
前置基础
- Redis的核心命令执行线程为单线程，持久化/主从同步为后台多线程，这是高性能的核心设计；
- 核心优势：彻底避免线程切换、锁竞争开销，CPU利用率100%，结合纯内存操作实现10万+ QPS；
- 核心原则：所有客户端命令串行执行，先到先执行，无并发数据冲突。
完整执行流程
- 客户端通过TCP与Redis建立长连接，发送业务命令（如
SET/GET）； - Redis通过IO多路复用模型（epoll/kqueue）监听所有客户端的网络事件，收集就绪请求；
- 就绪命令按到达顺序进入「命令队列」排队等待执行；
- Redis单线程从队列中逐个取出命令，依次执行：解析命令 → 操作内存数据结构 → 生成响应结果；
- 单线程将响应结果通过TCP返回至对应客户端；
- 循环执行「事件监听→入队→执行→响应」的闭环流程。
生产注意事项
- 单线程的核心坑点：慢查询命令阻塞 ，如
KEYS */HGETALL会阻塞整个队列，导致Redis卡顿； - 解决方案：禁用慢命令，用
SCAN/HSCAN渐进式遍历替代； - Redis6.0+的多线程仅优化网络IO读写，命令执行仍为单线程，核心流程不变。
2. Redis 过期Key清理核心流程（定期删除 + 惰性删除，组合策略）
前置基础
- 核心能力：Redis支持
EXPIRE key ttl给Key设置过期时间，需主动清理过期Key释放内存； - 核心策略：采用定期删除+惰性删除的组合方案，Redis最优解，无其他替代方案，必考；
- 设计初衷：平衡「内存释放效率」和「单线程性能」，既清理过期Key，又不阻塞主线程。
完整执行流程（双策略并行，缺一不可）
策略1：定期删除（主动后台清理，主力）
- Redis单线程每隔100ms执行一次过期清理任务；
- 每次清理随机抽样部分带过期时间的Key，而非全量扫描；
- 检查抽样Key是否过期，过期则直接删除；
- 若本次抽样的过期率≥25%，则继续抽样清理，直到过期率低于阈值；
- 单次清理耗时严格限制在毫秒级，超时立即停止，绝对不阻塞主线程。
策略2：惰性删除（被动按需清理，兜底）
- 客户端主动访问某Key时，Redis优先校验该Key的过期状态；
- 若Key已过期，立即删除该Key并返回
null空值； - 若Key未过期，正常执行命令并返回业务结果。
生产注意事项
- 过期Key漏删是必然的：定期删除是抽样、惰性删除是按需，会有部分过期Key残留内存；
- 漏删的过期Key，最终会被「内存淘汰机制」兜底清理，二者强联动。
3. Redis 内存淘汰机制执行流程（内存满兜底策略，生产必配）
前置基础
- 触发条件：Redis内存使用量 ≥ 配置的
maxmemory上限时，立即触发，无例外； - 核心关系：过期清理是「清理过期Key」，内存淘汰是「清理内存超限的Key」，淘汰是过期清理的终极兜底；
- 核心配置：
maxmemory-policy，共8种策略，生产禁用默认的noeviction。
完整执行流程（自动触发，业务无感知）
- Redis实时监控内存使用率，与
maxmemory阈值做对比； - 内存占满后，立即触发内存淘汰机制；
- 按配置的淘汰策略，筛选待删除的Key集合：
allkeys-lru：筛选最近最少使用的所有Key（生产最常用）；volatile-lfu：筛选使用频率最低的带过期时间的Key；
- 逐个删除筛选出的Key，释放内存至
内存使用率 < maxmemory； - 淘汰完成，Redis恢复正常读写服务。
生产注意事项
- 生产必配策略：
allkeys-lru或volatile-lfu，禁止使用noeviction（拒绝所有写命令，业务报错）； maxmemory建议配置为物理内存的70%-80%，避免系统OOM杀死Redis进程；- 淘汰操作单线程执行，每次仅删少量Key，无性能阻塞。
4. Redis RDB持久化完整核心流程（快照持久化，默认开启）
前置基础
- 核心原理：将Redis内存中的全量数据 生成二进制快照文件
dump.rdb落地磁盘，重启加载恢复； - 触发方式：手动触发(
bgsave/save) + 自动触发(save m n/关闭Redis/主从全量同步)； - 核心特点：文件体积小、恢复速度快，缺点是可能丢失快照间隔内的数据。
完整执行流程（分「生成」+「加载」两个子流程）
子流程1：RDB文件生成流程
- 触发RDB后，优先使用
bgsave（异步），主进程fork子进程执行快照，不阻塞主线程； - 子进程持有主进程的内存数据副本，遍历数据写入「临时RDB文件」；
- 写入完成后，原子性替换旧的RDB文件，避免文件破损；
- 子进程退出，RDB生成完成。
子流程2：Redis重启-RDB加载流程
- Redis启动时，检查本地是否存在
dump.rdb文件； - 存在则加载文件至内存恢复数据，加载期间暂停客户端请求；
- 加载完成后，Redis正常接收读写请求；无文件则内存为空启动。
生产注意事项
- 禁止使用
save命令：同步执行快照，会阻塞主线程导致Redis卡死； - fork子进程会短暂阻塞主线程，数据量越大阻塞越久，建议低峰期触发。
5. Redis AOF持久化+AOF重写完整核心流程（日志持久化）
前置基础
- 核心原理：将Redis所有写命令 以文本日志形式追加写入
appendonly.aof文件，重启重放命令恢复数据； - 核心开关：配置
appendonly yes开启，默认关闭，生产必开； - 优先级规则：AOF优先级 > RDB优先级，同时开启时，重启优先加载AOF（数据更完整）；
- 核心痛点：AOF文件会无限增大，需通过AOF重写机制瘦身。
完整执行流程（三个子流程闭环）
子流程1：AOF正常追加写入流程
- Redis执行写命令后，将命令追加至「AOF缓冲区」；
- 按配置的
appendfsync刷盘策略写入磁盘：always：每次写命令刷盘，零数据丢失，性能最差；everysec：每秒刷盘一次，最多丢1秒数据，生产默认推荐；no：由系统决定刷盘时机，性能最好，风险最高。
- 循环执行，所有写命令永久记录至AOF文件。
子流程2：AOF重写流程（核心瘦身，自动/手动触发）
- 触发方式：手动
bgrewriteaof/ 自动（文件体积增长100%且≥64MB）； - Redis fork子进程，遍历内存数据生成「重建数据的最少命令」写入临时AOF文件；
- 重写期间，新写命令同时写入「原AOF缓冲区+重写缓冲区」，保证数据不丢失；
- 子进程写完后，将重写缓冲区的命令追加至临时文件，原子性替换旧AOF文件；
- 后续写命令追加至新AOF文件，重写完成。
子流程3：Redis重启-AOF加载流程
- Redis启动时，若开启AOF则优先检查
appendonly.aof文件； - 存在则逐行读取并执行写命令，恢复内存数据；文件破损则自动修复后加载；
- 加载完成后，正常提供服务。
生产注意事项
- 生产必开混合持久化（Redis4.0+）：AOF头部是RDB快照，尾部是增量命令，兼顾恢复速度和数据安全；
- AOF重写的fork操作会短暂阻塞主线程，自动触发阈值不宜配置过低。
6. Redis 主从复制-断点续传流程（增量复制补充，高频场景）
前置基础
- 核心场景：主从节点网络断连后重新恢复连接，无需再次全量复制，仅同步断连期间的增量命令；
- 核心依赖：主节点的「复制积压缓冲区」，固定大小的环形缓冲区，存储主节点最近的写命令；
- 核心价值：避免网络抖动导致的重复全量复制，大幅降低同步性能损耗。
完整执行流程（自动触发，无人工干预）
- 主从正常同步时，主节点将写命令持续写入「复制积压缓冲区」；
- 主从网络断连，从节点停止同步，主节点继续写入命令至缓冲区；
- 网络恢复后，从节点重连主节点，发送
PSYNC 偏移量命令，偏移量为最后一次同步成功的位置； - 主节点校验偏移量是否在缓冲区中：
- 存在：发送偏移量后的所有增量命令，从节点执行追平数据，恢复常态同步（断点续传）；
- 不存在：缓冲区被覆盖，重新执行全量复制。
生产注意事项
- 配置
repl-backlog-size 10-50MB（默认1MB），调大缓冲区减少覆盖概率； - 断点续传是Redis原生优化，所有主从架构均支持，无需额外配置。
7. Redis Cluster 哈希槽分配+数据迁移核心流程（集群灵魂，平滑扩容核心）
前置基础
- 核心规则：Redis Cluster固定
16384个哈希槽，是集群最小分片单位+最小迁移单位； - 核心特性：槽位迁移时，仅迁移槽位对应的Key，无需迁移全量数据，这是平滑扩容的根本原因；
- 核心场景：集群初始化、扩容新增节点、缩容下线节点，本质都是哈希槽的重新分配。
完整执行流程（分初始化+迁移两个核心场景）
场景1：集群初始化-哈希槽首次分配
- 执行
redis-cli --cluster create搭建集群，指定所有节点； - Redis自动将16384个哈希槽平均分配给所有主节点；
- 各节点记录自身槽位范围，广播槽位映射关系，集群初始化完成。
场景2：扩容/缩容-哈希槽+数据迁移（平滑无感知）
- 指定待迁移的「哈希槽范围」、源节点、目标节点，执行迁移命令；
- 源节点将槽位内的Key逐个取出，发送至目标节点；
- 目标节点写入Key后返回确认，源节点删除本地对应Key；
- 槽位内所有Key迁移完成后，源节点将槽位所有权转移至目标节点；
- 集群广播新的槽位映射关系，客户端请求自动重定向，全程服务不中断。
生产注意事项
- 哈希槽不可拆分：只能迁移整个槽位，不能迁移槽内部分Key，保证数据归属唯一；
- 迁移为「逐个槽位」执行，降低性能损耗，业务完全无感知。
8. Redis 启动加载完整核心流程（所有流程入口，优先级最高）
前置基础
- 核心定位：Redis启动时第一个执行的流程，所有其他流程均在此之后启动；
- 核心目标：加载持久化文件恢复内存数据，保证重启后数据不丢失；
- 核心优先级：AOF文件 > RDB文件，二者同时存在时只加载AOF。
完整执行流程（固定顺序，永不改变）
- Redis启动，加载
redis.conf配置文件，初始化端口、内存、持久化等核心参数； - 初始化内存数据结构，此时内存为空；
- 检查是否开启AOF持久化：有AOF文件则加载并恢复数据，无则进入下一步；
- 检查是否存在RDB文件：有则加载恢复数据，无则内存保持为空；
- 数据加载完成后，初始化网络监听，接收客户端请求；
- 若配置主从/哨兵/集群，启动对应的高可用流程。
生产注意事项
- AOF文件破损会导致启动失败，可使用
redis-check-aof --fix命令修复； - 数据量越大加载耗时越长，建议业务低峰期重启Redis。
总结：Redis 所有核心流程 优先级+关联关系
1. 全量核心流程优先级排序（从核心到运维，一网打尽）
- Redis 启动加载完整核心流程（所有流程的统一入口）
- Redis 单线程命令执行核心流程（高性能底层根源，所有请求通用）
- Redis 过期Key清理核心流程（定期删除+惰性删除）
- Redis 内存淘汰机制执行流程（内存超限兜底）
- Redis RDB持久化完整核心流程
- Redis AOF持久化+AOF重写完整核心流程
- Redis 主从复制完整核心流程（含断点续传）
- Redis 哨兵模式故障转移完整核心流程
- Redis Cluster 哈希槽分配+数据迁移核心流程
- Redis Cluster 集群故障转移完整核心流程
2. 所有流程核心关联逻辑（吃透即通透Redis）
- 所有流程围绕高性能、高可用、数据安全、易运维四大目标设计，环环相扣无孤立流程；
- 启动加载是入口，单线程执行是运行核心，过期清理+内存淘汰保障内存稳定；
- 持久化是数据安全的兜底，主从复制是高可用的根基；
- 哨兵是主从的自动化升级，集群是主从+哨兵+分片的分布式终极形态；
- 哈希槽迁移是集群运维核心，解决海量数据的平滑扩容问题。
核心一句话总结
Redis的所有核心流程，本质是一套完整的闭环体系，从底层的单线程执行到上层的集群故障转移，所有设计均为了解决生产环境的实际问题，这也是Redis成为互联网核心中间件的根本原因。