Redis cluster集群模式介绍

---

title: Redis cluster集群模式介绍
categories: 数据库
tags: Redis

---

一、Redis主从概念

​ 为了避免单点故障，通常的做法是将数据库复制多个副本以部署在不同的服务器上，这样即使有一台服务器出现故障，其他服务器依然可以继续提供服务。为此， Redis 提供了复制（replication）功能，可以实现当一台数据库中的数据更新后，自动将更新的数据同步到其他数据库上。

​ 在复制的概念中，数据库分为两类，一类是主数据库（master），另一类是从数据库（slave）。主数据库可以进行读写操作，当写操作导致数据变化时会自动将数据同步给从数据库。而从数据库一般是只读的，并接受主数据库同步过来的数据。一个主数据库可以拥有多个从数据库，而一个从数据库只能拥有一个主数据库。

二、为什么要有集群？

​ redis的哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台redis服务器都存储相同的数据，很浪费内存，所以在redis3.0上加入了cluster模式，实现的redis的分布式存储，也就是说每台redis节点上存储不同的内容。

三、数据分布算法

3.1 hash算法

​ 哈希算法的思想非常简单，也许你知道 HashMap 的哈希函数，哈希算法跟 HashMap 一样，也是通过一个哈希函数得到某一个数字，然后根据数字找到相应的服务器。

​ 比如有N个redis实例，那么如何将key映射到redis上呢？

​ 通常是采用hash算法计算key的hash值，然后通过取模，均匀的映射到N个redis服务器上，如果增加一个服务器，那么映射公式就变成了hash(key)%(N+1)，如果有一个服务器宕机了，映射公式变成了hash(key)%(N-1)

​ 这种情况下，几乎所有的缓存都失效了，会导致数据库访问的压力陡增，甚至导致数据库宕机

3.2 一致性hash算法

​ 一致性哈希算法可以说是哈希算法的升级版，解决了哈希算法扩展性差的问题，一致性哈希算法跟哈希算法不一样，一致性哈希算法会将服务器和数据都通过哈希函数映射到一个首尾相连的哈希环上

具体步骤如下：

1. 首先求出服务器（节点）的哈希值，并将其配置到0～232的圆（continuum）上。
2. 然后采用同样的方法求出存储数据的键的哈希值，并映射到相同的圆上。
3. 然后从数据映射到的位置开始顺时针查找，将数据保存到找到的第一个服务器上。如果超过2的32次方仍然找不到服务器，就会保存到第一台服务器上。
   
   

可能存在的问题：

​ 一个master宕机不会导致大部分缓存失效，可能存在缓存热点问题 ，比如某个区间的值特别多没那么会导致大量的数据都涌入一个服务器内，造成缓存热点问题，出现性能瓶颈

3.3 用虚拟节点改进的一致性hash算法

​ 缓存热点问题是在服务器节点数非常少的时候容易出现，因此，我们通过添加虚拟节点的方式，来使的服务器节点数变多，从而大量数据均匀分布，而不是涌入到一个服务器内

3.4 rediscluster的hash slot算法

​ redis cluster中每个master都会持有部分slot，比如有3个master，那么可能每个master持有5000多个hash slot 。hash slot让node的增加和移除很简单，增加一个master，就将其他master的hash slot移动部分过去，减少一个master，就将它的hash slot移动到其他master上去

​ 客户端的api，可以对指定的数据，让他们走同一个hash slot，通过hash tag来实现

​ 客户端向节点发送键命令，节点要计算这个键属于哪个槽。如果是自己负责这个槽，那么直接执行命令，如果不是，向客户端返回一个MOVED错误，指引客户端转向正确的节点。

四、节点间的通信机制

1.基础通信

（1）redis cluster节点间采取gossip协议进行通信

跟集中式不同，不是将集群元数据（节点信息，故障，等等）集中存储在某个节点上，而是互相之间不断通信，保持整个集群所有节点的数据是完整的

集中式：好处在于，元数据的更新和读取，时效性非常好，一旦元数据出现了变更，立即就更新到集中式的存储中，其他节点读取的时候立即就可以感知到; 不好在于，所有的元数据的跟新压力全部集中在一个地方，可能会导致元数据的存储有压力

gossip：好处在于，元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上去更新，有一定的延时，降低了压力; 缺点，元数据更新有延时，可能导致集群的一些操作会有一些滞后

（2）10000端口

每个节点都有一个专门用于节点间通信的端口，就是自己提供服务的端口号+10000，比如7001，那么用于节点间通信的就是17001端口

每隔节点每隔一段时间都会往另外几个节点发送ping消息，同时其他几点接收到ping之后返回pong

（3）交换的信息

故障信息，节点的增加和移除，hash slot信息，等等

2. gossip协议

1. meet: 某个节点发送meet给新加入的节点，让新节点加入集群中，然后新节点就会开始与其他节点进行通信

2. ping: 每个节点都会频繁给其他节点发送ping，其中包含自己的状态还有自己维护的集群元数据，互相通过ping交换元数据 每个节点每秒都会频繁发送ping给其他的集群，ping，频繁的互相之间交换数据，互相进行元数据的更新

3. pong: 返回ping和meet，包含自己的状态和其他信息，也可以用于信息广播和更新

4. fail: 某个节点判断另一个节点fail之后，就发送fail给其他节点，通知其他节点，指定的节点宕机了

五、redis cluster 的高可用与主备切换原理

redis cluster 的高可用的原理，几乎跟哨兵是类似的。

5.1 判断节点宕机

如果一个节点认为另外一个节点宕机，那么就是 pfail，主观宕机。如果多个节点都认为另外一个节点宕机了，那么就是 fail，客观宕机，跟哨兵的原理几乎一样，sdown，odown。

在 cluster-node-timeout 内，某个节点一直没有返回 pong，那么就被认为 pfail。

如果一个节点认为某个节点 pfail 了，那么会在 gossip ping 消息中，ping 给其他节点，如果超过半数的节点都认为 pfail 了，那么就会变成 fail。

5.2 从节点过滤

对宕机的 master node，从其所有的 slave node 中，选择一个切换成 master node。

检查每个 slave node 与 master node 断开连接的时间，如果超过了 cluster-node-timeout * cluster-slave-validity-factor，那么就没有资格切换成 master。

5.3 从节点选举

每个从节点，都根据自己对 master 复制数据的 offset，来设置一个选举时间，offset 越大（复制数据越多）的从节点，选举时间越靠前，优先进行选举。

所有的 master node 开始 slave 选举投票，给要进行选举的 slave 进行投票，如果大部分 master node（N/2 + 1）都投票给了某个从节点，那么选举通过，那个从节点可以切换成 master。

从节点执行主备切换，从节点切换为主节点。

5.4 与哨兵比较

整个流程跟哨兵相比，非常类似，所以说，redis cluster 功能强大，直接集成了 replication 和 sentinel 的功能。

参考

部分文字参考链接：https://www.nowcoder.com/discuss/364714?type=post&order=time&pos=&page=0

图片为作者所绘制，不存在参考