Redis主从复制、哨兵模式

Redis主从复制（重点）

概念

​ 默认情况下，每个Redis服务器都是主节点；

​ 将一台Redis服务器的数据，复制到其他的Redis服务器，前者称为主节点，后者为从节点；数据复制是单向的，只能由主节点到从节点；Maste可以写，Slave不能写只能读；

Redis的主从复制功能分为两种数据同步模式进行：全量数据同步和增量数据同步。

作用（最少3台）
1、实现故障恢复：主从模式可以在主节点挂掉之后，由从节点提高服务，实现快速的故障恢复。
2、实现负载均衡：由主节点负责写操作，而其他从节点负责读取操作，分担服务器负载。
3、高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础

1.主从复制过程（重点）

​ Redis的主从复制功能除了支持一个Master节点对应多个Slave节点的同时进行复制外，还支持Slave节点向其它多个Slave节点进行复制。这样使得我们能够灵活组织业务缓存数据的传播，例如使用多个Slave作为数据读取服务的同时，专门使用一个Slave节点为流式分析工具服务。Redis的主从复制功能分为两种数据同步模式进行：全量数据同步和增量数据同步。

**全量数据同步：**请求Master BgSave出自己的一个RDB Snapshot文件发给slave，Slave接收完Master发来的而数据文件后，清除掉自己的旧数据，然后将数据文件存盘并载入内存。

**增量数据同步：**Master作为一个普通的client连入Slave，将所有写操作转发给slave，完成同步。

​ 增量同步过程不再主要依赖RDB文件，Master会将新产生的数据变化操作存放在一个内存区域，这个内存区域采用环形构造。过程如下：

Slave启动：

• Slave启动并连接到Master后，会发送一个sync同步命令；

• Master接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据的命令，在后台执行完成后，Master将传输整个数据文件到Slave中，并完成一次完全同步（全量同步）；

除此之外：当Slave节点给定的run_id和Master的run_id不一致时，或者Slave给定的上一次增量同步的offset的位置在Master的环形内存中无法定位时，Master就会对Slave发起全量同步操作。

思考：

​ 为什么在Master上新增的数据除了根据Master节点上RDB或者AOF的设置进行日志文件更新外，还会同时将数据变化写入一个环形内存结构，并以后者为依据进行Slave节点的增量更新呢？主要原因有以下几个：

​ 由于网络环境的不稳定，网络抖动/延迟都可能造成Slave和Master暂时断开连接，这种情况要远远多于新的Slave连接到Master的情况。如果以上所有情况都使用全量更新，就会大大增加Master的负载压力——写RDB文件是有大量I/O过程的，虽然Linux Page Cahe特性会减少性能消耗。（方便写出，而不是每次都要全量数据同步）

​ 另外在数据量达到一定规模的情况下，使用全量更新进行和Slave的第一次同步是一个不得已的选择——因为要尽快减少Slave节点和Master节点的数据差异。所以只能占用Master节点的资源和网络带宽资源。（第一次同步使用全量数据同步是为了减少主从节点间数据间差异不得已而为之）

​ 使用内存记录数据增量操作，可以有效减少Master节点在这方面付出的I/O代价。而做成环形内存的原因，是为了保证在满足数据记录需求的情况下尽可能减少内存的占用量。这个环形内存的大小，可以通过repl-backlog-size参数进行设置。（用内存操作是为了减少磁盘IO）

2.如何建立

​ 在配置文件里面进行配置，注意一个主库能有多个从库，而一个从库只能对应一个主库。

//只用配置从库；
//把文件分发到其他集群中，修改conf中的ip地址配置；
//查看当前Redis配置信息；（每一台都是Master节点）
hadoop102:6379> info replication
# Replication
role:master //角色
connected_slaves:0 //连接从库
master_replid:7a5d71fbeb709bc9aa64ac493dfb04cdf6e36723 //随机ID
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0 
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

//配置从库：
//以Hadoop102为主机，hadoop103和Hadoop104为从机；
hadoop103:6379> SLAVEOF hadoop102 6379 
hadoop104:6379> SLAVEOF hadoop102 6379

//从机显示：    
hadoop104:6379> info replication
# Replication
role:slave //转变为Slave；
master_host:hadoop102 //主机地址；
master_port:6379 //主机IP；
master_link_status:up
master_last_io_seconds_ago:3
master_sync_in_progress:0
slave_repl_offset:56
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:62b786975664767a8838575ad3d546ecbb536216
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:56
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:43
repl_backlog_histlen:14

//主机显示：   
hadoop102:6379> info replication
# Replication
role:master
connected_slaves:2 //两台从机；
slave0:ip=192.168.10.103,port=6379,state=online,offset=154,lag=1
slave1:ip=192.168.10.104,port=6379,state=online,offset=154,lag=1
master_replid:62b786975664767a8838575ad3d546ecbb536216
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:154
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:154    

3.配置信息

