Redis集群到底咋搞，才能真实现高可用不掉链子

第一，别心疼机器，节点数量要到位。 （来源：Redis官方文档及社区最佳实践） Redis集群默认是分片的，也就是把数据分成很多份，放在不同的主节点上，一个最基本的原则是：至少要有三个主节点和三个从节点，注意，是“至少”，你搞三个主节点，每个主节点配一个从节点，这是最低配置，为什么不能少？因为集群要正常运作并且能容忍故障，需要大多数节点同意，如果你只有两个主节点，挂掉一个，剩下一个节点无法形成“大多数”（2个里面的多数是2，但只剩1个了），集群就挂了，三个主节点的话，挂掉一个，剩下两个还能形成多数（3个里面的多数是2），集群还能正常选举和故障转移，节点数量是基础，不能抠门。

第二，主从别放一台机器，甚至别放一个机柜。 （来源：运维血泪教训） 这是最最最经典的错误，有些人为了省资源，把一对主从节点部署在同一台物理服务器上，这下好了，这台服务器万一出点硬件故障，比如断电、硬盘坏了，主节点和它的从节点瞬间一起玩完，这个分片的数据就彻底丢失了，因为没人能接替它，高可用就成了空话，正确的做法是跨机架、跨可用区（如果是在云上）部署，主节点在A机房，它的从节点就放到B机房，这样，哪怕整个A机房断电了，B机房的从节点还能顶上来，保证服务不中断，这叫“容灾”。

第三，哨兵（Sentinel）也得做成集群，并且独立部署。 （来源：Redis作者Antirez的博客及社区建议） Redis集群的高可用依赖于一种叫“哨兵”的机制，哨兵负责监控主节点是否活着，如果发现主节点挂了，就赶紧组织投票，让它的从节点上位成为新的主节点，这么重要的“裁判”，你自己想想，能只部署一个吗？肯定不行，哨兵本身也必须是一个集群，通常建议至少部署三个哨兵实例，这三个哨兵最好也别和Redis主从节点挤在同一台机器上，因为如果某台机器挂了，上面既有Redis节点又有哨兵节点，可能会影响哨兵集群的判断能力，让哨兵独立出来，它的判断才更客观、更可靠。

第四，给Redis留足“体力”，别把内存和CPU用得太满。 （来源：生产环境性能调优经验） 很多人觉得Redis快，就拼命往里塞数据，把内存用到90%甚至95%以上，这是非常危险的，内存快满了，Redis本身操作就会变慢，可能触发内部清理操作，影响性能，更重要的是，当主节点故障，从节点要接替它的时候，新主节点需要和客户端建立连接、同步数据（如果还有没同步完的），这个过程本身需要额外的内存和CPU资源，如果此时机器资源已经告急，很可能导致故障转移失败，或者转移后新主节点性能极差，服务一样不可用。一般建议内存使用率控制在70%-80%以下，给突发情况留出余量，CPU也是同理。

第五，网络是命根子，稳定大于一切。 （来源：分布式系统通用原则） Redis集群节点之间、客户端和集群之间，需要频繁地通信（心跳检测、数据同步、命令转发），网络一旦出现严重延迟或者丢包，就会出大问题，哨兵可能因为网络波动误判主节点挂了，然后发起一次不必要的故障转移，这个过程本身就会导致服务短暂不可用，这叫“脑裂”风险，确保你的集群节点都在一个网络质量好、延迟低、带宽够的内网环境里，避免跨地域部署集群，因为公网延迟是不可控的。

第六，监控和报警是“守夜人”，不能没有。 （来源：所有SRE工程师的共识） 你以为配置好了就一劳永逸了？不行，你必须有一套监控系统，像守夜人一样时刻盯着集群，要监控哪些东西呢？节点是否存活、内存使用率、CPU使用率、网络流量、连接数、延迟时间、故障转移的次数等等，一旦有任何指标出现异常，比如内存使用率持续飙升、某个节点网络延迟突然变大，报警系统要能立刻通知到运维人员，这样才能在问题酿成大祸之前，提前介入处理，没有监控的集群，就像在黑夜中裸奔，什么时候掉坑里都不知道。

定期做“消防演习”。 （来源：Netflix等大型互联网公司的混沌工程实践） 光有理论不行，得真刀真枪地试一下，定期在业务低峰期，主动模拟一些故障，手动杀掉一个主节点进程，看看哨兵能不能在预期时间内完成故障转移，业务应用有没有受到影响，影响时间有多长，或者，给一台机器加大负载，看集群的表现，这个过程叫“混沌工程”，通过演习，你才能真实地验证你的高可用方案是否有效，同时让运维团队熟悉故障处理流程，真出事的时候才不会慌。

搞定Redis高可用集群,不是一个配置项的事情，而是一个系统工程，从节点规划、部署架构、资源规划、网络保障，到后期的监控预警和故障演练，每一个环节都不能掉以轻心，把这些都做到了，你的Redis集群才能真正地扛住压力，在关键时刻不掉链子。