一文解读 redis 主从/哨兵/集群架构

主从

主从结构示意图:一文解读 redis 主从/哨兵/集群架构_第1张图片

主从架构搭建,配置从节点:

  1. 复制 redis.conf 文件,并修改如下配置port 8001pidfile /var/redis_8001.pidlogfile 8001.logdir /usr/local/redis_8001/data
  2. 配置主从配置replicaof 172.0.0.1 8002replica-read-only yes
  3. 根据配置文件启动redisredis-server redis.conf

主从结构工作原理

master-slave数据同步过程:

全量同步:slave会发送一个PSYNC命令给master,master接收到该命令后,会立即进行持久化操作,通过命令bgsava生成一个RDB快照文件,持久化期间,如果客户端仍在写入数据,这部分数据会被保存在内存缓冲区(repl buffer)中,持久化完成以后,master会将RDB文件发送给slave,slave 将数据加载到内存中,然后master会将缓冲区的命令发送给slave节点。一文解读 redis 主从/哨兵/集群架构_第2张图片

断点续传:当master和slave由于某些原因断开时,slave重新连接时,会发送 PSYNC(offset) 包含一个下标的命令,表示断开之前同步到了哪儿。master节点在写入数据时,会将数据写入一个缓冲区(repl backlog buffer),当master接受到 PSYNC(offset) 命令时,会先去查看offset是否在缓冲区,如果在缓存区,会将offset后面的命令发送给slave,否则直接进行一次全量同步一文解读 redis 主从/哨兵/集群架构_第3张图片 

主从结构可能发生的问题:

主从复制风暴:多个从节点同时宕机重启后,全部需要进行全量同步,导致master节点压力过大

解决方案: 将将从节点挂载在某个从节点上,数据同步也从这个从节点复制。一文解读 redis 主从/哨兵/集群架构_第4张图片

哨兵模式

哨兵模式结构示意图:一文解读 redis 主从/哨兵/集群架构_第5张图片

哨兵模式搭建,配置哨兵

  1. 复制 sentinel.conf 文件到conf目录,并修改如下配置port 26379daemonize yespidfile "/var/run/redis-sentinel.pid"logfile "redis_sentinel_26379.log"dir "/home/redis/redis-6.0.9/sentinel_26379"sentinel monitor mymaster 172.19.14.57 6379 2
  2. 启动哨兵src/redis-sentinel conf/sentinel.conf

哨兵的工作原理

sentinel 哨兵是特殊的redis服务,他不对外提供读写服务,只用于监控主从结构的状态。
哨兵模式下,client端第一次连接哨兵找出redis主节点并缓存到本地,之后直接访问redis主节点。
当redis节点状态发生改变,sentinel哨兵会第一时间感知到,并将新的主节点推送给客户端。(client端订阅sentinel,一有变动直接推送)

哨兵leader选举流程
当一个 master 服务器被某 sentinel[哨兵]视为下线状态后,该sentinel[哨兵] 会与其他 sentinel[哨兵] 协商选出新的master,进行故障转移工作。

每个发现master服务器进入下线状态的sentinel[哨兵]都可以要求其他sentinel[哨兵]选自己为“本次决策”的leader,选举是先到先得。

同时每个sentinel每次选举都会自增配置纪元(选举周期),每个纪元中只会选择一个sentinel的leader。如果所有超过一半的sentinel选举某sentinel作为leader。

之后由该sentinel[哨兵leader]进行故障转移操作,从存活的slave中选举出新的master,这个选举过程跟集群的master选举很类似【请查看下面redis集群模式的选举】。哨兵集群只有一个哨兵节点,redis的主从也能正常运行以及选举master,如果master挂了,那唯一的那个哨兵节点就是哨兵leader了,可以正常选举新master。不过为了高可用一般都推荐至少部署三个哨兵节点。为什么推荐奇数个哨兵节点原理跟集群奇数个master节点类似。

哨兵模式其实就是主从结构上加了一个哨兵,所以数据同步原理和主从结构一致

哨兵模式可能发生的问题:

访问瞬断:在主节点宕机时,哨兵会发起选举。在选举过程中,如果客户端发起请求,会发生异常。当主节点重新选举出来,又会恢复。该问题在哨兵模式下无法避免。

redis集群架构

集群图示:一文解读 redis 主从/哨兵/集群架构_第6张图片