//真实主从配置，在配置文件中配置；
//重要配置：

# slaveof <masterip> <masterport> //配置主机地址和IP；//建议不配置，这样更灵活；
    
# replica-serve-stale-data yes //当master节点断开和当前salve节点的连接或者当前slave节点正在进行和master节点的数据同步时，如果收到了客户端的数据读取请求，slave服务器是否使用陈旧数据向客户端提供服务。该参数的默认值为yes。
    
# slave-read-only //一旦设置为“只读”，表示这个Salve节点只会进行数据读取服务，如果客户端直接向这个Salve节点发送写数据的请求，则会收到错误提示。建议采用默认的“yes”值进行设定。
    
# repl-backlog-size 1mb//上文已经介绍过了Redis中为了进行增量同步所准备的环形内存区域，以及Redis这样做的原因额，所以这里就不再赘述了。这个选项就是用来设置环形内存的大小的，这个选项的默认值为1MB；正式的生产环境下可以稍微加大一些，例如5MB。    
    
# slave-priority //当前Slave节点的优先级权重。我们后文会介绍一款Redis自带的监控和故障转移工具：Redis Sentinel，这个工具允许一个Master节点下有多个Slave节点，并且可以自动切换Slave节点为Master节点。如果Slave节点的优先级权重值越低，就会再切换时有限成为新的Master节点。 
    
# min-slaves-to-write和min-slaves-max-lag //为了尽可能避免Master节点对应的多个Slave节点在数据复制过程中数据差异被越拉越大。Redis服务提供了一组拒绝数据写操作的策略，这个策略可以解释为：当Master上在min-slaves-max-lag时间（单位秒）间隔后，仍然有min-slaves-to-write个Slave和它正常连接，那么Master才允许进行数据写操作。    

//不太重要配置：
    
# repl-diskless-sync no//上文已经介绍过Redis的主从复制功能基于RDB，后者的过程是将数据刷入RDB文件（实际上是Linux的Page Cache区域），然后基于RDB文件内容的更新情况和Salve当前已同步的数据标记点来进行Salve上的数据更新。所以这个过程实际会增加一定的数据延迟，消耗一定的处理资源。基于这个情况，Redis中提供了一种不经过物理磁盘设备就进行主从数据同步的技术，称为diskless。但是直到Redis version 3.2这个技术也一直处于试验状态，所以并不推荐在生产环境下使用：“ 
WARNING: DISKLESS REPLICATION IS EXPERIMENTAL CURRENTLY”。

# repl-diskless-sync-delay 5//这个参数只有在上一个参数设置为“yes”时才起作用，主要是设置在进行两次diskless模式的数据同步操作的时间间隔。默认为5秒。

# repl-ping-replica-period 10//Slave节点向Master节点发送ping指令的事件间隔，默认为10秒。

# repl-timeout //这是一个超时间，当某些操作达到这个时间时，Master和Slave双方都会认为对方已经断开连接。实际上您可以将这个时间看成是一个租约到期的时间。那么这个操作时间会影响哪些操作呢？A、向Slave进行的数据同步操作本身不能超过这个时间；B、Slave向Master发送一个PING指令并等待响应的时间；C、Master向Slave发送PONG回复并等待ACK的时间。

# repl-disable-tcp-nodelay no//这个选项的默认值为no，它对优化主从复制时使用的网络资源非常有用。要明白这个参数的含义，就首先要解释一下tcp-nodelay是个什么玩意儿？TCP数据报的报文头包含很多属性，这些属性基本上起到记录和保证传输目的、传输状态的作用，但没有数据报的所携带的业务数据（称之为有效载荷）。那么很明显，20个字节内容的信息分成20个数据报进行传输和只用一个数据报进行传输，需要占用的网络资源就完全不一样。JohnNagle在1984年发明了一种减轻网络传输压力的算法，就是为了解决这个问题（算法的名字就叫做“Nagle”，后续的技术人员又做了很多改进和升级）。其基本思路就是将要发送的内容凑够一定的数量后，再用一个数据报发送出去。如果该属性设置为yes，Redis将使用“Nagle”算法（或类似算法），让数据报中的有效载荷凑够一定数量后，在发送出去；设置成no，Redis就不会这么做。

4.哨兵模式（面试、工作重点）

4.1哨兵模式架构解析

哨兵模式基础架构：

它由两部分组成，哨兵节点和数据节点：

• 哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的 Redis 节点，不存储数据。
• 数据节点：主节点和从节点都是数据节点。

实际上为了防止哨兵节点挂掉，我们也给哨兵节点配置了集群，所以完整版哨兵模式架构如下：（至少需要6个节点）

4.2哨兵进程的作用

1.监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。

2.提醒(Notification):当被监控的某个Redis节点出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。

3.自动故障迁移(Automatic failover)：当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作。

• 它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master；

• 当客户端试图连接失效的Master时，集群也会向客户端返回新Master的地址，使得集群可以使用现在的Master替换失效Master。

