Redis的高可用的原理及搭建

主从复制

redis通过一主多从的形式，将数据备份到各个从节点上，当主节点master宕机或者故障时，通过哨兵模式从slave节点中选择一个顶替master继续工作，避免了数据丢失，实现了redis的高可用，主从复制使得redis具备了较高的可扩展性和容错性的特点

image.png

作用

1、读写分离，分担redis读的压力：主从复制中master端主要负责写的操作，写入客户端输入的数据，同时将写入的数据同步到slave节点上，而slave节点主要负责读操作，master将读的流量分流到各个从节点上执行读操作，利用负载均衡的原理实现了redis分担读压力的效果
2、避免单点故障：避免单机故障后数据的丢失，通过哨兵模式从从节点中选出新的主节点
3、数据备份：将数据备份到各个从节点上，实现了数据备份

主从复制的策略

主从复制的方式使用的是RDB,复制的策略有以下两种

1、全量复制：

从节点初始化时，master通过bgsave的方式进行一次全量的复制操作形成一个RDB文件同时开启一个复制缓冲区记录从此时开始的所有写命令（如果从节点花费时间过长，将导致缓冲区溢出，最后全量同步失败），master将RDB文件和缓冲区数据传输到slave节点上，slave节点先清空节点上的数据然后再进行数据加载，在此之后redis会进行增量同步的模式，如果期间尝试增量失败的时候，还会再进行全量的复制

2、增量复制

master节点每执行一个写命令都会向slave节点发送相同的命令，slave节点接收并执行master的写命令

主从复制的搭建演示

由于条件有限，只能在一个节点上的演示主从复制，不多BB开干就完事了

进入redis的安装目录拷贝一个redis.conf并改名

image.png

先配置master节点，master节点的配置文件是redis.conf,编辑这个文件
开启守护进程，修改pid,日志文件名称，rdb文件名称，工作目录

image.png

接下来是slave节点的配置
为了方便，还是从刚刚修改过的redis.conf的基础上修改配置，

image.png

编辑redis6380.conf文件
修改端口、日志文件名称、rdb文件名称，主节点地址

image.png

启动6379 master节点,启动后查看6379端口redis是否启动成功

image.png

进入命令执行客户端，执行info查看6379的状态，我们看到这是个主节点

image.png

然后启动slave节点,启动后查看6380端口redis是否启动成功

image.png

进入命令执行客户端，执行info查看6380的状态，我们看到这是个主节点

image.png

我们看到这是个slave节点，并且master节点的ip端口是本机的6379，并且连接状态是up表示主从连接得通

image.png

到处我们的主从配置是完成了，我们去看看怎么玩这个主从复制

我们看看master和slave的数据全是空的

image.png

那我们给 master节点添加一些数据

image.png

我们看看slave节点会不会有相同的同步数据，结果是数据是同步过来了

image.png

我们在slave上添加数据会报错，证明了redis的从节点默认只能是有读操作

我们进入工作目录中可以看到生成的相应的log和rdb文件

我们看看这个6380.log的日志文件内容

image.png

从这个一段日志中我们可以看到了slave节点初始的过程，先是进行full resync全量的复制,然后flushing old data清理旧数据，loading db in memory加载数据然后完成

如果redis的master节点挂了，如果没有一些监控切换master的脚本的程序的话我们就得需要手动去发现和切换master,而redis sentinel就是为了解决这种问题而生产的。

redis sentinel:哨兵模式

sentinel是redis高可用的实现方案。sentinel是一个redis的独立进程，这个进程并不是用来存储数据，而是用来监控redis的各个主从节点并进行故障转移，sentinel本身也存在着单点故障的问题，所以sentinel也是有多个节点的，节点之间能相互监控和通信，当sentinel有发现redis宕机了，sentinel将会对master进行下线，从slave节点中选出一个master顶替

工作步骤：

一、监控任务：

1、10秒任务：每个sentinel会对master和slave每10秒发送info命令收集redis主从节点运行信息，以确定redis的主从关系

image.png

2、2秒任务：每个sentinel每两秒会通过发布订阅的方式在master内部名叫sentinel:hello的频道发布消息，sentinel们在这个频道发布自身的信息和自己的意见同时也获取其他sentinel的信息和意见，这个频道是sentinel信息交换的平台，其中节点故障判断、sentinel领导选举都是在这里进行，并且每个新加入的sentinel都会去订阅这个频道以获取其他sentinel的信息

image.png

3、1秒任务：每个sentinel会对其他的sentinel和每个redis节点进行ping，实际上就是一个心跳检测，同时也是sentinel主观下线的依据

image.png

二、主观下线和客观下线：

配置：
sentinel monitor mymaster 192.168.200.128 6379 2
sentinel down-after-milliseconds mymaster 3000
1、主观下线：在每个sentinel每秒对master进行ping操作，如果在设置时间内没有回应则被当前的sentinel认为是有问题的master,这只是某个sentinel对master的个人观点，称为主观下线。例如我们使用上面的配置，设定了3000毫秒内没有回应则认为此master故障了
2、客观下线：当其他的sentinel也认为这个master有问题，并且超过设定的数量法定人数则会进行客观下线。例如我们使用上面的配置，当到达两个sentinel都认为master有问题时，就会达成客观下线。这里法定人数的配置最后使用：法定人数=sentinel节点数量/2+1（sentinel节点的数量最好配置成奇数）

三、领导者选举：

当sentinel们达成了客观下线后就会进行投票，选举出一个领导者对master进行故障转移。当某个sentinel拿到了超过了半数的投票，将会成为领导者，如果有两个sentinel拿到了同样的票数都成为了领导者，将会进行重选

image.png

四、故障转移：

在选举出领导者的sentinel节点后，这个sentinel将会从slave中选择一个合适的master节点，怎么才叫做合适呢主要有以下几点：
1、选择slave-priority最高的slave节点（默认是相同）
2、选择复制偏移量最大的节点。
3、如果以上两个条件都不满足，选runId最小的（启动最早的）。
选出master节点后，sentinel会向剩余的slave节点发送命令让slave节点去复制这个新master,然后在通知客户端，master节点的改变，让客户端去连接新的master节点

sentinel搭建演示

（由于条件有限，搭建的sentinel和redis主从节点都是在同一台机器上）
我们看看这个配置的解释，这是我从网上找来的解释的挺好的

port 26379 #端口
daemonize yes #守护进程
#pid
pidfile /var/run/redis-sentinel26379.pid 
#工作目录
dir /usr/local/redis-5.0.0/data 
#日志文件
logfile "26379.log" 
 #sentinel主节点的名称
#mymaster 主节点 127.0.0.1 6379，2个sentinel检测到主节点有问题就进行故障转移
sentinel monitor mymaster 127.0.0.1 6379 2 
#30秒ping不同就认为主节点有问题
sentinel down-after-milliseconds mymaster 30000 
 #老的slave或者新的master进行复制，最多可以有多少个slave同时对新的master进行 同步，推荐1
sentinel parallel-syncs mymaster 1
 #故障转移时间
sentinel failover-timeout mymaster 180000

搭建基于我们已经搭建好的redis主从复制，master节点的端口是6379，slave的节点是6380和6381，创建两个文件夹 sentinel-data和sentinel-conf