Redis主从复制及哨兵模式

一、Redis主从复制

---

主机数据更新后根据配置和策略，自动同步到备机的master/slave机制，Master以写为主, Slave以读为主

3.1 主从复制作用

1. 做数据库的热备，作为后备数据库，主数据库服务器故障后，可切换到从数据库继续工作，避免数据丢失。
2. 架构的扩展。业务量越来越大，I/O访问频率过高，单机无法满足，此时做多库的存储，降低磁盘I/O访问的频率，提高单个机器的I/O性能。
3. 读写分离，使数据库能支撑更大的并发。在报表中尤其重要。由于部分报表sql语句非常的慢，导致锁表，影响前台服务。如果前台使用master，报表使用slave，那么报表sql将不会造成前台锁，保证了前台速度。

3.2 主从复制原理

1. 数据库有个bin-log二进制文件，记录了所有sql语句
2. 目的就是把主数据库的bin-log文件的sql语句复制到从数据库
3. 让其转为从数据库的relay-log中继日志，通过中继日志将朱数据库中的SQL语句同步到从数据库，保证主从数据库一致
4. 具体需要三个线程来操作：
   • binlog 输出线程：每当有从库连接到主库发送请求时，主库都会创建一个线程然后发送binlog内容到从库。
     同样，在从库里，当复制开始的时候，从库就会创建两个线程进行处理：
   • 从库I/O线程：当START SLAVE语句在从库开始执行之后，从库创建一个I/O线程，该线程连接到主库并请求主库发送binlog里面的更新记录到从库上。从库I/O线程读取主库的binlog输出线程发送的更新并拷贝这些更新到本地文件，其中包括relay log文件。
   • 从库的SQL线程：从库创建一个SQL线程，这个线程读取从库I/O线程写到relay log的更新事件并执行。
     可以知道，对于每一个主从复制的连接，都有三个线程。拥有多个从库的主库为每一个连接到主库的从库创建一个binlog输出线程，每一个从库都有它自己的I/O线程和SQL线程。
     

• 可以知道，对于每一个主从复制的连接，都有三个线程。拥有多个从库的主库为每一个连接到主库的从库创建一个binlog输出线程，每一个从库都有它自己的I/O线程和SQL线程。

原理图2：

1. 主库db的更新事件(update、insert、delete)被写到binlog
2. 从库发起连接，连接到主库
3. 此时主库创建一个binlog dump thread线程，把binlog的内容发送到从库
4. 从库启动之后，创建一个I/O线程，读取主库传过来的binlog内容并写入到relay log
5. 还会创建一个SQL线程，从relay log里面读取内容，从Exec_Master_Log_Pos位置开始执行读取到的更新事件，将更新内容写入到slave的db

3.3 docker下redis主从复制环境搭建

docker下redis主从复制环境搭建

二、Redis哨兵(sentinel)模式

---

2.1 为什么用到哨兵

哨兵(Sentinel)主要是为了解决在主从复制架构中出现宕机的情况,主要分为两种情况:

• 从Redis宕机
  这个相对而言比较简单，在Redis中从库重新启动后会自动加入到主从架构中，自动完成同步数据。在Redis2.8版本后，主从断线后恢复的情况下实现增量复制。
• 主Redis宕机
  这个相对而言复杂，需要以下2步才能完成：
  1. 在从数据库中执行SLAVEOF NO ONE命令，断开主从关系并且提升为主库继续服务。
  2. 将主库重新启动后，执行SLAVEOF命令，将其设置为其他库的从库,这时数据就能更新回来。

由于手动完成恢复的过程其实是比较麻烦的并且容易出错，所以Redis提供的哨兵(sentinel)的功能来解决

2.2 哨兵介绍

哨兵是 redis 集群机构中非常重要的一个组件，主要有以下功能：

• 集群监控：负责监控 redis master 和 slave 进程是否正常工作。
• 消息通知：如果某个 redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员。
• 故障转移：如果 master node 挂掉了，会自动转移到 slave node 上。
• 配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址。

哨兵用于实现 redis 集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。

• 故障转移时，判断一个 master node 是否宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题。
• 即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了。

哨兵的核心知识

• 哨兵至少需要 3 个实例，来保证自己的健壮性。
• 哨兵 + redis 主从的部署架构，是不保证数据零丢失的，只能保证 redis 集群的高可用性。
• 对于哨兵 + redis 主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练。
  
  

2.3 Sentinel哨兵

• 单哨兵模式
  
• 多哨兵模式
  
  多个哨兵,不仅同时监控主从数据库,而且哨兵之间互为监控

2.3 配置哨兵

# 新建sentinel配置文件
vim /usr/local/redis/conf/sentinel6379.conf

# 填写sentinel monitor
sentinel monitor mymaster 172.17.0.3 6379 2
# mymaster：监控主数据的名称,自定义即可,可以使用大小写字母和“.-_”符号
# 172.17.0.3：监控的主数据库的IP(docker内网IP)
# 6379：监控的主数据库的端口
# 2：至少有2个哨兵同意迁移的数量

# 依次修改 sentinel6380.conf，sentinel6381.conf 配置

启动哨兵进程

redis-server /usr/local/redis/conf/sentinel6379.conf --sentinel
docker exec -i -t  name /bin/bash
# 进入对应路径下启动哨兵进程 ./redis-sentinel /etc/redis/sentinel6379.conf

博客参考：
1. Docker搭建Redis主从复制+哨兵
2. docker配置Redis哨兵Sentinel模式

本文地址：https://blog.csdn.net/weixin_44069569/article/details/107451209