repl_backlog_buffer，是一个【环形】缓冲区，用于主从服务器断连后，从中找到差异的数据；
replication offset，标记上面那个缓冲区的同步进度，主从服务器都有各自的偏移量，主服务器使用 master_repl_offset 来记录自己「写」到的位置，从服务器使用 slave_repl_offset 来记录自己「读」到的位置。

在主服务器进行命令传播时，不仅将写命令发送给从服务器，还将写命令写入repl_backlog_buffer 缓冲区里，因此这个缓冲区里会保存着最近传播的写命令。

网络断开后，当从服务器重新连上主服务器时，从服务器会通过 psync 命令将自己的复制偏移量 slave_repl_offset 发送给主服务器，主服务器根据自己的 master_repl_offset 和 slave_repl_offset 之间的差距，然后来决定对从服务器执行哪种同步操作：

当主服务器在 repl_backlog_buffer 中找到主从服务器差异（增量）的数据后，就会将增量的数据写入到 replication buffer 缓冲区，其缓存将要传播给从服务器的命令。

repl_backlog_buffer 缓行缓冲区的默认大小是 1M，并且由于它是一个环形缓冲区。为了避免在网络恢复时，主服务器频繁地使用全量同步的方式，我们应该调整下 repl_backlog_buffer 缓冲区大小，尽可能的大一些，减少出现从服务器要读取的数据被覆盖的概率，从而使得主服务器采用增量同步的方式。

主从复制中replication buffer 、repl backlog buffer有什么区别？

哨兵机制

哨兵（Sentinel）机制，它的作用是实现主从节点故障转移。它会监测主节点是否存活，如果发现主节点挂了，它就会选举一个从节点切换为主节点，并且把新主节点的相关信息通知给从节点和客户端。

Ubuntu下配置哨兵集群https://blog.csdn.net/weixin_44415582/article/details/131748680?spm=1001.2014.3001.5501

哨兵的作用：

哨兵集群

在哨兵集群中，哨兵节点之间是通过 Redis 的发布者/订阅者机制来相互发现的。哨兵 A 把自己的 IP 地址和端口的信息发布到__sentinel__:hello 频道上，哨兵 B 和 C 订阅了该频道。那么此时，哨兵 B 和 C 就可以从这个频道直接获取哨兵 A 的 IP 地址和端口号。然后，哨兵 B、C 可以和哨兵 A 建立网络连接。

主节点知道所有【从节点】的信息，所以哨兵会每 10 秒一次的频率向主节点发送 INFO 命令来获取所有【从节点】的信息。

集群监控原理

Sentinel基于心跳机制监测服务状态，每隔1秒向集群的每个实例发送ping命令：

主观下线：如果某sentinel节点发现某实例未在规定时间响应(配置项 down-after-milliseconds 参数设定的，单位是毫秒)，则认为该实例主观下线。
客观下线：若超过指定数量（quorum）的sentinel都认为该实例主观下线，则该实例客观下线。quorum值最好超过Sentinel实例数量的一半<一般是哨兵个数的二分之一加一>。(防止主节点因为假死被故障切换啦)

集群故障恢复原理

一旦发现master故障，sentinel需要在salve中选择一个作为新的master，选择依据是这样的：

当选出一个新的master后，故障切换流程如下：

分片集群

当 Redis 缓存数据量大到一台服务器无法缓存时，就需要使用 Redis 分片集群（Redis Cluster ）方案，它将数据分布在不同的服务器上，以此来降低系统对单主节点的依赖，从而提高 Redis 服务的读写性能。
Redis Cluster主节点互相之间通过心跳机制监控互相状态，而每个主节点的从节点不支持读写操作，只是做个备份。

Ubuntu下配置分片集群https://blog.csdn.net/weixin_44415582/article/details/131748887?spm=1001.2014.3001.5501

Redis Cluster 方案采用哈希槽（Hash Slot），来处理数据和节点之间的映射关系。在 Redis Cluster 方案中，一个切片集群共有 16384 个哈希槽，这些哈希槽类似于数据分区，每个键值对都会根据它的 key，被映射到一个哈希槽中，具体执行过程分为两大步：

通过以下两种方案被映射到具体的 Redis 节点上

需要注意的是，在手动分配哈希槽时，需要把 16384 个槽都分配完，否则 Redis 集群无法正常工作。

集群伸缩

向集群中添加新的节点

cd /tmp

创建一个文件夹
mkdir 7004

拷贝配置文件
cp redis.conf /7004

修改配置文件
sed /s/6379/7004/g 7004/redis.conf

启动
redis-server 7004/redis.conf

执行添加命令 192.168.150.101:7004《添加节点》 192.168.150.101:7001《集群中已知节点》
redis-cli --cluster add-node  192.168.150.101:7004 192.168.150.101:7001

通过命令检查集群状态：
redis-cli -p 7001 cluster nodes

但是，可以看到7004节点的插槽数量为0，因此没有任何数据可以存储到7004上

转移插槽

将0~3000的插槽从7001转移到7004

与7001建立连接
redis-cli --cluster reshard 192.168.150.101:7001

询问要移动多少个插槽，我们计划是3000个

询问，你的插槽是从哪里移动过来的？

集群故障转移

自动故障转移

手动故障转移

利用cluster failover命令可以手动让集群中的某个master宕机，切换到执行cluster failover命令的这个slave节点（主从切换），实现无感知的数据迁移。其流程如下

cluster failover命令可以指定三种模式：

案例需求：在7002这个slave节点执行手动故障转移，重新夺回master地位

QT中的耗时操作放到子线程中执行

主从模式

主从第一次同步：全量同步

第一阶段：建立链接、协商同步

第二阶段：主服务器同步数据给从服务器

第三阶段：主服务器发送新写操作命令给从服务器

命令传播

增量同步

主服务器怎么知道要将哪些增量数据发送给从服务器呢？