什么是主从复制？

指将一台Redis服务器的数据，复制到其它的Redis服务器，前者称为主节点(master)，后者称为从节点(slave)，数据的复制是单向的，只能由主节点到从节点。

默认情况下，每台Redis服务器都是主节点，且一个主节点可以有多个从节点（或没有从节点），但一个从节点只能有一个主节点。

为什么用主从复制

在实际的场景当中单一节点的redis容易面临风险。

比如：我们部署一台Redis服务器，当发生机器故障时，需要迁移到另外一台服务器并且要保证数据是同步的。

要实现分布式数据库的更大的存储容量和承受高并发访问量，我们会将原来集中式数据库的数据分别存储到其他多个网络节点上。

Redis为了解决这个单一节点的问题，也会把数据复制多个副本部署到其他节点上进行复制，实现Redis的高可用，实现对数据的冗余备份，从而保证数据和服务的高可用。

主从复制的作用

数据冗余：

• 主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式

故障恢复：

• 当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；
• 实际上是一种服务的冗余；

负载均衡：

• 在主从复制的基础上，配合读写分离，可以由主节点提供写服务，从节点提供读服务；
• 即写redis数据时应用连接主节点，读redis数据从节点分担服务器负载；
• 尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量；

读写分离：

• 可以用于实现读写分离，主库写，从库读；
• 读写分离不仅可以提高服务器的负载能力，同时可根据需求的变化，改变从库的数量

高可用基石：

• 除了上述作用外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础

主从复制工作原理

如下图所示，是Redis的工作原理，其对应的文字说明如下:

• slave库通过"SLAVEOF 10.0.0.112 6370"命令连接master库并发送"SYNC"给master库；
• master库收到"SYNC"，会立即触发"BGSAVE"后台保存RDB快照，并将RDB快照发送给slave库；
• slave库接收后会应用RDB快照；
• master库会陆续将中间产生的新的操作保存并发送给slave库；
• 到此我们master复制集就正常工作了；
• 再此以后,master库只要发生新的操作，都会以命令传播的形式自动发送给slave库；
• 所有复制相关信息，从info信息中都可以查到，即使重启任何节点，他的master-slave关系依然都在；
• 如果发生master-slave关系断开时，slave库数据没有任何损坏，在下次重连之后，slave库发送"PSYNC"给master库；
• master库只会将slave库缺失部分的数据同步给slave库应用，达到快速恢复master-slave架构的目的；

温馨提示：

在Redis 2.8版本之前，如果master-replica架构中replica库宕机将会再次触发"SYNC"，从而全量拷贝主库的数据，这样效率明显很低。

于是在Redis 2.8版本之后就新增了"PSYNC"指令以实现可以理解为"断点续传"的功能

而在生产环境中，建议开启master库持久化功能，避免因主库意外重启而导致缓存丢失

举个例子，master库有1w条数据，replica库在某一时刻仅有9k数据，还有1k数据未来得及同步master库时，master库意外重启导致KEY为0，此时replica库同步master库数据会将replica库已有的9k缓存数据删除以达到和master库同步的目的

Redis主从复制部署

主从复制环境

部署Redis

mkdir -pv /oldboyedu/softwares/
# 下载Redis软件包
wget https://download.redis.io/releases/redis-6.2.2.tar.gz

# 解压软件包
tar xf redis-6.2.2.tar.gz -C /oldboyedu/softwares/
ln -sv /oldboyedu/softwares/redis-6.2.2 /oldboyedu/softwares/redis

# 安装依赖包
yum -y install gcc automake autoconf libtool make

# 编译Redis源码
cd /oldboyedu/softwares/redis
make && make install

# 为Redis环境单独配置环境变量
cat >/etc/profile.d/redis.sh<<EOF
#!/bin/bash
       
export PATH=/oldboyedu/softwares/redis/src:\$PATH
EOF

# 使得上一步配置的Redis环境变量生效
source /etc/profile.d/redis.sh
redis-cli --version  # 如果输出该命令有提示信息说明配置生效

为各个Redis实例创建数据和配置文件目录

# 创建Redis的数据存储目录
mkdir -pv /oldboyedu/data/redis

# 创建Redis的配置文件存储目录
mkdir -pv /oldboyedu/softwares/redis

为各个Redis实例创建配置文件

cat > /oldboyedu/softwares/redis/redis.conf <<EOF
port 16370
daemonize yes
pidfile /oldboyedu/data/redis/redis.pid
loglevel notice
logfile /oldboyedu/data/redis/redis.log
dbfilename dump.rdb
dir /oldboyedu/data/redis
bind 10.0.0.0 127.0.0.1
requirepass oldboyedu
masterauth oldboyedu
# 配置RDB持久化策略
save 900 1
save 300 10
save 60 10000
# 配置AOF持久化
appendonly yes
appendfsync everysec
EOF

