Redis-6 三种集群模式：主从模式、哨兵模式、分片集群

主从模式

一.介绍一下redis的主从同步

单节点的redis的并发能力是有上限的，要实现高并发，就要搭建主从集群，实现读写分离。通常是一主多从，主节点负责写数据，从节点负责读数据。

二.介绍一下主从模式同步数据的流程

1.全量同步——用于主从第一次建立连接

（1）从节点请求主节点同步数据，向主节点发送版本信息：replication id和offset

replication id：简称为replid，是数据集的标记，replid一致说明使用同一个数据集。通常每一个master节点都有唯一的replid，slave节点则会继承master节点的replid。

offset：偏移量，随着命令日志文件的数据的增多而增大。slave节点完成同步时会记录当前同步的offset，如果slave的offset小于master的offset，说明该slave的数据落后于master，需要进行数据同步。

（2）主节点根据replid是否一致判断是否是第一次请求同步，如果replid不一致，说明是第一次同步，执行全量同步

（3）主节点执行bgsave，生成一个RDB文件，发送给从节点去同步

（4）在从节点同步RDB文件期间，如果主节点接受了新的写命令，则会将这些写命令记录在一个命令日志文件repl_baklog里面，该日志文件相当于一个缓冲区

（5）从节点同步完成后，主节点会将repl_baklog中的命令发送给从节点进行同步

2.增量同步——用于slave重启或后期数据变化

（1）从节点请求主节点同步数据，向主节点发送版本信息

（2）主节点根据replid是否一致判断是否是第一次请求同步，如果replid一致，说明不是第一次同步，执行增量同步

（3）主节点从repl_baklog中获取从节点的offset值之后的命令，发送给从节点进行同步

哨兵模式

一.介绍一下哨兵模式

redis提供了哨兵(sentinel)机制用来实现主从集群的自动故障恢复，哨兵具有以下三个功能：

1.监控：sentinel会不断检查master节点和slave节点是否按预期工作。其基于心跳检测机制运行，每隔1秒就向集群的每个实例发送ping命令

（1）主观下线：如果某个sentinel节点发现集群中某个实例未在规定时间内响应，则认为该实例主观下线。该sentinel会向其余所有sentinel节点发送信息，询问它们该实例是否下线。

（2）客观下线：如果超过指定数量的sentinel节点都认为该实例主观下线，则判定该实例为客观下线，即该实例不可用。这个指定数量最好超过sentinel节点数量的一半。

2.自动故障恢复：如果master节点被判定为客观下线，则sentinel会依据选主规则将一个slave节点提选为新的master节点。当原master节点故障恢复后也会变成slave节点，以新的master节点为主。哨兵选主规则有多个，常用的有：

（1）先判断从节点的slave-priority值，值越小优先级越高

（2）如果slave-priority值相同，则判断从节点的offset值，值越大优先级越高

3.通知：sentinel充当redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给redis客户端。

二.你使用的redis是单点还是集群，如果是集群，是哪种集群？

示例：我使用的redis是集群，用的主从模式(一主一从)+哨兵模式。单节点不超过10G内存，如果redis内存不足，可以给不同的服务器分配独立的redis主从节点。

三.介绍一下redis的集群脑裂

1.集群脑裂是由于master节点与 slave节点和sentinel 处于不同的网络分区，导致sentinel未能感知到master节点的心跳，判断master节点主观下线，提选一个slave节点作为新的master节点，这样就同时存在了两个master节点，像大脑分裂了一样。客户端仍然会向原master节点写入数据，而新节点无法同步数据。当网络恢复后，原master节点会被降为slave节点，其数据也会因为从新的master节点那同步数据而被覆盖，这样就导致了网络故障期间写入原master节点的数据全部丢失。

2.解决方式

通过修改redis的配置，实现

（1）设置最少从节点数量，只有当主节点的从节点数量超过指定值，才允许向主节点写入数据

（2）缩短主从同步数据的延迟时间

如果达不到要求就拒绝请求，这样就可以避免大量的数据丢失。