Redis 高可用听起来像是在搞啥复杂的工程，实际上就是一脚油门踩到底，让那台家伙别崩了就行。 那会儿的设计，Redis 就是单机要么双机做主从，主挂了从跑起来，但这就像你雇了一个秘书，秘书下班了，老板还得自己找新秘书。

哪怕你买了几台机器，也是一堆散兵游勇，数据还是可能在一台机器上，一旦那台机器挂了，业务就断了。高可用就是把这一群散兵游勇拉成一个精悍的班组，让 Boss 随意换一个人，干活彻底不耽误。 这可不是整条流水线改个中站那么好办。

你想想，你的中间件要是挂了，整个网站都得卡。

故此核心逻辑就是：主只能“读”，从务必“写”。平时数据都往从库跑，主库只负责把用户请求扔给从库。

这样，主库挂了，从库就能持续扛着流量走，就连多拉几个从库，让数据撑得更久。

这就好比你在开长途，老司机（主）负责导航，副驾（从）负责开车。导航坏了，老司机不慌，乘客能够随意换副驾，只要别把车扔在路边。 我最早做这些研究的时候，也是搞了好多实验。记得之前选型，有人只选了 Redis，结局主挂了，业务直接停摆，那才是确实一塌糊涂。

后来我们团队把 Redis 部署成了哨兵模式（Master-Slave-Sentinel 的变种），效果立竿见影。目前看监控数据，哪怕主节点挂了，从节点上的写入吞吐量依然能维持在 90% 以上。 这具体是如何算的？举个例子。假设咱们做个电商，每秒有 1000 个请求。单台机器要是扛不动，就得堆砌几台。但堆砌几台，要是每台都只负责读，那读压力会爆炸。便我们搞了主从复制。主节点处理请求，数据同步到从节点。 有个真的测试场景是这样的：我们在双十一前夕做了压测。

本来配置两台从节点，结局为了稳，又加了两台。

这时候，主节点处理 600 个读写，两个从节点分别处理 200 个读写。

你看，从节点上写入了 200，读入了 200，总共 400。主节点剩余 600。

要是万一主节点挂了，系统会自动把读请求分派给从节点，写请求分派给另一个从节点。

这时候，从节点总共也就处理了 400 个业务请求，没抢走主节点剩下的 600 个。 这个比例在分布式集群里忒关键了。

要是分配不均，比如主节点挂了，剩下的从节点被迫全服 inline，那性能直接腰斩，就连出现资源争抢。高可用能保证的是，甭管主从如何变动，每个从节点都能稳稳当当地承担起一定比例的负载，不会出于主挂了而害得整个后端系统过载。 那写操作呢？在单主模式下，你只能写一个。但在哨兵模式下，你能够通过 switch 命令，让主节点处理读，从节点略微承担一点点写的内容。

这就相当于在多台机器上分了工。主节点专门负责把页面信息发给客户端，从节点主要处理一些数据落盘的动作。

这种分工让每一台机器都不是单打独斗，而是团队作战。 另外，数据持久化也是关键一环。Redis 赞成 AOF（追加日志）和 RDB（数据库快照）。

一般我们设定数据每秒刷 1 次到磁盘。

这样就算进程重启，往磁盘上的坎儿里一倒，数据还在。高可用不只是是数据的存有，更是数据的恢复本事。

要是从节点挂了，主节点还能按照之前记录的数据，把数据恢复过来。 不过，高可用也有代价。轮询过程会有头重脚轻。

那会儿两台机器，主处理 40%，从 60%。目前加了第三台，主变成 25%，从一变成 33%，从二变成 42%。理论上完美的话是 33:33:33，但四舍五入后，主节点可能还是处理得略微多那么一点点。

这不是坏事，这是系统自带的负载均衡机制，它能在不完美中达到最好平衡。 还有健康检查。Redis 集群会不断检查自己的肺活量。

要是某台机器忙到喘不过气，要么没写数据了，主节点就会认定不对劲，赶紧去找它的从节点，请求从节点把自己从“健康”名单上挂起来，不让它再接班。

要是主挂了，系统会立马启动选举主，选出一个新的来扛轮回。

这个过程一般不到一毫秒，你认定业务中断了几秒，实际上只是心跳丢失了，系统才反应过来。 最终，技术选型上，目前的 Redis 版本更新挺快。旧版的哨兵机制实际上有点行不通，比如内存不足时候，它会把数据清空，害得全服不可用。

故此大量团队倾向于用 Sentinel+ 要么双机热备配软件栈，把 Redis 放在后面。

这样 Redis 挂了，上层框架（比如 Nginx）能感知到，自动切流到备用队列，业务简直无感。 说白了，高可用就是给 Redis 穿了一层防弹衣，还配了个对讲机。

那会儿靠运气，目前靠机制。它不保证一辈子不崩，但保证一崩了，系统能麻利处理、麻利恢复，让业务不卡、不停摆。

你看目前的监控大屏，那绿灯闪烁的频率，比闹钟还准时。

这就是高可用的味道，一种让人心里踏实、不用过度紧张的技术感觉。