温馨提示：

所有的requirepass建议设置为一致，这为我们"哨兵模式"做准备，很明显，"requirepass"表示配置当前实例的验证口令；

注意"masterauth"表示的含义是主库的验证口令；

启动各个Redis实例

redis-server /oldboyedu/softwares/redis/redis.conf

关闭Redis实例

停止各个Redis实例运行，此步骤可跳过，因为我们暂时还不需要停止Redis，我们要用Redis实例做主从架构

redis-cli -p 6370 -a oldboyedu shutdown

开启Redis的主从

# 从库实例开启主从
redis-cli -p 6370 -a oldboyedu SLAVEOF 10.0.0.112 6370

主库实例查看主从信息

redis-cli -p 6370 -a oldboyedu INFO REPLICATION

从库实例查看主从信息

redis-cli -p 6370 -a oldboyedu INFO REPLICATION

验证主从配置是否生效

在redis-master112实例主库的11号数据库创建测试数据

redis-cli -p 6370 -a oldboyedu -n 11
> SET name oldboyedu
> SET age 18
> KEYS *

在redis-slave113实例从库的11号数据库查看是否同步主库的11号数据库

redis-cli -p 6370 -a oldboyedu -n 11
> KEYS *
> GET name
> GET age

在redis-slave114实例从库的11号数据库查看是否同步主库的11号数据库

redis-cli -p 6370 -a oldboyedu -n 11
> KEYS *
> GET name
> GET age

解除"redis-slave114"实例的主从关系

redis-cli -p 6370 -a oldboyedu SLAVEOF NO ONE

什么是哨兵模式

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行

其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例

这里的哨兵有两个作用

• 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器
• 当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机

然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控

各个哨兵之间还会进行监控，这样就形成了多哨兵模式

用文字描述一下故障切换（failover）的过程：

• 假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线
• 当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作
• 切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线
• 这样对于客户端而言，一切都是透明的
  
  

部署Redis哨兵模式

创建sentinel所需的目录

# Redis-master服务器上执行
mkdir -pv /oldboyedu/softwares/redis-sentinel
mkdir -pv /oldboyedu/data/redis-sentinel
mkdir -pv /oldboyedu/logs/redis-sentinel

创建sentinel的配置文件

cat > /oldboyedu/softwares/redis-sentinel/sentinel.conf <<EOF
bind 10.0.0.112 127.0.0.1
port 16370
dir /oldboyedu/data/redis-sentinel

# 指定Redis初始集群的master库节点并命名为"oldboyedu_master"，注意这个"1"的含义，他表示sentinel需要最少的投票数。这在于多sentinel的场景下很有用，由于本案例只是用了1个sentinel，因此我就设置为1
sentinel monitor oldboyedu_master 10.0.0.112 6370 1

# 监控sentinel集群时，如果超过了5000毫秒(即5秒)仍然没有响应，则sentinel会判定master库宕机了
sentinel down-after-milliseconds oldboyedu_master 5000

# 由于sentinel需要访问Redis集群，因此我们要设置访问整个集群的密码，我这里指定的密码为"oldboyedu"，这意味着所有的节点都使用相同的密码
sentinel auth-pass oldboyedu_master oldboyedu
EOF

启动sentinel进程并查看日志

启动sentinel进程

redis-sentinel /oldboyedu/softwares/redis-sentinel/sentinel.conf &> /oldboyedu/logs/redis-sentinel/sentinel.log &

查看日志信息

tail -100f /oldboyedu/logs/redis16379/sentinel.log

手动停止主库运行，模拟主库宕机

切换前主从状态正常

手动将主库宕机，观察从库被sentinel实现了自动切换

redis-cli -p 6370 -a oldboyedu SHUTDOWN

查看sentinel的日志信息，不难发现有记录切换的过程，如下所示

tail -100f /oldboyedu/logs/redis-sentinel/sentinel.log

手动修复宕机的主库

# 修复后，之前宕机的主库会自动加入集群并成为slaves节点redis-server /oldboyedu/softwares/redis/redis.confredis-cli -p 6370 -a oldboyedu INFO REPLICATION

注意观察sentinel日志哟，会有新日志记录

tail -100f /oldboyedu/logs/redis-sentinel/sentinel.log

总结：

在本教程中，我们通过一些示例学习了如何去部署Redis主从复制和单哨兵模式

感谢您的阅读，由于文档整理较费时费力，难免会有疏漏和不妥当地方，敬请谅解