Redis 如何保证高并发与高可用
一、Redis 高并发的实现机制
1.1 单线程模型 + I/O 多路复用
- Redis 使用 单线程架构（从 Redis 6 开始引入 I/O 多线程，但核心命令仍由单线程执行）。
- 采用 epoll/kqueue 等 I/O 多路复用机制，非阻塞处理大量连接。
- 避免多线程带来的上下文切换和锁竞争问题。
1.2 高效数据结构与命令执行
- 内部使用如 跳表、字典、压缩列表、整数集合、位图等高效结构。
- Redis 命令执行在内存中，时间复杂度较低（多数为 O(1) 或 O(logN)）。
- 严格限制命令设计（无复杂计算型命令），保障执行效率。
1.3 内存操作 + 持久化可选
- 所有数据都存在内存中，读写无磁盘 I/O 瓶颈。
- RDB/AOF 持久化方式为异步，不阻塞主流程（可配置延迟策略）。
1.4 网络层优化
- 支持 TCP backlog、Nagle 算法关闭、keepalive 等参数优化。
- 支持批量管道（pipeline）减少 RTT 延迟。
二、Redis 高可用的实现机制
2.1 主从复制（Replication）
- 支持一主多从（master-slave）架构，从节点实时同步主节点数据。
- 可减轻主节点压力，读写分离：主写从读。
缺点：主节点宕机后需要人工切换，不能自动故障恢复。
2.2 哨兵机制（Sentinel）
Redis Sentinel 提供以下功能：
| 功能 | 描述 |
|---|---|
| 健康监控 | 定时 PING 各个实例，判断其是否存活 |
| 自动故障转移 | 主节点故障后，自动选举新的主节点 |
| 通知与报警机制 | 通过 API、日志等通知外部系统 |
| 配置更新 | 更新客户端连接信息，重新指向新的主节点 |
架构图示意：
+------------+ +------------+
| Master | ---> | Slave A |
+------------+ +------------+^ ^| Sentinel 监控 |+-------------------+
2.3 Redis Cluster（集群模式）
- 水平扩展：数据自动分片至多个节点（哈希槽 0~16383）。
- 分布式架构：无中心节点，每个节点负责一部分数据及 slots。
- 高可用保证：每个主节点可配置一个或多个从节点。
优点：
- 自动故障转移：主节点挂了，从节点提升为主。
- 读写高并发：客户端根据槽位访问目标节点，负载均衡。
- 无单点瓶颈：节点自治。
集群示意图：
[Master1] --- [Slave1]| |[Master2] --- [Slave2]| |[Master3] --- [Slave3]
2.4 快速恢复与持久化机制
- RDB 快照：定期生成数据快照（压缩存储）
- AOF（Append Only File）：追加日志形式记录写操作，支持恢复能力更强
- 混合持久化：RDB + AOF 的结合，兼顾启动速度与数据安全
- 延迟复制与备份中心：支持从节点异地部署，实现数据异地容灾
2.5 客户端容错与连接池
- 支持客户端连接池（如 JedisPool、Lettuce），避免连接创建开销。
- 客户端支持哨兵/集群感知，自动连接正确主节点。
- 支持超时重试、断线重连等机制，提高服务可用性。
三、高并发高可用场景下的实践建议
| 实践点 | 说明 |
|---|---|
| 使用集群部署 | Redis Cluster 保证可扩展性和故障恢复能力 |
| 开启持久化 | RDB + AOF 保证断电或崩溃后可恢复数据 |
| 配置哨兵 | 保证主从架构自动切换，提高服务可用性 |
| 合理内存规划 | 避免 OOM 导致实例崩溃 |
| 命令优化 | 避免使用 O(N) 的命令（如 keys、smembers） |
| 使用 Pipeline | 批量读写提升吞吐量，降低网络 RTT |
| 定期监控与预警 | 使用 Prometheus + Grafana 监控 QPS、延迟、内存等 |
| 冷热数据分离 | 频繁数据保留在 Redis，冷数据入库 |
四、总结
| 目标 | Redis 解决方案 |
|---|---|
| 高并发 | 单线程模型、内存操作、Pipeline、优化数据结构 |
| 高可用 | 主从复制 + 哨兵机制 + Redis Cluster |
| 数据安全 | AOF、RDB 持久化机制 |
| 横向扩展 | Redis Cluster 分片 |
| 故障转移 | Sentinel 自动主从切换，Cluster 自主选主 |