聊聊Redis集群搭建及选举原理

聊聊Redis集群搭建及选举原理

redis集群简述

哨兵模式中如果主从中 master宕机了，是通过哨兵来选举出新的master，在这个选举切换主从的过程，整个redis服务是不可用的。而且哨兵模式中只有一个主节点对外提供服务，因此没法支持更高的并发。而且当个主节点的内存设置也不宜过大。否则会导致持久化文件过大，影响数据恢复或主从同步的效率。

redis集群是由 一系列的 主从节点群组成的分布式服务器群，它具有复制、高可用和分片特性。 Redis集群不需要 sentinel哨兵也能完成节点移除和故障转移的功能。需要将每个节点设置成集群模式，这种集群模式没有中心节点 ，客户端通过 CRC16算法对key进行hash

得到一个值，来判断该 key存储在哪个主从服务上面，因此就算是某一个主从整个宕机，redis集群也是部分可用的。方便 水平扩展， 可以根据业务规模可以随时加减配置。 据官方文档称可以线性扩展到上万个节点 ( 但是 官方推荐不超过 1000个节点)。redis集群的性能和高可用性均优于哨兵模式 。

Redis 集群搭建

1. 修改 redis.conf 配置文件

daemonize yes 后台启动cluster-enabled yes 开启集群模式cluster-config-file nodes-6379.conf 集群配置信息存放文件名cluster-node-timeout 5000 节点离线时间限制，到达此值时发起某个主从重新选举 masterprotected-mode no 关闭保护模式requirepass xxx 设置本机密码masterauth xxx 设置访问别的机器的密码

2. 注意关闭服务器的防火墙，否则可能造成节点之间无法通信，无法搭建集群

使用修改好的配置文件启动 redis 服务，我这里使用三个一主一从来搭建。因此先将 6 个 redis 服务使用指定的配置文件 redis-master.conf 启动起来： src/redis-server redis-master.conf

3.搭建集群服务

为了保险起见最好先检查下每台机器的 redis 服务是否正常启动了 ps -ef|grep redis

可以看见 redis 服务进程后面有个 cluster 的标志，普通启动的 redis 服务是没有这个标志的

5.0 版本可以直接使用 C 语言客户端提供的指令去构建集群：

src/redis-cli -a xxx --cluster create --cluster-replicas 1 192.168.0.67:6379 192.168.0.68:6379 192.168.0.69:6379 192.168.0.70:6379 192.168.0.71:6379 192.168.0.72:6379

-a 配置的密码

--cluster create 表示集群创建

--cluster-replicas 表示每个 master 几个 slave ，上面一共 6 个 redis 节点，因此会构建三个一主一从。

执行命令之前，如果你的 redis 环境以前搭建过主从或者哨兵之类的，数据不干净可能会报错，最好将持久化文件删掉，然后 flushdb ，将以前脏数据清理掉，否则可能出现如下错误：

正常执行会返回一个集群分配计划，我们按照它的计划即可：

然后节点之间就开始通信构建集群，最后会看见 16384 个 slots 分配完毕，可以看见构建计划中有三个 master ，每个 master 都是有指定槽位的。意思就是存入的 key 经过 crc16 hash 算法之后得到的值，在哪个范围内，就存储到那个 redis 主从上面去，这就是 redis 的分片集群模式。

至此集群搭建完毕

4.集群操作

以集群方式连接 redis 客户端通过 cluster info 查看集群信息，通过 cluster nodes 查看节点信息

src/redis-cli -a 密码 -c 集群方式连接

我们设置 set abc 123 一个值 会看见客户点会计算 abc 的 slot 是 7638 ， 然后重定向到对应的主从的 master 上面去写数据

现在我看下 java 客户端的 jedis 里面的 key 值计算 redis.clients.util.JedisClusterCRC16#getSlot(java.lang.String) ：

最后计算结果就会落到 0-16383 之间去。

当 Redis Cluster 的客户端来连接集群时，它也会得到一份集群的槽位配置信息并将其缓存在客户端本地。这样当客户 端要查找某个 key 时，可以直接定位到目标节点。同时因为槽位的信息可能会存在客户端与服务器不一致的情况，还需 要纠正机制来实现槽位信息的校验调整。

集中式集群和分片式集群

Redis 节点之间使用的是 gossip 协议进行通信，每个节点之间都会互相通信。

gossip 协议包含多种消息，包括 ping ， pong ， meet ， fail 等等。

ping ：每个节点都会频繁给其他节点发送 ping ，其中包含自己的状态还有自己维护的集群元数据，互相通过 ping 交换元数据;

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

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

meet ：某个节点发送 meet 给新加入的节点，让新节点加入集群中，然后新节点就会开始与其他节点进行通信，不需要发送形成网络的所需的所有 CLUSTER MEET 命令。发送 CLUSTER MEET 消息以便每个节点能够达到其他每个节点只需通 过一条已知的节点链就够了。由于在心跳包中会交换 gossip 信息，将会创建节点间缺失的链接。

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

就是自己提供服务的端口号 +10000 ，比如 6379 ，那么用于节点间通信 的就是 16379 端口。 每个节点每隔一段时间都会往另外几个节点发送 ping 消息，同时其他几点接收到 ping 消息之后返回 pong 消息。

还有就是集中式的，比如 ZK 集群

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

Redis 集群选举机制

当 slave发现自己的master变为FAIL状态时，便尝试 发起选举 ，以期成为新的 master。由于挂掉的master可能会有 多个 slave，从而存在多个slave竞争成为master节点的过程， 其过程如下：

1.slave发现自己的master变为FAIL

2.将自己记录的集群currentEpoch(选举轮次标记)加1，并广播信息给集群中其他节点

3.其他节点收到该信息，只有master响应，判断请求者的合法性，并发送结果

4.尝试选举的slave收集master返回的结果，收到 超过半数 master的统一 后变成新 Master

5.广播Pong消息通知其他集群节点。

如果这次选举不成功，比如三个小的主从 A,B,C组成的集群，A的master挂了，A的两个小弟发起选举，结果B的master投给A的小弟A1，C的master投给了A的小弟A2，这样就会发起第二次选举，选举轮次标记+1继续上面的流程。事实上从节点并不是在主节点一进入 FAIL 状态就马上尝试发起选举，而是有一定延迟，一定的延迟确保我们等待FAIL状态在集群中传播，slave如果立即尝试选举，其它masters或许尚未意识到FAIL状态，可能会拒绝投票。 同时下面公式里面的随机数，也可以有效避免slave同时发起选举，导致的平票情况。

延迟计算公式：

DELAY = 500ms + random(0 ~ 500ms) + SLAVE_RANK * 1000ms

SLAVE_RANK表示此slave已经从master复制数据的总量的rank。Rank越小代表已复制的数据越新。这种方式下，持有最新数据的slave将会首先发起选举(理论上)。

前面说到这种分片的集群模式的集群可以部分提供服务， 当 redis.conf的配置cluster-require-full-coverage为no时， 表示当一个小主从整体挂掉的时候集群也可以用，也是说 0-16383个槽位中，落在该主从对应的slots上面的key是用不了的，但是如果key落在其他的范围是仍然可用的。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。