Redis主从原理+哨兵模式

一、主从复制原理

①：从服务器slave先于主服务器master建立socket长连接
②：从服务器slave向主服务器master发送一个PSYNC命令，请求复制数据。
③：主服务器master接收到PSYNC命令后，会通过bgsave命令利用子线程生成最新的rdb快照文件，并发送给从服务器slave。
持久化期间，master会继续接收客户端的请求，它会把这些可能修改数据集的请求缓存在内存repl buffer中
④：slave清掉无用数据，并接受master传来的数据加载到内存中
⑤：master再将之前持久化时缓存在内存中的命令发送给slave。
⑥：slave接受master发过来的新命令并执行
⑦：此时数据已同步完毕，当master再有新的写操作，会通过socket长连接持续的发给slave，保证主从数据一致性！
注意： 如果master收到了多个slave并发连接请求，它只会进行一次持久化，而不是一个连接一次，然后再把这一份持久化的数据发送给多个并发连接的slave。

1、如果在主从传输过程中，从节点挂了怎么办？

当salve因为网络等原因接收到一半数据时挂掉了，经过一段时间后，人为的重启了salve从节点，那么此时的数据传输是怎么处理呢？
答：从redis2.8版本开始，redis改用可以支持部分数据复制的命令PSYNC去master同步数据，slave与master能够在网络连接断开重连后只进行部分数据复制(断点续传)。流程图如下：

①：首先redis在运行时会默认开启一个缓存池，用于缓存最近的redis命令，可以在6379.conf中配置
repl-backlog-size 1mb ####redis命令缓存池，默认大小为1Mb
②：当slave与master断开并重新建立连接时，slave会向master发送PSYNC命令，并通过offset偏移量定位到断开连接时传输数据的位置，从这个位置开始进行断点续传
③：如果slave节点断开时间太久，导致偏移量太旧，已经在master中的命令缓存池中找不到对应的位置，那么就会进行一次全量数据的复制。无法使用断点续传了！

2.什么是主从复制风暴？

主从复制风暴：多个从节点同时复制主节点导致主节点压力过大
为了解决主从复制风暴问题，可以让部分从节点与从节点同步数据，架构如下设计：

3.主从复制优缺点

1.优点

2.缺点

二、Redis项目部署

1. 项目拓扑图

2.环境

 一台主服务器  master ：192.168.1.10
两台备服务器   slave1 ：192.168.1.11
             slave2 ：192.168.1.12

1.安装redis

主备服务器都需安装
通过xshell文件传输redis安装包

1.解压缩

[root@master ~]# tar zxvf redis-5.0.4.tar.gz   
[root@master ~]# cd redis-5.0.4/
[root@master redis-5.0.4]# make 配置安装
[root@master redis-5.0.4]# make DREFIX=/usr/local/redis install
更改安装路径可以用make PREFIX=安装路径 install
[root@master redis-5.0.4]# cd

2.创建链接

[root@master ~]# ln -s /usr/local/redis/bin/* /usr/local/bin/    
[root@master ~]# cd redis-5.0.4/utils/    
[root@master utils]# ls -lh    查看安装脚本
[root@master utils]# ./install_server.sh    运行脚本
[root@master utils]# netstat -anpt | grep redis   查看端口状态

提示安装成功后，表示Redis的基础配置完成

2.配置Redis主从复制服务

在主master服务器上

[root@master utils]# cd
[root@master ~]# vi /etc/redis/6379.conf 
[root@master ~]# /etc/init.d/redis_6379 stop    #服务关闭
[root@master ~]# /etc/init.d/redis_6379 start    #服务开启
修改添加
bind 0.0.0.0                     修改监听地址为0.0.0.0
daemonize yes                    开启守护进程
logfile /var/log/redis_6379.log  修改日志文件目录
dir /var/lib/redis/6379          修改工作目录
appendonly yes                   开启AOF持久化功能

在备1、2上编辑配置

[root@slave1 utils]# vi /etc/redis/6379.conf 
[root@slave1 utils]# /etc/init.d/redis_6379 restart  服务重启
修改添加
bind 0.0.0.0                 修改监听地址为0.0.0.0
appendonly yes               开启AOF持久化功能
replicaof 192.168.1.10 6379     增加一个同步master节点IP和端口

在master服务器上查看
验证主从效果

[root@master ~]# tail -f /var/log/redis_6379.log 

备2服务器同上

测试主从数据复制功能
在master主服务器上

[root@master ~]# redis-cli   #进入数据库
127.0.0.1:6379> set fa a     #设置fa键得值为a
127.0.0.1:6379> get fa       #查看fa键得值
127.0.0.1:6379> info replication   #信息复制，状态信息

在备1服务器上

[root@slave1 ~]# redis-cli    #进入数据库
127.0.0.1:6379> get fa        #获取fa键得值
127.0.0.1:6379> info replication     #信息复制，状态信息

在备2服务器上

// An highlighted block
var foo = 'bar';

3.模拟主服务器挂掉后

在master主服务器上，关闭服务

[root@master ~]# /etc/init.d/redis_6379 stop      关闭服务
[root@master ~]# tail -f /var/log/redis_6379.log  查看日志

在备1服务器查看现象

[root@slave1 ~]# tail -f /var/log/redis_6379.log 查看日志
[root@slave1 ~]# redis-cli                       进入数据库
127.0.0.1:6379> get k                            获取k的键值                    
"aa"                                                  
127.0.0.1:6379> info replication               信息复制，状态信息
# Replication
role:slave                                    状态：从服务器
master_host:192.168.1.10        

在备2服务器上

可以看到把主服务器关闭后，从服务器的状态不会转化成主服务器，但数据会复制转移过来，是可以读取查看到的

