Redis如何保证高可用？
前言
我亲历过Redis宕机导致损失惨重的教训。
真正的Redis高可用不是简单的主从复制，而是构建能自动愈合的分布式神经系统。
这篇文章跟大家一起聊聊Redis如何保证高可用，希望对你会有所帮助。
这两天苏三的星球太火爆了，公众号上所有的优惠券都已经抢完了。
一、主从复制：高可用的基石与陷阱
主从复制全流程解析
图片
致命陷阱：异步复制导致的数据丢失
复制
# 主节点写入后宕机（未同步到从节点）
SET order:1001 "confirmed"
# 从节点提升为主节点后，订单状态丢失1.2.3.
解决方案：
复制
// 强制同步写入（谨慎使用）
Jedis jedis = new Jedis("master", 6379);
jedis.waitReplicas(1, 1000); // 等待1个从节点同步1.2.3.
二、哨兵模式：自动故障转移的艺术
三节点哨兵集群部署
图片
哨兵选举四部曲：
主观下线（SDOWN）：单个哨兵检测到主节点失联客观下线（ODOWN）：超过quorum数量的哨兵确认领导者选举：基于Raft算法选出主哨兵故障转移：提升最优从节点为新主节点Java客户端连接哨兵示例：
复制
Set<String> sentinels = new HashSet<>();
sentinels.add("192.168.1.10:26379");
sentinels.add("192.168.1.11:26379");
JedisSentinelPool pool = new JedisSentinelPool(
"mymaster", sentinels, poolConfig);
try (Jedis jedis = pool.getResource()) {
// 自动路由到当前主节点
jedis.set("config:timeout", "500");
}1.2.3.4.5.6.7.8.9.10.11.
三、Redis Cluster：水平扩展的终极方案
数据分片原理
图片
节点通信Gossip协议：
复制
// 模拟节点间状态传播
public void gossip(Node node) {
// 随机选择3个节点交换状态
List<Node> peers = selectRandomPeers(3);
for (Node peer : peers) {
sendPing(peer, currentState);
}
}1.2.3.4.5.6.7.8.
跨槽位操作解决方案：
复制
# 错误：多key不在同槽位
MGET user:1001:name user:1002:age
# 正确：使用hash tag强制同槽位
MGET user:{1001}:name user:{1001}:age1.2.3.4.5.
四、多级高可用架构设计
电商平台真实案例
图片
四层防护体系：
代理层：Twemproxy自动路由+负载均衡集群层：双集群互备+就近访问数据层：1主2从+读写分离灾备层：跨地域异步复制五、避坑指南
脑裂问题：最危险的故障模式发生场景：
图片
解决方案：
复制
# 1. 增加哨兵节点数（至少3个）
sentinel monitor mymaster 192.168.1.10 6379 2
# 2. 设置主节点最小从节点数
min-replicas-to-write 11.2.3.4.5.
复制
// 缓存穿透+雪崩防护代码示例
public String getProductInfo(String id) {
// 1. 查询缓存
String cacheKey = "product:" + id;
String value = jedis.get(cacheKey);
// 2. 缓存穿透：空值缓存
if ("NULL_OBJ".equals(value)) returnnull;
// 3. 缓存未命中
if (value == null) {
// 4. 互斥锁防止雪崩
if (jedis.setnx("lock:"+id, "1") == 1) {
jedis.expire("lock:"+id, 3); // 避免死锁
try {
// 5. 数据库查询
value = db.query("SELECT...");
// 6. 空结果防穿透
jedis.setex(cacheKey, 300, value == null ? "NULL_OBJ" : value);
} finally {
jedis.del("lock:"+id);
}
} else {
// 7. 其他线程等待重试
Thread.sleep(100);
return getProductInfo(id);
}
}
return value;
}1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.
六、监控体系：高可用的生命线
告警规则示例：
复制
# 复制延迟 > 5秒
repl_delay{instance="*"} > 5
# 内存使用 > 90%
memory_used_percentage > 0.9
# 连接数 > 80%上限
connected_clients / maxclients > 0.81.2.3.4.5.6.7.8.
三级防御体系：
图片
五个核心原则：
冗余设计：最少1主2从，跨机架部署自动故障转移：哨兵quorum数 = 节点数/2 + 1容量规划：内存使用率控制在70%以下性能隔离：业务集群物理隔离混沌工程：定期模拟节点宕机、网络分区高可用的本质不是避免故障，而是在故障发生时系统仍能持续提供服务。
通过主从复制、哨兵机制、Cluster集群的三级防御，配合严谨的监控和容量规划，才能构建真正弹性的Redis架构。
阅读剩余
THE END
