redis主从架构及哨兵模式（redis篇四）

1. redis主从架构图

2. redis主从工作原理

第一步：如果你为master配置了一个slave，不管这个slave是否是第一次连接上Master，它都会发送一个SYNC命令(redis2.8版本之前的命令)给master请求复制数据。

第二步：master收到SYNC命令后，会在后台进行数据持久化通过bgsave生成最新的rdb快照文件（此时是全量复制给slave节点），持久化期间，master会继续接收客户端的请求，它会把这些可能修改数据集的请求缓存在内存中。当持久化进行完毕以后，master会把这份rdb文件数据集发送slave，slave会把接收到的数据进行持久化生成rdb，然后再加载到内存中。然后，master再将之前缓存在内存中的命令发送给slave。

注意：当master与slave之间的连接由于某些原因而断开时，slave能够自动重连Master，如果master收到了多个slave并发连接请求，它只会进行一次持久化，而不是一个连接一次，然后再把这一份持久化的数据发送给多个并发连接的slave。当master和slave断开重连后，一般都会对整份数据进行复制。但从redis2.8版本开始，master和slave断
开重连后支持部分复制。

3. 全量复制与部分复制

全量复制:一般发生在slave第一次请求数据时和slave，master断开重连的时候（redis2.8版本）
全量复制图解：

增量复制：master全量复制给slave之后，往后将以增量的方式将数据给slave
增量复制图解：

4. redis主从架构搭建，配置从节点步骤

解释：本文章主从架构时配置在一台服务器进行模拟的

4.1 将redis的redis.conf文件复制一份到任意其他目录

cp redis.conf  新文件夹路径（作者将文件夹移动到了/root/redisConfig/6381/redis.conf）

4.2 修改刚刚复制redis.conf配置文件

daemonize yes  #原来的no改为yes 作用：改为守护进程
port 6381  #端口号
pidfile /var/run/redis_6381.pid     #pid
logfile "6380.log"   #log文件
dir /usr/local/redis‐5.0.4/data/6381  #持久化文件存放位置
replicaof 192.168.0.3 6379  # 从本机6379的redis实例复制数据
replica‐read‐only yes #从节点只读（redis.conf文件找不到这个配置，直接复制到里面就ok）

4.3 启动

4.5检查ps -ef | grep redis

5. redis哨兵模式

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

6. redis哨兵模式配置

6.1 复制一份sentinel.conf文件

cp sentinel.conf sentinel‐26379.conf

6.2 将相关配置修改为如下值

 port 26379
 daemonize yes
 pidfile "/var/run/redis‐sentinel‐26379.pid"
 logfile "26379.log"
 dir "/usr/local/redis‐5.0.4/data"
 sentinel monitor mymaster 192.168.0.3 6379 2

[sentinel monitor mymaster 192.168.0.3 6379 2]这个参数的意思是指明当有多少个sentinel认为一个master失效时(值一般为：sentinel总数/2 +1)，master才算真正失效

6.3 启动哨兵

./src/redis-sentinel sentinel‐26379.conf

6.4 检查启动哨兵

ps -ef |grep 26379

7. redis哨兵模式底层原理

     哨兵(sentinel) 是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用流言协议(gossipprotocols)来接收关于Master是否下线的信息,并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master.
　　每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave定时发送消息,以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的”主观认为宕机” Subjective Down,简称sdown).
     若“哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master"彻底死亡"(即:客观上的真正down机,Objective Down,简称odown),通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置.
　　虽然哨兵(sentinel) 释出为一个单独的可执行文件 redis-sentinel ,但实际上它只是一个运行在特殊模式下的 Redis 服务器，你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨兵(sentinel).
哨兵(sentinel) 的一些设计思路和zookeeper非常类似

8. redis哨兵模式缺点

在redis3.0以前的版本要实现集群一般是借助哨兵sentinel工具来监控master节点的状态，如果master节点异常，则会做主从切换，将某一台slave作为master，哨兵的配置略微复杂，并且性能和高可用性等各方面表现一般，特别是在主从切换的瞬间存在访问瞬断的情况，而且哨兵模式只有一个主节点对外提供服务，没法支持很高的并发，且单个主节点
内存也不宜设置得过大，否则会导致持久化文件过大，影响数据恢复或主从同步的效率,所以大型互联网公司都会采用redis集群架构