Redis集群单台不行，单数台也有问题，咋整才靠谱呢

关于Redis集群到底用几台机器才靠谱这个问题，确实让很多人头疼，单台不行，这好理解，因为一旦这台机器出故障，整个缓存服务就瘫痪了，没有高可用性，但为什么说单数台也有问题呢？这主要源于Redis集群的“多数派”选举机制。

根据Redis官方文档（redis.io）中关于集群模式的说明，Redis集群采用了一种类似Raft的共识算法来实现故障转移，这个机制的核心是：集群中的每个主节点都有一票投票权，当需要判断一个主节点是否真的失效（从而让它的从节点顶上去）时，剩下的健康主节点会进行投票，只有当超过半数的主节点认为某个主节点失效了,故障转移操作才会被批准执行。

这个“超过半数”的原则，就是导致单数台机器部署可能出问题的根源,我们来举个例子就明白了。

假设我们用一个非常小的集群，比如3台服务器，每台服务器上运行一个Redis主节点（为了简化，我们先不谈从节点），这样，整个集群一共有3个主节点，半数是1.5,超过半数就是至少2票。

• 正常情况：3台机器都健康,相安无事。
• 出现故障：假设其中1台机器（我们叫它节点A）因为网络问题或者宕机，与其他两个节点失联了。
  • 剩下的两个健康节点（节点B和节点C）会开始协商：“节点A是不是挂了？”
  • 它们俩一投票，总共3个主节点，现在有2票认为节点A挂了，2 > 1.5，超过了半数，集群顺利地将节点A标记为失效，如果节点A有从节点，那么这个从节点就会被提升为新的主节点，集群继续对外服务，你看，3台的情况下，允许1台故障,集群还能正常工作。

那问题出在哪儿呢？出在网络分区（俗称“脑裂”）这种更棘手的故障上，还是这个3节点的集群，假设不是某台机器宕机，而是发生了网络故障，导致3台机器被分割成了两个网络区域：比如节点A自己在一个区域,节点B和节点C在另一个区域。

• 在节点B和C看来：它们俩能互相联系，但联系不上节点A，于是和上面一样，它们有2票，超过半数，认定节点A失效，然后继续对外提供服务（比如接受写请求）。
• 但在节点A看来：它联系不上B和C，它觉得是B和C都挂了，现在整个集群有3个主节点，它自己只有1票，1票够不够半数（1.5）？不够，节点A没有资格认为自己还活着并继续提供服务，它会停止接受写请求，进入一种“自闭”状态，以此来保证数据的一致性,防止出现两个大脑都接受写入的混乱局面。

这样设计是为了避免数据冲突，是靠谱的，但如果我们把集群规模变成双数，比如4台服务器，部署4个主节点,情况就危险了。

假设4个节点也发生了网络分区，恰好分成2对2（比如节点A&B在一个区，节点C&D在另一个区）。

• 在A&B这个分区：总主节点数是4，半数是2，A&B手里有2票，刚好等于半数，但没有超过半数，它们没有权限判定C和D失效,因此自己也不能擅自成为主集群提供服务。
• 同样，在C&D那个分区，情况一模一样，也是2票，不超过半数,也无法行动。

结果就是，整个集群的两个部分都陷入了瘫痪，都无法提供服务，这就是“双数台”集群在遇到网络分区时可能导致的“僵局”问题。

到底咋整才靠谱呢？答案就是：使用至少3个主节点，并且部署成奇数台服务器，这并不是说机器数量必须是奇数，而是指有投票权的主节点数量最好是奇数，这样可以在容忍相同数量节点故障的前提下（比如3节点容忍1台故障，5节点容忍2台故障）,最大限度地避免上面提到的网络分区导致的僵局。

一个更具体且常见的靠谱部署方案是：使用至少6台服务器，部署一个包含3个主节点和3个从节点的Redis集群。

• 为什么是6台？ 这样保证了主节点数量是奇数（3个），每个主节点都配备一个从节点,实现高可用。
• 好处：
  1. 高可用：任何一台主节点宕机，它的从节点都能在另外两个主节点的投票同意下（2>1.5）迅速升级为主节点,服务中断时间极短。
  2. 避免脑裂僵局：3个主节点的投票机制，能有效应对网络分区，确保只有一个分区（拥有至少2个主节点的分区）能继续服务，另一个分区会自动停止服务,保证数据一致性。
  3. 性能与容量：3个主节点可以对数据进行分片存储,提升了整体缓存容量和并发处理能力。

总结一下，解决“单台不行，单数台也有问题”困惑的最直接、最靠谱的办法，就是遵循官方建议，搭建一个主节点为奇数（至少3个）且每个主节点都有从节点的集群，对于大多数场景，从3主3从（共6节点）的配置开始,就是一个非常稳健的选择。