redis（二）

一、Redis主从复制

1、什么是主从复制

是用来建立一个和主数据库完全一样的数据库环境，称为从数据库，可实现高可用；主数据库一般是实时的业务数据库，从数据库的作用和使用场合一般有几个： 

1. 作为后备数据库，主数据库服务器故障后，可切换到从数据库继续工作；
2. 可在从数据库作备份、数据统计等工作，这样不影响主数据库的性能；
3. 可以进行读写分离，master进行接收写操作，slave接收读的操作，可有效的进行流量的分流；

2、主从复制的配置

命令实现：slaveof 127.0.0.1 6379 ，在一台机器上输入此命令表示，本机器成为6379的从节点。
                slaveof no one 取消复制，提升slave为Master节点，以前同步的数据不会消失。但是当此节点成为从节点
                时，从节点的数据会清除，并同步主节点的数据。
配置实现：slaveof ip port   当前节点成为某个主节点的从节点。
                slave-read-only yes  设置slave为只读模式。

其中我们要注意：
1）规避全量复制 ：
             全量复制情景：第一次全量复制，slave节点连接时进行。主节点重启（运行ID变化），从节点会进行全量复制
2）规避复制风暴：
             风暴复制（主节点重启，多从节点复制）。

3、主从复制高可用的存在的问题？

1. 手动故障转移，一旦master宕机，slave晋升成主节点，同时需要修改应用方的主节点地址，还需要命令所有从节点去复制新的主节点，整个过程需要人工干预。
2. 主节点的写能力受到单机的限制。
3. 主节点的存储能力受到单机的限制。

手动故障转移：master宕机时，选取一台slave执行slaveof no noe命令晋升marster，其余slave执行slaveof new master寻找新的marster

二、Redis Sentinel 哨兵机制

1、介绍

        Redis Sentinel是一个分布式架构，包含若干个Sentinel节点和Redis数据节点，每个Sentinel节点会对数据节点和其余Sentinel节点进行监控，当发现节点不可达时，会对节点做下线标识。如果被标识的是主节点，他还会选择和其他Sentinel节点进行“协商”，当大多数的Sentinel节点都认为主节点不可达时，他们会选举出一个Sentinel节点来完成自动故障转移工作，同时将这个变化通知给Redis应用方。整个过程完全自动，不需要人工介入，所以可以很好解决Redis的高可用问题。

sentinel其实就是reids实例，只不过它没有存储的功能，是用来监控redis的，也可以用redis-cli连接。
多个sentinel实时监控所有的redis节点，而客户端连接sentinel来了解redis各节点的情况。

2、sentinel的主要配置

1) sentinel monitor mymaster 127.0.0.1 7000 2
2) sentinel  down-after-milliseconds mymaster  30000
3) sentinel  parallel-syncs mymaster  1
4) sentinel  failover-timeout mymaster  180000
 

1) 监控的主节点的名字、ip，2代表判断主节点失败至少需要2个Sentinel节点节点同意
2) 每30秒就去ping监控的 节点，如果超过30秒且没有回复，则判定不可达
3) 当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复制操作，限制每次向新的主节点发起复制操作的从节点个数为1
4) 故障转移超时时间为180000毫秒

3、sentinel如何实现故障转移

三个定时任务

为了保证sentinel对redis进行失败判定和故障转移，sentinel内部有定时任务去执行操作。

1.每10秒每个sentinel对master和slave执行info（发现slave节点、确认主从关系）
2.每2秒每个sentinel通过master节点的channle交换信息（pub/sub），通过_sentinel:hello频道交互，交互对节点的“看法”和自身信息
3.每1秒每个sentinel对其他sentinel和redis执行ping

主观下线和客观下线

主观下线：每个sentinel节点自己认为redis节点宕机（ping超时）
客观下线：一定数量的sentinel节点认为redis节点宕机（一定数量就是quorum，前面的命令进行配置）

领导者选举

原因：只有一个sentinel节点完成故障转移
选举：通过sentinel is-master-down-by-addr命令都希望成为领导者
          1）每个做主观下线的sentinel节点向其他sentinel节点发送命令，要求将它设为领导者
          2）收到命令的sentinel节点如果没有同意通过其他sentinel节点发送的命令，那么将同意该请求，否则拒绝
          3）如果该sentinel节点发现自己的票数已经超过sentinel集合半数且超过quorum，那么它将成为领导者
          4）如果此过程有多个sentinel节点成为领导者，那么将等待一段时间重新进行选举

故障转移（领导者选举结束后）

1.从slave节点中选出一个“合适的”节点作为新的master节点。
2.通知其余slave成为新的master额slave。
3.通知客户端主从变化
4.等待老的master复活成为新的master的slave。

选择“合适的”slave节点

1.选择slave-priority（slave节点优先级）最高的slave节点，如果存在则返回，不存在则继续。
2.选择复制偏移量最大的slave节点（复制的最完整），如果存在则返回，不存在则继续。
3.选择runId最小的slave节点。

4、总结

• Redis Sentinel是Redis的高可用实现方案：故障发现、故障自动转移、配置中心、客户端通知
• Redis Sentinel是Redis2.8版本开始才正是生产使用，之前版本生产不可以
• 尽可能在不同物理机上部署Redis Sentinel的节点
• Redis Sentinel中的Sentinel节点个数应该大于等于3且最好为奇数
• Redis Sentinel中的数据节点与普通数据节点没有区别
• 客户端初始化时连接的是Sentinel节点集合，不再是具体的Redis节点
• 看懂Redis Sentinel故障转移日志对于Redis Sentinel以及问题排查非常有帮助