Redis系列八：redis主从复制和哨兵

一、Redis主从复制

主从复制：主节点负责写数据，从节点负责读数据，主节点定期把数据同步到从节点保证数据的一致性

1. 主从复制的相关操作

a,配置主从复制方式一、新增redis6380.conf,加入 slaveof 192.168.152.128 6379,在6379启动完后再启6380，完成配置；b,配置主从复制方式二、redis-server --slaveof 192.168.152.128 6379 临时生效

c,查看状态：info replicationd,断开主从复制：在slave节点，执行6380:>slaveof no onee,断开后再变成主从复制：6380:> slaveof 192.168.152.128 6379f,数据较重要的节点，主从复制时使用密码验证： requirepasse,从节点建议用只读模式slave-read-only=yes,若从节点修改数据，主从数据不一致 h,传输延迟：主从一般部署在不同机器上，复制时存在网络延时问题，redis提供repl-disable-tcp-nodelay参数决定是否关闭TCP_NODELAY,默认为关闭参数关闭时：无论大小都会及时发布到从节点，占带宽，适用于主从网络好的场景，参数启用时：主节点合并所有数据成TCP包节省带宽，默认为40毫秒发一次，取决于内核，主从的同步延迟40毫秒，适用于网络环境复杂或带宽紧张，如跨机房

2. Redis主从拓扑

a)一主一从：用于主节点故障转移从节点，当主节点的“写”命令并发高且需要持久化，可以只在从节点开启AOF（主节点不需要），这样即保证了数据的安全性，也避免持久化对主节点的影响 

 

b)一主多从：针对“读”较多的场景，“读”由多个从节点来分担，但节点越多，主节点同步到多节点的次数也越多，影响带宽，也加重主节点的稳定

 

c)树状主从：一主多从的缺点（主节点推送次数多压力大）可用些方案解决，主节点只推送一次数据到从节点B，再由从节点B推送到C，减轻主节点推送的压力。

3. 主从复制原理

 

4. 数据同步

redis 2.8版本以上使用psync命令完成同步，过程分“全量”与“部分”复制全量复制：一般用于初次复制场景（第一次建立SLAVE后全量）部分复制：网络出现问题，从节点再次连接主节点时，主节点补发缺少的数据，每次数据增量同步心跳：主从有长连接心跳，主节点默认每10S向从节点发ping命令，repl-ping-slave-period控制发送频率

5. 主从的缺点

a)主从复制，若主节点出现问题，则不能提供服务，需要人工修改配置将从变主b)主从复制主节点的写能力单机，能力有限c)单机节点的存储能力也有限

6.主从故障如何故障转移

a)主节点(master)故障，从节点slave-1端执行 slaveof no one后变成新主节点；b)其它的节点成为新主节点的从节点，并从新节点复制数据；c)需要人工干预，无法实现高可用。

二、Redis哨兵机制（Sentinel）

1. 为什么要有哨兵机制？

       哨兵机制的出现是为了解决主从复制的缺点的

2. 哨兵机制(sentinel)的高可用

　　原理：当主节点出现故障时，由Redis Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。

其实整个过程只需要一个哨兵节点来完成，首先使用Raft算法（选举算法）实现选举机制，选出一个哨兵节点来完成转移和通知

3. 哨兵的定时监控任务

任务1：每个哨兵节点每10秒会向主节点和从节点发送info命令获取最拓扑结构图，哨兵配置时只要配置对主节点的监控即可，通过向主节点发送info，获取从节点的信息，并当有新的从节点加入时可以马上感知到

任务2：每个哨兵节点每隔2秒会向redis数据节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解其它哨兵节点的信息及对主节点的判断，其实就是通过消息publish和subscribe来完成的

 任务3：每隔1秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测，这个也是哨兵用来判断节点是否正常的重要依据

3

 

4. 领导者哨兵选举流程

a)每个在线的哨兵节点都可以成为领导者，当它确认（比如哨兵3）主节点下线时，会向其它哨兵发is-master-down-by-addr命令，征求判断并要求将自己设置为领导者，由领导者处理故障转移；b)当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；c)如果哨兵3发现自己在选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，继续选举…………

 

5. 故障转移机制

sentinel

 

 b) 3

 c) Sentinel3

 

 

　　  1. 

         2. 

         3. 

         4

 d) redis sentinel

6. 哨兵机制－故障转移详细流程-确认主节点

3

1. redis

　　A）

requirepass 12345678

　　B) 配置都一样

requirepass 12345678,

访问主节点的密码masterauth 12345678,

    注意：当主从起来后，主节点可读写，从节点只可读不可写

2. (

       /usr/local/bin/conf/sentinel_26379.conf  

       /usr/local/bin/conf/sentinel_26380.conf

       /usr/local/bin/conf/sentinel_26381.conf

: 26379   26380   26381

sentinel monitor mymaster 192.168.152.128 6379 2  //

      sentinel auth-pass mymaster 12345678     //

三个配置除端口外，其它一样。

3. sentinel.conf

sentinel monitor mymaster 192.168.152.128 6379 2  

//2

sentinel auth-pass mymaster 12345678  //sentinel

sentinel config-epoch mymaster 2  //

sentinel leader-epoch mymaster 2

sentinel failover-timeout mymasterA 180000 //

a,

b,180S时，则故障转移失败

c,180S转移失败

sentinel down-after-milliseconds mymasterA 300000//sentinel300S……

sentinel parallel-syncs mymasterA 1 //13

4. 

b)启动主从复制服务，先启动主再启动从

主：./redis-server conf/redis6379.conf &

从：

　　./redis-server conf/redis6380.conf &

　　./redis-server conf/redis6381.conf &      

sentinel

       ./redis-sentinel conf/sentinel_26379.conf &

       ./redis-sentinel conf/sentinel_26380.conf &

     

 ./redis-sentinel conf/sentinel_26381.conf &

到此服务全部启动完毕

连接到6379的redis的服务，可看到6379就是主节点，他有6380和6381两个从节点

5. kill -9 6379  

重新启动6379以后变为6380的从节点

6380

6380info replication     

sentinel_26379.conf6380 2

redis6379.conf6380,

redis Sentinel

部署建议

a

b

c

    N

     3