前言

文本已收录至我的GitHub仓库，欢迎Star：github.com/bin39232820…

种一棵树最好的时间是十年前，其次是现在

絮叨

半步神游，神游之下，天下无敌。一梦一游 便是天下。

Redis前面几篇的文章链接：

🔥从零开始学Redis之金刚凡境

🔥从零开始学Redis之自在地境

🔥从零开始学Redis之逍遥天境

上一篇的逍遥天境 讲的是Redis的内存淘汰策略 和持久化方式。那这半步神游就是带你们遨游Redis的主从HA，哨兵，和Lua脚本

Redis主从和哨兵模式

Redis 主从搭建（有兴趣的小伙伴自己用虚拟机搭一个玩玩）

1、环境说明

2、修改主从的redis配置文件

[root@redis-master ~]# grep -Ev "^$|#" /usr/local/redis/redis.conf 
bind 192.168.56.11
protected-mode yes
port 6379
daemonize yes
pidfile /var/run/redis_6379.pid
logfile "/var/log/redis.log"
dir /var/redis/
[root@redis-slave01 ~]# grep -Ev "^$|#" /usr/local/redis/redis.conf
bind 192.168.56.12
protected-mode yes
port 6379
daemonize yes
pidfile /var/run/redis_6379.pid
logfile "/var/log/redis.log"
dir /var/redis/
replicaof 192.168.56.11 6379    #配置为master的从，如果master上有密码配置，还需要增加下面一项密码配置
masterauth 123456   #配置主的密码
[root@redis-slave02 ~]# grep -Ev "^$|#" /usr/local/redis/redis.conf
bind 192.168.56.13
protected-mode yes
port 6379
daemonize yes
pidfile /var/run/redis_6379.pid
logfile "/var/log/redis.log"
dir /var/redis/
replicaof 192.168.56.11 6379    #配置为master的从
masterauth 123456   #配置主的密码
复制代码

3、启动主从redis

这里需要注意的是：redis主从和mysql主从不一样，redis主从不用事先同步数据，它会自动同步过去

[root@redis-master ~]# systemctl start redis
[root@redis-slave01 ~]# systemctl start redis
[root@redis-slave02 ~]# systemctl start redis
[root@redis-master ~]# netstat -tulnp |grep redis
tcp        0      0 192.168.56.11:6379      0.0.0.0:*               LISTEN      1295/redis-server 1 
[root@redis-slave01 ~]# netstat -tulnp |grep redis
tcp        0      0 192.168.56.12:6379      0.0.0.0:*               LISTEN      1625/redis-server 1 
[root@redis-slave02 ~]# netstat -tulnp |grep redis
tcp        0      0 192.168.56.13:6379      0.0.0.0:*               LISTEN      1628/redis-server 1 
复制代码

4、数据同步验证

[root@redis-master ~]# redis-cli -h 192.168.56.11   #主上写入数据
192.168.56.11:6379> KEYS *
(empty list or set)
192.168.56.11:6379> set k1 123
OK
192.168.56.11:6379> set k2 456
OK
[root@redis-slave01 ~]# redis-cli -h 192.168.56.12  #slave01上查看是否数据同步
192.168.56.12:6379> KEYS *
1) "k2"
2) "k1"
192.168.56.12:6379> get k1
"123"
192.168.56.12:6379> get k2
"456"
[root@redis-slave02 ~]# redis-cli -h 192.168.56.13  #slave02上查看是否数据同步
192.168.56.13:6379> KEYS *
1) "k2"
2) "k1"
192.168.56.13:6379> get k1
"123"
192.168.56.13:6379> get k2
"456"
复制代码

主从架构

主从架构的特点

• 主服务器负责接收写请求
• 从服务器负责接收读请求
• 从服务器的数据由主服务器复制过去。主从服务器的数据是一致的

主从架构的好处

• 读写分离(主服务器负责写，从服务器负责读)
• 高可用(某一台从服务器挂了，其他从服务器还能继续接收请求，不影响服务)
• 处理更多的并发量(每台从服务器都可以接收读请求，读QPS就上去了)

主从同步

主从架构的特点之一：主服务器和从服务器的数据是一致的。

主从同步的2种情况

• 同步(sync)

• 将从服务器的数据库状态更新至主服务器的数据库状态

• 命令传播(command propagate)

• 主服务器的数据库状态被修改，导致主从服务器的数据库状态不一致，让主从服务器的数据库状态重新回到一致状态。

完整的同步

• 从服务器向主服务器发送PSYNC命令
• 收到PSYNC命令的主服务器执行BGSAVE命令，在后台生成一个RDB文件。并用一个缓冲区来记录从现在开始执行的所有写命令。
• 当主服务器的BGSAVE命令执行完后，将生成的RDB文件发送给从服务器，从服务器接收和载入RBD文件。将自己的数据库状态更新至与主服务器执行BGSAVE命令时的状态。
• 主服务器将所有缓冲区的写命令发送给从服务器，从服务器执行这些写命令，达到数据最终一致性。

