Redis的主从架构以及哨兵高可用架构

一、Redis的主从架构

1、原理

在我们日常的业务开发中，经常会用到Redis，假设我们只有部署了一台Redis服务器，某个时刻Redis服务挂了，造成Redis不可用，在此期间，大量的请求将会直接打到数据库，数据库cpu飙升，严重的可能导致数据库直接挂掉，这就是我们经常说的单点故障。为了解决单点问题，一般都需要对redis 配置主从节点，那么redis主节点和从节点之间如何进行数据同步呢? Redis提供了主从复制机制。

1.1、redis读写分离

在redis主从架构中，Master节点负责处理写请求，Slave节点只处理读请求。对于写请求少，读请求多的场景，例如电商详情页，通过这种读写分离的操作可以大幅提高并发量，通过增加redis从节点的数量可以使得redis的QPS达到10W+。

1.2、redis主从同步

Master节点接收到写请求并处理后，需要告知Slave节点数据发生了改变，保持主从节点数据一致的行为称为主从同步，所有的Slave都和Master通信去同步数据也会加大Master节点的负担，实际上，除了主从同步，redis也可以从从同步，我们在这里统一描述为主从同步。

2、Redis主从节点复制数据的过程

2.1、数据全量复制

数据全量复制的意思是创建一了个新的从节点，从主节点将数据复制到过去的过程：
（1）从节点先跟master建立socket长连接，发送一个PSYNC命令给master请求复制数据。（不管第一次是否连接上）；
（2）master收到psync命令执行bgsave生成一个rdb快照文件。生成rdb文件的时候，这个过程中进行的一些修改的操作都在这里面放着。
（3）当持久化进行完毕以后，master会把这份rdb文件数据集发送给slave，slave会把接收到的数据进行持久化生成rdb，然后再加载到内存中
（4）master再将之前缓存在内存中的命令发送给slave
（5）后续的话，主节点执行一条命令，主节点就通知从节点也执行一条命令。
当master与slave之间的连接由于某些原因而断开时，slave能够自动重连Master，如果master收到了多个slave并发连接请求，它只会进行一次持久化，而不是一个连接一次，然后再把这一份持久化的数据发送给多个并发连接的slave。

2.2、数据部分复制

数据部分复制的请情况出现在从节点万一宕机了一段时间，过了一会我们又启动了从节点，这个时候我们希望同步的数据是宕机这段时间的数据，而不是全量的数据，所以就出现了数据部分复制。
（1）断开连接，因为这个链接可以已经不能用，需要重新断开再次连接。
（2）从节点宕机的这一段时间的数据操作都在这里面放着。
（3）重新建立socket长连接。
（4）发送一个psync(offest)，offset是上次同步数据坐标的偏移量。
（5）如果slave发送的offset在repl backlog中，则发送offset之后的数据给从节点，如果不在，则发送全量数据给从节点。
（6）后续的话，主节点执行一条命令，主节点就通知从节点也执行一条命令

3、主从复制风暴

主从复制风暴的意思是出现某一瞬间或者某一段时间，有大量的从节点要从主节点复制数据，主节点压力过大，所以我们可以将主从架构部署成如下树形结构，以缓解主节点压力，如下图所示：

4、从节点的搭建

1、复制一份redis.conf文件

2、将相关配置修改为如下值：
port 6380
pidfile /var/run/redis_6380.pid  # 把pid进程号写入pidfile配置的文件
logfile "6380.log"
dir /usr/local/redis-5.0.3/data/6380  # 指定数据存放目录
# 需要注释掉bind
# bind 127.0.0.1（bind绑定的是自己机器网卡的ip，如果有多块网卡可以配多个ip，代表允许客户端通过机器的哪些网卡ip去访问，内网一般可以不配置bind，注释掉即可）

3、配置主从复制
replicaof 192.168.0.60 6379   # 从本机6379的redis实例复制数据，Redis 5.0之前使用slaveof
replica-read-only yes  # 配置从节点只读

4、启动从节点
redis-server redis.conf

5、连接从节点
redis-cli -p 6380

6、测试在6379实例上写数据，6380实例是否能及时同步新修改数据

7、可以自己再配置一个6381的从节点

二、Redis哨兵高可用架构

1、简介

​ 当我们使用主从复制时，从库宕机依然可以将请求发送给主库或者其他从库，但是 Master 宕机，只能响应读操作，写请求无法再执行。所以主从复制架构面临一个严峻问题，主库挂了，无法执行「写操作」，无法自动选择一个 Slave 切换为 Master，也就是无法故障自动切换。

​ 哨兵是Redis的高可用性解决方案：由一个或多个Sentinel实例组成的Sentinel系统，可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器，然后由新的主服务器代替 已下线的主服务器继续处理命令请求。

哨兵的功能：
（1）监控：哨兵会不断地检查主节点和从节点是否运作正常。
（2）自动故障转移（核心功能）：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。
（3）配置提供者：客户端（从节点）在初始化时，可以通过连接哨兵来获得当前Redis服务的主节点地址。
（4）通知：哨兵可以将故障转移的结果发送给客户端。

2、Redis哨兵搭建

（1）复制一份sentinel.conf文件

cp sentinel.conf sentinel-26379.conf

（2）将相关配置修改为如下值：

# 设置对外的端口
port 26379
# 设置后台启动
daemonize yes
# 设置保存pid文件的路径
pidfile "/var/run/redis-sentinel-26379.pid"
# 设置日志文件的名称
logfile "26379.log"
# 设置工作目录，默认是当前目录，也就是运行redis-server时的命令，日志、持久化等文件会保存在这个目录
dir "/usr/local/redis-7.0.5/data"

核心配置：

# sentinel monitor <master-redis-name> <master-redis-ip> <master-redis-port> <quorum>
# quorum是一个数字，指明当有多少个sentinel认为一个master失效时(值一般为：sentinel总数/2 + 1)，master才算真正失效
sentinel monitor mymaster 192.168.0.60 6379 2   # mymaster这个名字随便取，客户端访问时会用到

（3）启动sentinel哨兵实例

src/redis-sentinel sentinel-26379.conf

（4）查看sentinel的info信息

src/redis-cli -p 26379
127.0.0.1:26379>info
# 可以看到Sentinel的info里已经识别出了redis的主从

3、哨兵leader选举流程

当一个master服务器被某sentinel视为下线状态后，该sentinel会与其他sentinel协商选出sentinel的leader进行故障转移工作。每个发现master服务器进入下线的sentinel都可以要求其他sentinel选自己为sentinel的leader，选举是先到先得。同时每个sentinel每次选举都会自增配置纪元(选举周期)，每个纪元中只会选择一个sentinel的leader。如果所有超过一半的sentinel选举某sentinel作为leader。之后该sentinel进行故障转移操作，从存活的slave中选举出新的master，这个选举过程跟集群的master选举很类似。
哨兵集群只有一个哨兵节点，redis的主从也能正常运行以及选举master，如果master挂了，那唯一的那个哨兵节点就是哨兵leader了，可以正常选举新master。
不过为了高可用一般都推荐至少部署三个哨兵节点。推荐奇数个哨兵节点的原理跟集群奇数个master节点类似。