Redis的主从集群以及哨兵机制学习总结

为什么要使用主从集群？

我们项目中常常使用Redis来提高接口的性能和并发能力，但是单节点的并发能力并不是特别出众，并且如果节点宕机短时间内就无法工作。因此我们部署多个Redis实例，使用主从集群，包括一个主节点和多个从节点，主节点负责修改操作，从节点负责数据读取。

部署主从集群

我们通过以下命令指定主从节点：

# Redis5.0以前
slaveof <masterip> <masterport>
# Redis5.0以后
replicaof <masterip> <masterport>

主从集群怎么同步数据？

主节点负责修改数据，从节点负责读取数据，那么主节点需要向从节点同步数据，那么主从集群是怎么同步数据的？

数据同步的方式和时机

主从集群的数据同步方式有两种，分别是全量同步和增量同步，很简单理解，全量同步就是向从节点同步主节点的所有数据，而增量同步是向从节点同步主节点新增的数据即部分数据。
数据同步的时机：
当第一次同步数据时，会通过全量同步同步数据
当从节点宕机重启后，会通过增量同步同步数据
那么主节点怎么判断从节点是不是第一次同步数据呢？
通过

实例查看

开启三个实例，但是开启主从集群：

实例一：

实例二：

实例三：

开启主从集群后：

三个实例：

在还没有开启主从集时，我们发现三个实例的replid不同，开启主从后，实例二和实例三的replid变得和实例一一样

那么redis完全可以通过replid来判断有没有进行数据同步。

主从数据同步原理

当从节点向主节点发送数据同步的原理时，主节点会判断从节点replid是否和自己相同，如果不相同，说明没有进行数据同步，就会向从节点进行全量同步，如果相同，就会进行增量同步。
全量局部：全量同步是基于RDB持久化完成的，当主节点发现从节点的replid和自己不同时，会调用bgsave命令，创建一个子进程创建RDB快照，将快照发送给从节点，从节点删除本地所有数据通过RDB快照同步数据。
增量同步：主节点在缓存中有一个缓冲环即repl_baklog文件，如下图。主节点和从节点分别有自己的offset，即各自执行到的命令，当进行增量同步时，会根据其偏移量将从节点没有执行过的命令发送到从节点中

增量同步潜在的问题

当从节点宕机了，而主节点一直在写入命令，导致主节点覆盖了从节点还没有读到的指令，那么就会进行全量同步

全量同步毫无疑问很浪费性能，因此可以优化主从集群

主从集群的优化

1、在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步时的磁盘IO。
2、减少单节点的内存大小，当进行全量同步时数据同步更快
3、提高缓冲环的大小，防止由于主节点写入过快导致数据覆盖而进行全量同步
4、使用主-从-从的模型，减少主节点的从节点数量，降低主节点数据同步的压力

主节点宕机怎么办？

我们上面讲了从节点宕机的问题和解决方案，如果主节点宕机了怎么办，怎么写入数据呢？

哨兵机制

我们可以开启哨兵，哨兵可以对Redis节点进行监控、故障转移以及状态通知
监控：哨兵集群对所有redis节点进行监控，每一秒就会ping每个节点，如果节点在一定时间内没有回应，那么哨兵认为redis主观下线（挂了），但是也有可能是哨兵的网络问题，因此需要通过哨兵集群的主观判断，如果超过一定数量的哨兵认为redis节点主观下线，那么该节点就是客观下线了，就需要进行故障转移
故障转移：如果主节点被认为是客观下线，那么最先发现主节点宕机的哨兵就会进行故障转移，从从节点中推选出一位主节点，一般是根据这些从节点与主节点的最晚断开连接时间、在缓冲环中的最大offset或者最多运行时间（同步了主节点最多的数据），然后将推选出的主节点设置为其他的从节点的主人，将故障的主节点设置为故障状态，等待其重启后认主。
状态通知：通知最新的集群信息给redis客户端
配置：

//哨兵ip
sentinel announce-ip "172.0.0.1"
// 主节点的ip和端口，2是判定主节点客观下线的哨兵数量
sentinel monitor hmaster 172.0.0.1 7001 2
//哨兵认为主观下线的超时响应时间
sentinel down-after-milliseconds hmaster 5000
//第一次故障转移失败多久后重试
sentinel failover-timeout hmaster 60000