分布式环境里怎么搞多节点Redis，性能和同步那些事儿

在分布式环境里使用多个Redis节点,主要是为了解决两个核心问题：一个是怕它“扛不住”，也就是性能瓶颈；另一个是怕它“挂掉”，也就是单点故障，这就像一家很火的餐厅，如果只有一个厨师（单个Redis节点），客人点菜多了（请求量大了），厨师就忙不过来，餐厅的响应就慢；万一这个厨师生病请假了（节点宕机），整个餐厅就直接停摆了，我们得请多个厨师，并且安排好他们的工作方式和协作机制。

最常见的多节点Redis方案有三种,它们各有侧重，像不同的“阵型”一样。

第一种阵型：主从复制（Master-Slave Replication）。 这个模式很简单，一主多从”。（来源：Redis官方文档对Replication的描述）只有一个节点是“主节点”，这个节点负责处理所有的写操作（比如新增、修改、删除数据），其他节点是“从节点”，它们的数据完全从主节点那里“复制”过来，平时只负责处理读操作。

• 同步那些事儿： 当主节点收到一个写命令后，除了自己执行，还会把这个命令发送给所有的从节点，从节点接收到命令后，在自己这边也执行一遍，这样就能保证主从之间的数据最终是一致的，这个过程是异步的，意思是主节点不会傻等着所有从节点都执行完才给客户端回应，而是立刻回应，然后再去同步，这样做性能很好，但有个小风险：万一主节点在命令发出后、从节点还没执行完的时候就宕机了，可能会丢失极小一部分最新的数据。
• 性能与可靠性： 这个模式最大的好处是“读写分离”，写请求全给主节点，读请求可以分散到多个从节点上，这样读的性能就大大提升了，如果主节点挂了，我们可以手动把一个从节点“提拔”成新的主节点，让服务恢复，这就解决了单点故障问题，但它没解决主节点的写性能瓶颈，因为所有写压力还是在一个节点上。

第二种阵型：Redis哨兵（Sentinel）。 主从复制有个麻烦事，就是主节点宕机后需要人工干预来切换主从，这既慢又容易出错，Redis哨兵就是来解决这个问题的“自动运维管家”。（来源：Redis官方文档对Sentinel的描述）哨兵本身不是一个Redis数据节点，而是一个或多个独立的守护进程（可以理解成小助手）。

• 同步那些事儿： 哨兵们的核心工作是“监控”主从节点集群，它们会不断地向主节点和从节点发送心跳包，检查它们是否还“活着”，如果大多数哨兵都认为主节点失联了，它们就会自动协商，然后从剩下的从节点中投票选出一个新的主节点，并通知其他的从节点连接这个新主节点，同时也会通知客户端现在的主节点地址变了，这一切都是自动化的，大大提高了系统的可用性。
• 性能与可靠性： 哨兵模式本质上是给主从复制模式加上了“自动故障转移”的能力，所以它在性能和读写分离上的特点和主从复制是一样的，它的主要贡献是让系统变得更“智能”、更“高可用”，减少了对人肉运维的依赖，但它依然没有解决写操作的集中性问题。

第三种阵型：Redis集群（Cluster）。 这是Redis官方提供的“终极”分布式方案，目标就是同时解决读和写两个方向的性能瓶颈，以及高可用问题。（来源：Redis官方文档对Cluster的描述）它的思路是“分片”，也叫“数据分片”。

• 同步那些事儿： Redis集群会把整个数据库分成16384个“槽位”，你可以想象成一个超大的书架被分成了16384个格子，集群中的每个主节点都负责管理一部分槽位，当客户端要存储一个数据时，集群会用一个算法根据数据的key计算出一个值，决定这个数据应该放在哪个槽位里，进而就知道该存到哪个主节点上，这样，写压力就被均匀地分摊到了不同的主节点上，每个主节点都会配备一个或多个从节点，形成一个个小规模的主从复制单元，保证每个分片的高可用。
• 性能与可靠性： 这是性能最强的方案，因为它实现了真正的分布式存储和计算，无论是读还是写，压力都可以水平扩展，通过增加主节点，就可以线性地提升集群的整体吞吐量，可靠性也非常高，任何一个主节点宕机，它对应的从节点就会在集群内部被自动提升为主节点，继续服务，它的搭建和配置也比前两种模式要复杂一些。

• 如果你只是想做个数据备份,或者单纯想提升读性能，主从复制就够了。
• 如果你希望主从复制能自动进行故障切换,不用半夜爬起来手动处理，那就加上哨兵。
• 如果你的业务量非常大,读写压力都很高，单个主节点已经成为瓶颈，那么你就需要采用Redis集群方案，把数据和压力分散开来。

选择哪种“阵型”，完全取决于你的实际业务对性能、数据可靠性和运维成本的要求，没有最好的，只有最合适的。