部分重同步

• 主从服务器的复制偏移量 主服务器每次传播N个字节，就将自己的复制偏移量加上N
• 从服务器每次收到主服务器的N个字节，就将自己的复制偏移量加上N
• 通过对比主从复制的偏移量，就很容易知道主从服务器的数据是否处于一致性的状态！

Redis HA 方案

HA(High Available，高可用性群集)机集群系统简称，是保证业务连续性的有效解决方案，一般有两个或两个以上的节点，且分为活动节点及备用节点。通常把正在执 行业务的称为活动节点，而作为活动节点的一个备份的则称为备用节点。当活动节点出现问题，导致正在运行的业务（任务）不能正常运行时，备用节点此时就会侦测到，并立即接续活动节点来执行业务。从而实现业务的不中断或短暂中断。

Redis 一般以主/从方式部署（这里讨论的应用从实例主要用于备份，主实例提供读写）该方式要实现 HA 主要有如下几种方案：

• keepalived： 通过 keepalived 的虚拟 IP，提供主从的统一访问，在主出现问题时， 通过 keepalived 运行脚本将从提升为主，待主恢复后先同步后自动变为主，该方案的好处是主从切换后，应用程序不需要知道(因为访问的虚拟 IP 不变)，坏处是引入 keepalived 增加部署复杂性，在有些情况下会导致数据丢失
• zookeeper： 通过 zookeeper 来监控主从实例， 维护最新有效的 IP， 应用通过 zookeeper 取得 IP，对 Redis 进行访问，该方案需要编写大量的监控代码
• sentinel： 通过 Sentinel 监控主从实例，自动进行故障恢复，该方案有个缺陷：因为主从实例地址( IP & PORT )是不同的，当故障发生进行主从切换后，应用程序无法知道新地址，故在 Jedis2.2.2 中新增了对 Sentinel 的支持，应用通过 redis.clients.jedis.JedisSentinelPool.getResource() 取得的 Jedis 实例会及时更新到新的主实例地址

Redis Sentinel

Redis Sentinel是官方推荐的高可用性解决方案。Sentinel是一个管理多个Redis实例的工具，它可以实现对Redis的监控、通知、自动故障转移。

Sentinel的主要功能包括主节点存活检测、主从运行情况检测、自动故障转移（failover）、主从切换。Redis的Sentinel最小配置是一主一从。 Redis的Sentinel系统可以用来管理多个Redis服务器，该系统可以执行以下四个任务：

• 监控: Sentinel会不断的检查主服务器和从服务器是否正常运行。
• 通知: 当被监控的某个Redis服务器出现问题，Sentinel通过API脚本向管理员或者其他的应用程序发送通知。
• 自动故障转移: 当主节点不能正常工作时，Sentinel会开始一次自动的故障转移操作，它会将与失效主节点是主从关系的其中一个从节点升级为新的主节点， 并且将其他的从节点指向新的主节点。
• 配置提供者: 在Redis Sentinel模式下，客户端应用在初始化时连接的是Sentinel节点集合，从中获取主节点的信息。

Redis Sentinel的工作流程

如图所示：由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器，以及所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求

Sentinel负责监控集群中的所有主、从Redis，当发现主故障时，Sentinel会在所有的从中选一个成为新的主。并且会把其余的从变为新主的从。同时那台有问题的旧主也会变为新主的从，也就是说当旧的主即使恢复时，并不会恢复原来的主身份，而是作为新主的一个从。

在Redis高可用架构中，Sentinel往往不是只有一个，而是有3个或者以上。目的是为了让其更加可靠，毕竟主和从切换角色这个过程还是蛮复杂的。这个是所有分布式系统都要碰到的问题一个是崩溃恢复 一个是数据同步 下面我们就来聊聊

Redis HA方案的 崩溃恢复 和数据同步

崩溃恢复

这个是所有分布式系统的问题 什么就是崩溃恢复呢 就我们目前的方案来说 我们是用sentinel 来保证redis的高可用 同时 sentinel 本身自己也做了HA 假设一主俩从的情况下 如果主节点挂了 怎么办，这就能造成单点故障 让整个redis 集群不可用，所以 崩溃恢复就是类似于一个Zookeeper的ZAB 算法 从其他节点中选举一个主节点，具体怎么选举一个新的主节点,这边就不扩展了，再说下去，这篇就扯不完了。

数据同步

redis的主从复制

>依赖于redis依赖于RDB模式下的持久化存储；采用复制RDB文件的形式进行主从节点之间的数据同步     
>注意：  主从复制时不要开启AOF持久化模式，因为AOF优先级高于RDB模式   
复制代码

RDB文件两种传输方法

1.普通复制    
复制代码

将主节点已经到磁盘上的的ROB文件，复制到从节点上

2.无盘复制

master端直接将RDB file传到slave socket，不需要与disk进行交互

无磁盘diskless方式适合磁盘读写速度慢但网络带宽非常高的环境