主从复制，主制单是从复指将一台 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.conf redis-cli -p 6370 -a oldboyedu INFO REPLICATION

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

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