　　主从复制，是指将一台 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 16370daemonize yes
pidfile /oldboyedu/data/redis/redis.pid
loglevel notice
logfile /oldboyedu/data/redis/redis.log
dbfilename dump.rdbdir /oldboyedu/data/redis
bind 10.0.0.0 127.0.0.1requirepass oldboyedu
masterauth oldboyedu# 配置RDB持久化策略save 900 1save 300 10save 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.1port 16370dir /oldboyedu/data/redis-sentinel# 指定Redis初始集群的master库节点并命名为"oldboyedu_master"，注意这个"1"的含义，他表示sentinel需要最少的投票数。这在于多sentinel的场景下很有用，由于本案例只是用了1个sentinel，因此我就设置为1sentinel 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

ITPub博客

Redis主从复制与单哨兵模式详解！

最新文章