解决办法：
通过哨兵功能可以实现在主服务器失效时，主从的状态自动转换

先恢复到之前状态
master上
恢复上线

[root@master ~]# /etc/init.d/redis_6379 start      服务启动
[root@master ~]# tail -f /var/log/redis_6379.log   查看日志
[root@master ~]# redis-cli                         进入数据库
127.0.0.1:6379> info replication            信息复制，状态查看
# Replication
role:master          主服务 
connected_slaves:2   连接2个服务器
slave0:ip=192.168.1.11,port=6379,state=online,offset=84,lag=1
slave1:ip=192.168.1.12,port=6379,state=online,offset=84,lag=0
master_replid:087088c1aa398b11c1e4759e93eb8abb6bc277e2
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:84
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:84
127.0.0.1:6379> set nb b      添加nb键值为b
OK
127.0.0.1:6379> get nb        获取nb的键值
"b"

在备1服务器上

[root@slave1 ~]# tail -f /var/log/redis_6379.log   #查看日志
[root@slave1 ~]# redis-cli             

三、哨兵模式原理

• sentinel哨兵是特殊的redis服务，不提供读写服务，主要用来监控redis实例节点的状态！
• 哨兵架构下client端第一次请求redis服务时，会先从哨兵找出redis的主节点，后续就直接访问redis的主节点，不会每次都通过sentinel代理访问redis的主节点，当redis的主节点发生变化，哨兵会第一时间感知到，并且将新的redis主节点通知给client端(这里面redis的client端一般都实现了订阅功能，订阅sentinel发布的节点变动消息)
• 

1.哨兵的主要作用

1.现象

当master节点挂掉后，服务端控制台会打印 连接超时错误，当过一段时间后，又恢复正常，可以继续向redis中写入数据！

2.原因

• 原因就是哨兵会时刻监视着master节点，当master节点挂掉，此时服务端控制台会打印连接超时错误。但同时哨兵经过半数机制确认master挂掉，会选举出一个slave作为新的master
• 选举的这顿时间内，控制台还是会打印错误，一旦选举成功，就会恢复正常连接，这也是出现以上现象的原因！！
• 当原来挂掉的master节点重新恢复时，将自动称为新的master的丛节点，完成哨兵高可用架构！

哨兵要设为奇数，最少三台，里面涉及到投票问题!!

2.哨兵部署流程

在master服务器上
编辑哨兵模式的配置文件

[root@master ~]# vi redis-5.0.4/sentinel.conf 
修改添加
protected-mode no               关闭安全模式
daemonize yes                   指定sentine1为后台启动，开启守护进程
logfile "/var/log/sentinel.log" 指定日志存放路径
dir /var/lib/redis/6379         指定数据库存放路径

sentinel monitor mymaster 192.168.1.10 6379 2     
指定几个哨兵（slave）检测主服务器故障，才会进行故障迁移（主服务器ip地址，端口号，slave数）

sentinel down-after-milliseconds mymaster 3000  
 判定服务器down掉的时间周期，默认30000毫秒（30秒）
 
sentinel failover-timeout mymaster 100000
故障节点的最大超时时间为100000毫秒（100秒）

拷贝文件到slave1，slave2上

[root@master ~]# scp redis-5.0.4/sentinel.conf root@192.168.1.11:/root/redis-5.0.4
[root@master ~]# scp redis-5.0.4/sentinel.conf root@192.168.1.12:/root/redis-5.0.4

启动哨兵模式
先启master服务器，后启slave服务器

[root@master ~]# redis-sentinel redis-5.0.4/sentinel.conf &
[1] 69742
[root@slave1 ~]# redis-sentinel redis-5.0.4/sentinel.conf &
[1] 62685
[root@slave2 ~]# redis-sentinel redis-5.0.4/sentinel.conf &
[1] 62250

在master服务器上
1.查看日志

[root@master ~]# tail -f /var/log/sentinel.log 

2.查看进程状态

[root@master ~]# ps aux | grep redis
[root@master ~]# ps aux | grep sentinel

表明哨兵服务已经启动
3.远程登录数据库查看哨兵状态

[root@master ~]# redis-cli -h 192.168.1.10 -p 26379 info sentinel
[root@master ~]# redis-cli -h 192.168.1.10 -p 6379 info replication

1.模拟主服务器出现问题down下来，查看从服务器状态变化

在master服务器上

[root@master ~]# /etc/init.d/redis_6379 stop  停止服务
[root@master ~]# ps aux | grep redis        查看进程状态

在从服务器上进行日志查看

[root@slave1 ~]#  tail -f /var/log/sentinel.log 

发现master状态转移到从备1上

在slave2查看远程登录查看哨兵信息

[root@slave2 ~]# redis-cli -h 192.168.1.11 -p 26379 info sentinel

2.查看之前配置的哨兵检测的主服务器地址情况

在备1服务器上

[root@slave1 ~]# vi redis-5.0.4/sentinel.conf 

在主服务器上

发现的配置地址变化，在自动切换主状态时也会自动变更检测地址

3.查看当原master服务器恢复上线时，状态变化

在master服务器上

[root@master ~]# /etc/init.d/redis_6379 start  服务启动
[root@master ~]# ps aux | grep redis           查看进程端口状态
[root@master ~]# tail -f /var/log/sentinel.log 查看日志文件

在slave2上
查看数据库哨兵状态

[root@slave2 ~]# redis-cli -h 192.168.1.11 -p 26379 info sentinel

发现在原主服务器出现上线后，master状态并不会再次转换重新到自己上，这一点不同于vrrp服务，原因vrrp有优先级设置，此处服务没有。