• Master和Slave服务器切换后，Master的redis.conf、Slave的redis.conf和sentinel.conf的配置文件的内容都会发生相应的改变，即，Master主服务器的redis.conf配置文件中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换。

4.3哨兵进程的工作方式

1.每个Sentinel（哨兵）进程以每秒钟一次的频率向整个集群中的Master主服务器，Slave从服务器以及其他Sentinel（哨兵）进程发送一个 PING 命令。
2.如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值，则这个实例会被 Sentinel（哨兵）进程标记为主观下线（SDOWN）。
3.如果一个Master主服务器被标记为主观下线（SDOWN），则正在监视这个Master主服务器的所有Sentinel（哨兵）进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态。
4.当有足够数量的 Sentinel（哨兵）进程（大于等于配置文件指定的值，即moniter配置IP后的值；）在指定的时间范围内确认Master主服务器进入了主观下线状态（SDOWN）， 则Master主服务器会被标记为客观下线（ODOWN）。
5.在一般情况下， 每个Sentinel（哨兵）进程会以每 10 秒一次的频率向集群中的所有Master主服务器、Slave从服务器发送 INFO 命令。
6.当Master主服务器被 Sentinel（哨兵）进程标记为客观下线（ODOWN）时，Sentinel（哨兵）进程向下线的 Master主服务器的所有 Slave从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
7.若没有足够数量的 Sentinel（哨兵）进程同意 Master主服务器下线， Master主服务器的客观下线状态就会被移除。若 Master主服务器重新向 Sentinel（哨兵）进程发送 PING 命令返回有效回复，Master主服务器的主观下线状态就会被移除。

部分操作：

//启动：
redis-sentinel sentinel配置文件；

//查询sentinel节点配置信息：
redis-cli -h hadoop102 -p 26379 info Sentinel

4.4配置文件

//主要修改参数 修改端口 ，修改主节点连接信息，其他使用默认就行了：
port 26379
sentinel monitor mymaster（被监控的名称） 192.168.10.102 6379（IP） 1  //1表示至少需要 2 个哨兵节点同意，才能判定主节点故障并进行故障转移；
daemonize yes //开启守护进程(后台运行，测试的时候选no就行）；    
    
# 哨兵sentinel的工作目录
dir /tmp
 
# 哨兵sentinel监控的redis主节点的 ip port 
# master-name  可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
# quorum 配置多少个sentinel哨兵统一认为master主节点失联 那么这时客观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
  sentinel monitor mymaster 192.168.10.102 6379 1
 
# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
 
 
# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000
 
# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行同步，
这个数字越小，完成failover所需的时间就越长，
但是如果这个数字越大，就意味着越多的slave因为replication而不可用。
可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1
 
 
 
# 故障转移的超时时间 failover-timeout 可以用在以下这些方面： 
#1. 同一个sentinel对同一个master两次failover之间的间隔时间。
#2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
#3.当想要取消一个正在进行的failover所需要的时间。  
#4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按
parallel-syncs所配置的规则来了
# 默认三分钟
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000
 
# SCRIPTS EXECUTION
 
#配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。
#对于脚本的运行结果有以下规则：
#若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10
#若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
#如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
#一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。
 
#通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），将会去调用这个脚本，
这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数，
一个是事件的类型，
一个是事件的描述。
如果sentinel.conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无法正常启动成功。
#通知脚本
# sentinel notification-script <master-name> <script-path>
  sentinel notification-script mymaster /var/redis/notify.sh
 
# 客户端重新配置主节点参数脚本
# 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。
# 以下参数将会在调用脚本时传给脚本:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# 目前<state>总是“failover”,
# <role>是“leader”或者“observer”中的一个。 
# 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的
# 这个脚本应该是通用的，能被多次调用，不是针对性的。
# sentinel client-reconfig-script <master-name> <script-path>
 sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

5.细节

//1.主机才能写，从机只能读；
hadoop104:6379> del balance consume k1 
(error) READONLY You can't write against a read only replica. //从机不能写；

hadoop104:6379> keys *
1) "balance"
2) "consume"
3) "k1"
hadoop102:6379> del balance //主机删除key；
(integer) 1
hadoop104:6379> keys * //从机也删除了；
1) "consume"
2) "k1"

//2.没有配置哨兵模式时，主机挂掉，从机不会修改配置，仍为主机；主机重新连上，集群就可以恢复正常；同时，从机可以通过slaveof on one命令转变为主节点；
//若是从机掉线，再次连接称为从机后（配置文件配置，否则需要重连），数据会自动和Master同步；（会自动执行一次全量数据同步）
//此时是支持层层链路型连接的，即某个从节点作为其他从节点的主节点，但需要注意的是，除了整个集群的Master能执行写操作之外，其他的节点仍然不能执行写操作，但主节点的操作仍然可以发向所有节点；