Redis集群到底是啥，基础概念和那些你得知道的东西

Redis集群,说白了，就是当一台Redis服务器不够用的时候，把多台Redis服务器组合在一起，让它们像一个整体一样工作，你可以把它想象成一家餐厅，如果这家餐厅只有一名厨师（单个Redis服务器），客人点菜太多太杂的时候，厨师肯定会忙不过来，整个餐厅的效率就卡在厨师这里了，为了解决这个问题，餐厅老板决定开一家“分店”，这就是集群的基本想法。

但开分店不是简单地把两个餐厅并排开就行了,你得解决几个核心问题：怎么分配客人？怎么保证一家分店关门了不影响整个餐厅运营？后厨的食材（也就是数据）怎么同步？Redis集群就是来解决这些问题的。

数据是怎么分片的？

Redis集群用的是一种叫“哈希槽”的方法来分片，你可以把整个数据存储空间想象成一个大柜子，这个柜子有16384个固定的抽屉，每个抽屉都有一个编号，从0到16383，这就是16384个哈希槽。

当你存一个数据的时候,比如想存一个键值对 user:1001:name 等于 “张三”，Redis集群会用一个公式（CRC16算法）对这个键“user:1001:name”算一下，算出一个数字，然后把这个数字对16384取个余数，比如算出来是5000，那么这个数据就该放在编号5000的那个抽屉里。

这16384个抽屉怎么分配给不同的Redis服务器（在集群里叫“节点”）呢？在集群创建的时候，我们就可以规定好，我们有三个主节点（可以理解为三个主要的大厨）：

• 节点A负责管理抽屉0到5460。
• 节点B负责管理抽屉5461到10922。
• 节点C负责管理抽屉10923到16383。

这样一来,数据“user:1001:name”根据计算属于5000号抽屉，而5000号抽屉归节点A管，所以这个数据最终就会被存储到节点A上，客户端（点菜的客人）在读写这个数据的时候，集群会引导它去连接正确的节点，这种分片方式的好处是，数据被均匀地分散开了，每台机器只负责一部分压力。

集群怎么保证高可用？光有主厨还不够，万一主厨生病了怎么办？

这就是“主从复制”的概念，上面说的节点A、B、C都是“主节点”，是干活的骨干，为了保证他们任何一个出问题时餐厅还能运转，Redis集群给每个主节点都配了至少一个“从节点”，从节点就像是主厨的副手或者徒弟。

主节点负责写数据（接受新的点单），同时会把所有写操作同步给它的从节点，所以从节点上的数据和主节点是完全一样的，只是它平时不处理写请求，主要用来读（比如客人问这道菜辣不辣，副手可以回答），更重要的是作为备份。

如果主节点A突然宕机了（比如主厨食物中毒送医院了），集群会自动检测到这个问题，主节点A对应的那个从节点（副手）就会挺身而出，被“提拔”成新的主节点，接管原来主节点A负责的所有抽屉（哈希槽），这样，整个集群就还能继续提供服务，只是现在只剩下两个主节点和它们的从节点在干活了，这个过程叫“故障转移”，等原来的主节点A修好了重新上线，它会自动变成新主节点的一个从节点。

客户端是怎么跟集群打交道的？

客户端（比如你的应用程序）不需要知道所有节点的地址，只需要知道集群中少数几个节点的地址就行，当客户端第一次连接集群时，它会获取一份“槽位配置图”，这张图清楚地记录了哪个抽屉归哪个节点管。

之后,当客户端要读写一个键时，它会自己先算一下这个键属于哪个槽，如果它发现这个槽正好在自己当前连接的节点上，就直接操作，如果算出来这个槽在另一个节点上，当前节点会告诉客户端：“这个数据不归我管，你去连接某某地址的节点吧”，并返回一个“重定向”指令，客户端就会根据这个指令去连接正确的节点进行操作，这种设计使得集群的扩展性很好，增加或减少节点时，只需要更新一下槽位配置图，客户端能自动适应。

一些你得知晓的注意事项：

1. 不是所有功能都支持：在集群模式下，由于数据是分片存储的，那些需要同时操作多个键的命令（比如两个集合的交集SINTER，或者事务MULTI中包含了不同节点的键）可能无法执行，除非这些键恰好都在同一个节点上（可以通过一种叫“哈希标签”的技巧强制让某些键分配到同一个槽）。
2. 需要客户端支持：你的应用程序使用的Redis客户端库必须是支持集群协议的，它要能理解上面说的重定向机制。
3. 网络要求高：集群的所有节点之间需要保持网络通畅，因为它们要互相通信，通过一种叫“Gossip”的协议来传递消息、检测节点是否存活。

Redis集群的核心就是为了解决大数据量和高并发下的性能和可用性问题,它通过分片来分摊数据和压力，通过主从复制和故障转移来保证服务不中断，理解了这个“开分店”的比喻和它背后的运作逻辑，你就抓住了Redis集群的精髓。 参考和整合了Redis官方文档关于集群的说明、以及《Redis设计与实现》等常见技术资料中对集群原理的通用解释）