Redis系列五：redis主从复制（replication）、哨兵（sentinel）、集群（cluster）
一、Redis主从复制
主从复制：主节点负责写数据，从节点负责读数据，主节点定期把数据同步到从节点保证数据的一致性
1. 主从复制的相关操作
- 配置主从复制方式一、新增redis6380.conf, 加入 slaveof 192.168.152.128 6379, 在6379启动完后再启6380，完成配置；
- 配置主从复制方式二、redis-server --slaveof 192.168.152.128 6379 临时生效
- 查看状态：info replication
- 断开主从复制：在slave节点，执行6380:>slaveof no one
- 断开后再变成主从复制：6380:> slaveof 192.168.152.128 6379
- 数据较重要的节点，主从复制时使用密码验证： requirepass
- 从节点建议用只读模式slave-read-only=yes, 若从节点修改数据，主从数据不一致
传输延迟：主从一般部署在不同机器上，复制时存在网络延时问题，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节点会通过指令sentinel is-masterdown-by-addr寻求其它哨兵节点对主节点的判断，当超过quorum（选举）个数，此时哨兵节点则认为该主节点确实有问题，这样就客观下线了，大部分哨兵节点都同意下线操作，也就说是客观下线
4. 领导者哨兵选举流程
a)每个在线的哨兵节点都可以成为领导者，当它确认（比如哨兵3）主节点下线时，会向其它哨兵发is-master-down-by-addr命令，征求判断并要求将自己设置为领导者，由领导者处理故障转移；
b)当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；
c)如果哨兵3发现自己在选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，继续选举…………
5. 故障转移机制
a)由Sentinel节点定期监控发现主节点是否出现了故障
sentinel会向master发送心跳PING来确认master是否存活，如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了
b) 当主节点出现故障，此时3个Sentinel节点共同选举了Sentinel3节点为领导，负载处理主节点的故障转移
c) 由Sentinel3领导者节点执行故障转移，过程和主从复制一样，但是自动执行
流程：
1. 将slave-1脱离原从节点，升级主节点，
2. 将从节点slave-2指向新的主节点
3. 通知客户端主节点已更换
4. 将原主节点（oldMaster）变成从节点，指向新的主节点
d) 故障转移后的redis sentinel的拓扑结构图
6. 哨兵机制－故障转移详细流程-确认主节点
a) 过滤掉不健康的（下线或断线），没有回复过哨兵ping响应的从节点
b) 选择salve-priority从节点优先级最高（redis.conf）的
c) 选择复制偏移量最大，指复制最完整的从节点
7. 实战：如何安装和部署哨兵
以3个Sentinel节点、2个从节点、1个主节点为例进行安装部署
1. 前提：先搭好一主两从redis的主从复制，和之前的主从复制搭建一样，搭建方式如下：
A）主节点6379节点（/usr/local/bin/conf/redis6379.conf）：
修改 requirepass 12345678，注释掉#bind 127.0.0.1
B) 从节点redis6380.conf和redis6381.conf: 配置都一样
修改 requirepass 12345678 ,注释掉#bind 127.0.0.1,
加上访问主节点的密码masterauth 12345678 ,加上slaveof 192.168.152.128 6379
注意：当主从起来后，主节点可读写，从节点只可读不可写
2. redis sentinel哨兵机制核心配置(也是3个节点)：
/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 //监听主节点6379
sentinel auth-pass mymaster 12345678 //连接主节点时的密码
三个配置除端口外，其它一样。
3. 哨兵其它的配置：只要修改每个sentinel.conf的这段配置即可：
sentinel monitor mymaster 192.168.152.128 6379 2
//监控主节点的IP地址端口，sentinel监控的master的名字叫做mymaster，2代表，当集群中有2个sentinel认为master死了时，才能真正认为该master已经不可用了
sentinel auth-pass mymaster 12345678 //sentinel连主节点的密码
sentinel config-epoch mymaster 2 //故障转移时最多可以有2从节点同时对新主节点进行数据同步
sentinel leader-epoch mymaster 2
sentinel failover-timeout mymasterA 180000 //故障转移超时时间180s，
a,如果转移超时失败，下次转移时时间为之前的2倍；
b,从节点变主节点时，从节点执行slaveof no one命令一直失败的话，当时间超过180S时，则故障转移失败
c,从节点复制新主节点时间超过180S转移失败
sentinel down-after-milliseconds mymasterA 300000//sentinel节点定期向主节点ping命令，当超过了300S时间后没有回复，可能就认定为此主节点出现故障了……
sentinel parallel-syncs mymasterA 1 //故障转移后，1代表每个从节点按顺序排队一个一个复制主节点数据，如果为3，指3个从节点同时并发复制主节点数据，不会影响阻塞，但存在网络和IO开销
4. 启动redis服务和sentinel服务:
a)先把之前安装的redis里面的标绿色的文件都拷贝到 usr/local/bin目录下，然后再再bin目录下新建一个conf文件夹存放配置好的redis主从配置文件和哨兵配置文件
b)启动主从复制服务，先启动主再启动从
主：./redis-server conf/redis6379.conf &
从：
./redis-server conf/redis6380.conf &
./redis-server conf/redis6381.conf &
c）启动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的redis服务
可以看到杀掉6379以后6380变为了主节点，6381变为了6380的从节点
重新启动6379以后变为6380的从节点
看日志是分配6380 是6381的主节点，当6379服务再启动时，已变成从节点
假设6380升级为主节点:进入6380>info replication 可以看到role:master
打开sentinel_26379.conf等三个配置，sentinel monitor mymaster 192.168.152.128 6380 2
打开redis6379.conf等三个配置, slaveof 192.168.152.128 6380,也变成了6380
注意：生产环境建议让redis Sentinel部署到不同的物理机上。
8.部署建议
a，sentinel节点应部署在多台物理机（线上环境）
b，至少三个且奇数个sentinel节点
c，通过以上我们知道，3个sentinel可同时监控一个主节点或多个主节点
监听N个主节点较多时，如果sentinel出现异常，会对多个主节点有影响，同时还会造成sentinel节点产生过多的网络连接，
一般线上建议还是， 3个sentinel监听一个主节点
三、redis集群
Redis集群的概念：
RedisCluster是redis的分布式解决方案，在3.0版本后推出的方案，有效地解决了Redis分布式的需求，当一个服务挂了可以快速的切换到另外一个服务，当遇到单机内存、并发等瓶颈时，可使用此方案来解决这些问题。
1、分布式数据库
1）分布式数据库把整个数据按分区规则映射到多个节点，即把数据划分到多个节点上，每个节点负责整体数据的一个子集。比如我们库有900
2）分区规则
常见的分区规则哈希分区和顺序分区，redis集群使用了哈希分区，顺序分区暂用不到，不做具体说明；
rediscluster采用了哈希分区的“虚拟槽分区”方式（哈希分区分节点取余、一致性哈希分区和虚拟槽分区），其它两种也不做介绍，有兴趣可以百度了解一下
3） 虚拟槽分区(槽：slot)
RedisCluster采用此分区，所有的键根据哈希函数(CRC16[key]&16383)映射到0－16383槽内，共16384个槽位，每个节点维护部分槽及槽所映射的键值数据
哈希函数: Hash()=CRC16[key]&16383 按位与
槽与节点的关系如下
redis用虚拟槽分区原因：解耦数据与节点关系，节点自身维护槽映射关系，分布式存储
4）redisCluster的缺陷
a，键的批量操作支持有限，比如mset, mget，如果多个键映射在不同的槽，就不支持了
b，键事务支持有限，当多个key分布在不同节点时无法使用事务，同一节点是支持事务
c，键是数据分区的最小粒度，不能将一个很大的键值对映射到不同的节点
d，不支持多数据库，只有0，select 0
e，复制结构只支持单层结构，不支持树型结构。
2、集群节点之间的通信
1） 节点之间采用Gossip协议进行通信，Gossip协议就是指节点彼此之间不断通信交换信息
当主从角色变化或新增节点，彼此通过ping/pong进行通信知道全部节点的最新状态并达到集群同步
2）Gossip协议
Gossip协议的主要职责就是信息交换，信息交换的载体就是节点之间彼此发送的Gossip消息，常用的Gossip消息有ping消息、pong消息、meet消息、fail消息
meet消息：用于通知新节点加入，消息发送者通知接收者加入到当前集群，meet消息通信完后，接收节点会加入到集群中，并进行周期性ping pong交换
ping消息：集群内交换最频繁的消息，集群内每个节点每秒向其它节点发ping消息，用于检测节点是在在线和状态信息，ping消息发送封装自身节点和其他节点的状态数据；
pong消息，当接收到ping meet消息时，作为响应消息返回给发送方，用来确认正常通信，pong消息也封闭了自身状态数据；
fail消息：当节点判定集群内的另一节点下线时，会向集群内广播一个fail消息，
3） 消息解析流程
所有消息格式为：消息头、消息体，消息头包含发送节点自身状态数据（比如节点ID、槽映射、节点角色、是否下线等），接收节点根据消息头可以获取到发送节点的相关数据。
消息解析流程：
4） 选择节点并发送ping消息：
Gossip协议信息的交换机制具有天然的分布式特性，但ping pong发送的频率很高，可以实时得到其它节点的状态数据，但频率高会加重带宽和计算能力，因此每次都会有目的性地选择一些节点； 但是节点选择过少又会影响故障判断的速度，redis集群的Gossip协议兼顾了这两者的优缺点，看下图：
不难看出：节点选择的流程可以看出消息交换成本主要体现在发送消息的节点数量和每个消息携带的数据量
流程说明：
A，选择发送消息的节点数量：集群内每个节点维护定时任务默认为每秒执行10次，每秒会随机选取5个节点，找出最久没有通信的节点发送ping消息，用来保证信息交换的随机性，每100毫秒都会扫描本地节点列表，如果发现节点最近一次接受pong消息的时间大于cluster-node-timeout/2 则立刻发送ping消息，这样做目的是防止该节点信息太长时间没更新，当我们宽带资源紧张时，在可redis.conf将cluster-node-timeout 15000 改成30秒，但不能过度加大
B，消息数据：节点自身信息和其他节点信息
3、redis集群扩容
这也是分布式存储最常见的需求，当我们存储不够用时，要考虑扩容
扩容步骤如下：
A. 准备好新节点
B. 加入集群,迁移槽和数据
1) 同目录下新增redis6382.conf、redis6392.conf两个redis节点
启动两个新redis节点
./redis-server clusterconf/redis6382.conf & （新主节点）
./redis-server clusterconf/redis6392.conf & （新从节点）
2) 新增主节点
./redis-trib.rb add-node 192.168.152.128:6382 192.168.152.128:6379
6379是原存在的主节点，6382是新的主节点
3),添加从节点
redis-trib.rb add-node --slave --master-id 03ccad2ba5dd1e062464bc7590400441fafb63f2 192.168.152.128:6392 192.168.152.128:6379
--slave，表示添加的是从节点
--master-id 03ccad2ba5dd1e062464bc7590400441fafb63f2表示主节点6382的master_id
192.168.152.128:6392,新从节点
192.168.152.128:6379集群原存在的旧节点
4) redis-trib.rb reshard 192.168.152.128:6382 //为新主节点重新分配solt
How many slots do you want to move (from 1 to 16384)? 1000 //设置slot数1000
What is the receiving node ID? 464bc7590400441fafb63f2 //新节点node id
Source node #1:all //表示全部节点重新洗牌
新增完毕！
4、集群缩减节点
集群同时也支持节点下线掉，下线的流程如下：
流程说明：
A，确定下线节点是否存在槽slot,如果有，需要先把槽迁移到其他节点，保证整个集群槽节点映射的完整性；
B，当下线的节点没有槽或本身是从节点时，就可以通知集群内其它节点（或者叫忘记节点），当下线节点被忘记后正常关闭。
删除节点也分两种：
一种是主节点6382，一种是从节点6392。
在从节点6392中，没有分配哈希槽，执行
./redis-trib.rb del-node 192.168.1.111:6392 7668541151b4c37d2d9 有两个参数ip：port 和节点的id。 从节点6392从集群中删除了。
主节点6382删除步骤：
1）./redis-trib.rb reshard 192.168.1.111:6382
问我们有多少个哈希槽要移走，因为我们这个节点上刚分配了1000 个所以我们这里输入1000
2）最后
./redis-trib.rb del-node 192.168.1.111:6382 3e50c6398c75e0088a41f908071c2c2eda1dc900
此时节点下线完成……
5、故障转移
redis集群实现了高可用，当集群内少量节点出现故障时，通过故障转移可以保证集群正常对外提供服务。
当集群里某个节点出现了问题，redis集群内的节点通过ping pong消息发现节点是否健康，是否有故障，其实主要环节也包括了 主观下线和客观下线；
主观下线：指某个节点认为另一个节点不可用，即下线状态，当然这个状态不是最终的故障判定，只能代表这个节点自身的意见，也有可能存在误判；
下线流程：
A，节点a发送ping消息给节点b ,如果通信正常将接收到pong消息，节点a更新最近一次与节点b的通信时间；
B，如果节点a与节点b通信出现问题则断开连接，下次会进行重连，如果一直通信失败，则它们的最后通信时间将无法更新；
节点a内的定时任务检测到与节点b最后通信时间超过cluster_note-timeout时，更新本地对节点b的状态为主观下线（pfail）
客观下线：指真正的下线，集群内多个节点都认为该节点不可用，达成共识，将它下线，如果下线的节点为主节点，还要对它进行故障转移
假如节点a标记节点b为主观下线，一段时间后节点a通过消息把节点b的状态发到其它节点，当节点c接受到消息并解析出消息体时，会发现节点b的pfail状态时，会触发客观下线流程；
当下线为主节点时，此时redis集群为统计持有槽的主节点投票数是否达到一半，当下线报告统计数大于一半时，被标记为客观下线状态。
故障恢复：
故障主节点下线后，如果下线节点的是主节点，则需要在它的从节点中选一个替换它，保证集群的高可用；转移过程如下：
1，资格检查：检查该从节点是否有资格替换故障主节点，如果此从节点与主节点断开过通信，那么当前从节点不具体故障转移；
2，准备选举时间：当从节点符合故障转移资格后，更新触发故障选举时间，只有到达该时间后才能执行后续流程；
3，发起选举：当到达故障选举时间时，进行选举；
4，选举投票：只有持有槽的主节点才有票，会处理故障选举消息，投票过程其实是一个领导者选举（选举从节点为领导者）的过程，每个主节点只能投一张票给从节点，当从节点收集到足够的选票（大于N/2+1）后，触发替换主节点操作，撤销原故障主节点的槽，委派给自己，并广播自己的委派消息，通知集群内所有节点。
