深入剖析Redis高可用集群架构原理

redis集群方案比较

1.哨兵模式架构

 

哨兵监控集群服务的各节点的健康状态，master解决写服务，down之后选举salve为主节点

问题：单台redis支持5w左右的并发，无法满足大并发的业务需求

master挂掉之后，在选举的过程中，不能响应写服务

节点内存有限，即内存瓶颈

2.高可用模式架构（redis3.0之后官方架构）

redis集群是一个由多个主从节点组成的分布式服务集群，它具有复制，高可用和分片的特性，Redis不需要sentinel哨兵也能完成节点移除和故障转移的功能，需要将每个节点部署为集群模式，这种集群模式没有中心节点，可以水平扩展，官方可线性扩展到1000个节点，Redis集群的性能和高可用性均优于之前版本的哨兵模式，且集群配置非常简单。

 

3.redis高可用搭建与使用

集群搭建：

自己测试搭建3个小集群，每个小集群都是一主两从架构

./redis-trib.rb create --replicas 2 192.168.1.101:6379 192.168.1.102:6379 192.168.1.103:6379 192.168.1.104:8001 192.168.1.104:8002 192.168.1.105:8001 192.168.1.105:8002 192.168.1.106:8001 192.168.1.106:8002

默认前面为主节点（16384个槽总共，不管有多少个master）

配置文件的主要修改：

a.daemonize yes 后台启动

b.port 6379 （若在伪集群下，需要修改这个端口号)

c. dir /home/redis-cluster/ (指定数据存放位置，伪集群下必须设置为不同 的地址， 不然会丢失数据)

d.cluster-enabled yes (启动集群模式)

e.cluster-config-file nodes-6379.conf(集群节点信息文件，最好和port对应上)

f.cluster-node-timeout 5000(监测集群节点不可用的时间)

g.appendonly yes (写日志文件)

具体的安装路径参考：https://www.cnblogs.com/xuliangxing/p/7146868.html

创建集群遇到的坑：

Sorry, can't connect to node 192.168.1.101:6379

修改redis.conf文件，将bind 127.0.0.1注释 protected-mode 模式设置为no

redis集群分片原理分析

redis cluster 采用虚拟槽分区，所有的键根据哈希函数映射到0~16383整数槽内，计算公式为:solt=CRC16(key)%16383，每一个节点负责维护一部分槽以及槽所映射的键值数据，每个集群之间是有心跳的，彼此之前知道所对应的分片槽

redis集群Master选举原理分析

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

1. salve发现自己的master变为FAIL
2. 将自己记录的集群的currentEpoch加1，并广播FAILOVER_AUTH_REQUEST信息
3. 其他节点收到该信息，只有master响应，判断请求者的合法性，并发送FAILOVER_AUTH_ACK，对每个epoch只发送一次ack
4. 尝试failover的salve收集FAIL_OVER_ACK,超过半数则成为master
5. 广播Pong通知其他集群节点