集群搭建

  1. 复制 sentinel.conf 文件到 redis_cluster/8001/redis.conf 目录,并修改如下配置port 8001daemonize yes ######## 守护进程pidfile /var/run/redis_8001.piddir /usr/local/redis-cluster/8001/replica-read-only yes ######## 从节点只读appendonly yes #######开启AOFcluster-enabled yes ########开启集群模式cluster-config-file nodes-8001.conf ########### 集群信息cluster-node-timeout 15000 ############ 集群master 节点失联多久开始选举requirepass zhouxh_z ########当前主机密码masterauth zhouxh_z ########访问其他主机密码
  2. 启动集群节点src/redis-server redis_cluster/8001/redis.conf
  3. 集群配置src/redis-cli -a zhouxh --cluster create --cluster-replicas 1 172.19.14.57:8001 172.19.14.57:8002 172.19.14.57:8003 172.19.14.57:8004 172.19.14.57:8005 172.19.14.57:8006
  4. 连接客户端src/redis-cli -a zhouxh -c -h 172.19.14.57 -p 8001
  5. 查看集群信息cluster info
  6. 查看节点列表cluster nodes

集群原理

集群下的每个小节点的同步复制,和主从一致。

槽位

并不是真实的物理空间,是一个虚拟的概念。
redisCluster 将内存虚拟划分为16384个槽位,分别分配到各个master节点中。redis在存储数据时,会对key进行Hash算法在对16383取余确保,key值必定存在集群槽位上。一文解读 redis 主从/哨兵/集群架构_第7张图片

取余算法

hash(key) = CRC16(key) % 16383

跳转重定位

在集群模式下,在客户向一个redis节点发起操作命令(如 set key value),会通过取余算法计算对应的槽位,如果发现对应的槽位不在目前节点上时,会自动进行跳转重定向。

如下:原本在 8001 端口的redis,发起set操作,通过取余算法计算key,发现zhouxh_1应该命中 8002 端口的redis所在的槽位,reids进行跳转重定向,自动将值set到了对应的槽位,并跳转到了8002 端口

 

网络抖动

网络波动可能导致部分master节点在短时间内连接不上,如果不进行限制,可能会发生频繁选举,进而导致脑裂问题。

cluster-node-timeout 15000
该配置可以使master节点在失联15000后,再进行选举。有效避免频繁选举问题

脑裂问题* 面试常问

由于网络问题导致master节点和其他节点断开连接,此时master(旧)节点并没有宕机,但是其他节点认为它已经宕机了,此时slave节点将发起选举,产生一个新的master(新)节点。此时存在两个master节点,客户端认为两个master节点都正常工作,此时会向这两个master节点写入数据。当网络重新连接时,由于存在两个master节点,此时集群会将master(旧)设置为从节点(slave),挂载到master(新)上,此时从节点相当于重启,需要从master节点同步数据,这就导致了之前客户端认为正常写入(master【久】)的数据丢失了。 解决方法:设置半数写入配置
min‐slaves‐to‐write 1
半数写入:即一半的节点认为写入成功才算成功
这里的 ”1“ 可变,计算方式:(小的主从节点数-1)/2

redis选举原理* 面试常问

  1. 当slave发现自己的master节点 挂了(fail)
  2. 将自己记录的集群 currentEpoch 加1,并广播 FAILOVER_AUTH_REQUEST 信息
  3. 其他节点接收到消息后,由主节点回复 FAILOVER_AUTH_ACK 信息,每个master节点只能发送一次
  4. 对应的slave节点,收集并统计 FAILOVER_AUTH_ACK 信息。
  5. 当收集到超过半数的ACK信息后,该节点自动升级为master节点。
  6. master(新)会播Pong消息通知其他集群节点,”我已经成功上位,你们可以歇歇了,赶紧更新你们的配置“。

第1步结束后,第2两步并不是马上执行,中间会有一个延迟时间,每个slave节点的延迟时间不同。
计算规则:500ms + random(0 ~ 500ms) + SLAVE_RANK * 1000ms
SLAVE_RANK:表示此slave已经从master复制数据的总量的rank。Rank越小代表已复制的数据越新。这种方 式下,持有最新数据的slave将会首先发起选举(理论上)。

你可能感兴趣的:(编程,Java,程序员,redis,架构,数据库)