Redis如何实现高可用性
小樊
39
2025-12-16 17:55:34
Redis高可用实现路径
一 核心机制总览
- 数据不丢失：通过持久化机制保障，包括RDB快照、AOF追加日志与混合持久化（Redis 4.0+）。RDB恢复快但可能丢数据；AOF更实时但写性能与体积压力大；混合持久化以RDB开头+AOF续写，兼顾启动速度与降低丢失风险。
- 故障自动切换：基于复制的**Redis Sentinel（哨兵）**实现主从架构下的自动故障转移与通知；Redis Cluster通过分片与副本实现无中心化的高可用与横向扩展。
- 水平扩展与容错：Cluster将数据划分为16384个哈希槽，多主多从分布，部分节点失效仍可对外服务。
二 主从复制要点
- 作用与特点：一主多从提供数据冗余与读写分离能力，从节点默认只读（replica-read-only yes），主节点写压力集中。
- 开启方式：在从节点配置文件中设置replicaof （或启动命令/运行时命令 slaveof），主从复制由从节点发起；若主节点启用密码，从节点需配置masterauth。
- 复制流程：
- 初次连接触发全量复制：主节点执行BGSAVE生成RDB并发送，同时缓冲新写命令；从节点加载RDB后回放缓冲命令。
- 断链重连后优先部分复制：依赖复制积压缓冲区（repl_backlog）与偏移量（offset）进行增量同步。
- 拓扑与网络：支持一主一从、一主多从、树状主从；跨机房可开启repl-disable-tcp-nodelay权衡延迟与带宽。
三 哨兵模式要点
- 定位与目标：监控主从节点，完成主观下线/客观下线判定与自动故障转移（failover），并通知客户端新主地址，解决主从架构下的人工切换问题。
- 部署建议：至少部署3个Sentinel实例且分布在不同物理机/可用区，形成多数派投票；最小监控单位通常为一主一从。
- 关键配置示例：
- sentinel monitor mymaster 127.0.0.1 6379 2（quorum为2）
- sentinel down-after-milliseconds mymaster 5000（5秒判定主观下线）
- sentinel failover-timeout mymaster 60000（故障转移60秒超时）
- sentinel parallel-syncs mymaster 1（故障后并行同步从节点数）
- 客户端接入：应用通过Sentinel API获取当前主节点，例如使用 redis-py 的Sentinel类连接。
四 Redis Cluster要点
- 架构特性：无中心、分片（16384槽）、多主多从、基于gossip与投票的故障转移；部分节点不可用仍可继续服务。
- 适用场景：需要线性扩展与高并发的业务；注意其最终一致性、跨slot限制（如mget/mset需同slot）、事务仅限同节点key、仅支持db 0等约束。
- 部署与运维：至少3主起步，建议每主至少1从；常见端口为6379（业务）与16379（集群总线）；可用官方工具或容器平台编排创建与扩缩容。
五 方案选型与落地建议
- 缓存优先、容忍少量丢失：主从 + 合理持久化（如AOF或混合持久化），读多写少场景可加从节点做读写分离。
- 高可用优先、写少读多：一主多从 + Sentinel，获得自动故障转移与读扩展能力。
- 大数据量/高并发：Redis Cluster分片，多主多从提升吞吐与容量，注意规避hot-key/big-key与跨slot操作。
- 跨地域容灾：在主从或Cluster之上引入跨区域复制（异步）提升区域级可用性，同时接受更高网络时延与一致性权衡。
- 通用实践：为故障演练准备切换预案与回滚路径，监控复制偏移与延迟、持久化状态、哨兵/集群健康度，并规范客户端重试与超时策略。
