Redis集群搭建和存储方案聊聊，奇数节点好像更靠谱点吧

咱们先别想那些复杂的术语，就把Redis集群想象成一个小团队，这个团队的任务是安全地保管一大堆数据，并且要保证即使有一两个同事请假（节点宕机），团队依然能正常运转，不丢数据，还能继续干活,这就是搭建集群的核心目标。

集群是怎么“搭”起来的？

搭建一个Redis集群，本质上就是让多个Redis实例（也就是多个服务器进程）互相认识，组成一个团队，然后商量好怎么分活儿,这个过程大概分几步：

1. 准备好几个“人”（节点）：你得先有几台服务器，每台上面都运行一个Redis实例，这些实例一开始都是孤立的,谁也不认识谁。
2. 让它们“握手”认识：通过一个简单的命令，告诉其中一个实例：“你去跟另外几个家伙联系一下，以后咱们就是一伙的了。”它们之间会建立连接,开始通信。
3. 分配“工作”（数据分片）：这是最关键的一步，整个数据仓库非常大，不能把所有东西都堆在一个人那里，所以团队要分活儿，Redis集群采用了一种叫“哈希槽”的方式来分活，你可以把整个数据仓库想象成有16384个抽屉（这就是哈希槽），团队组建成功后，会公平地把这16384个抽屉分配给每个在线的成员，有3个节点，可能就每人分 roughly 5461个抽屉，当客户端要存一个数据时，会根据数据的key算出一个号码，这个号码对应到其中一个抽屉，那么这个数据就存到负责这个抽屉的节点上，这样一来,数据和压力就均匀分散了。
4. 设立“备份”机制（主从复制）：光分活儿还不够，万一某个同事突然生病了（节点宕机），他负责的抽屉不就没人管了吗？数据就可能丢失，团队要实行“AB角”制度，每个干活的节点（称为主节点）都配一个或多个备份节点（称为从节点），主节点干什么，从节点就默默地跟着学，保持数据同步，这样，一旦主节点宕机，从节点就能马上顶上去，接替它的工作,保证那些抽屉还有人管。

为什么说“奇数节点”更靠谱？

这个话题的核心在于集群的“决策机制”，也就是故障转移：如何判断一个主节点真的挂了？以及挂掉之后,让哪个从节点来顶替它？

这个决策不能由一两个节点说了算，那样容易产生误判，可能只是网络有点问题，A节点联系不上主节点了，但B节点还能联系上，如果A节点自己就断定主节点挂了并启动切换,就会造成混乱。

Redis集群采用了一种“投票表决”的机制，有点像陪审团，它要求：必须要有超过半数的节点都认为某个主节点失效了，才能正式判定它失效，然后才能启动故障转移流程。

现在我们来看看节点数量不同会带来什么区别：

• 假设我们用2个节点组建集群：总节点数是2。“半数以上”是多少？2的一半是1，“以上”就意味着至少需要2票同意，也就是说，必须两个节点都认为主节点挂了才行，但如果真的有一个节点宕机了，剩下的那个节点只有1票，永远无法满足“超过半数”（即2票）的要求，它就没办法自己决定启动故障切换，整个集群就卡住了，无法自动恢复,所以2个节点无法构成有弹性的集群。

• 假设我们用3个节点组建集群：总节点数是3。“半数以上”就是至少2票，这样，即使宕机了一个节点，剩下的两个节点还能凑够2票，可以正常地投票决定是否进行故障转移，集群的容错能力是1（允许坏1个）。

• 假设我们用4个节点组建集群：总节点数是4。“半数以上”就是至少3票，集群允许宕机几个节点呢？如果只宕机1个，还剩3个，能凑够3票，没问题，但如果宕机2个，剩下的2个节点就无法凑够3票了，集群又会陷入无法决策的僵局，4个节点的容错能力其实还是1（允许坏1个）,但它比3个节点多花费了一台服务器的成本。

  

• 再比如，用5个节点：总节点数5，“半数以上”是3票，它允许宕机2个节点（剩下3个，能凑够3票）,容错能力是2。

对比一下就很清楚了：

• 3节点集群：容错1台,成本3台。
• 4节点集群：容错1台,成本4台。
• 5节点集群：容错2台,成本5台。

你看，4节点集群相比3节点集群，成本增加了，但容错能力并没有提升，还是只能坏1台，从效率和成本的角度看，它就显得“不划算”了，而3、5、7这样的奇数个节点，能够在给定的节点数量下，提供最大的容错能力，避免了资源的浪费，这就是为什么在分布式系统（不仅仅是Redis）中，推荐使用奇数个节点的主要原因,它是在可靠性和成本之间一个非常优雅的平衡点。

总结一下

聊到这里，关于Redis集群和奇数节点的门道就比较清楚了，搭建集群就是为了高可用和扩展性，通过数据分片和主从复制来实现，而奇数节点的推荐，根源在于那种“超过半数”的投票决策机制，它能最经济有效地利用服务器资源，换来更高的可靠性，在实际生产中，具体用3个、5个还是更多，还得看你的数据量、访问量和可接受的故障程度来综合决定。