redis笔记（五）redis高可用

redis高可用

• 什么是高可用
  1. 它与被认为是不间断操作的容错技术有所不同，是目前企业防止核心系统因故障而无法工作的最有效保护手段
  2. 高可用一般指服务的冗余，一个服务挂了，可以自动切换到另一个服务上，不影响客户体验
• 多种模式对比
  1. 主从复制，若主节点出现问题，则不能提供服务，需要人工修改配置将从变主
  2. 主从复制主节点的写能力单机，能力有限
  3. 单节点的存储能力也有限
• 主从故障如何故障转移
  1. 主节点故障，从节点slave-1端执行slaveof no one 后变成新主节点
  2. 其他的节点变成新主节点的从节点，并从新节点复制数据
  3. 需要人工干预，无法实现高可用
• 哨兵机制的高可用

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

  2. 哨兵机制的三个定时监控任务作用
     1> 哨兵对各个节点：每隔10s发一次info
     2> 哨兵对master节点：每隔2s发一次publish/subscribe
     3> 主哨兵对从节点：每秒Ping一次

  3. 哨兵下线
     1> 主观下线：哨兵对节点每隔1s发一次ping超过down-after-milliseconds无回复，下线节点。主观下线后，不准确，不会故障转移
     2> 客观下线：多个哨兵对节点is-master-down-by-addr，对某个节点达到quorum，则下线该节点

  4. 哨兵领导者选举

     
     哨兵领导者选举.png

  5. 哨兵故障转移
     1> 由Sentinel节点定期监控发现主节点是否出现了故障。sentinel会向master发送心跳PING来确认master是否存活，如果master在“一定时间范围”内不回应PONG或者回复了一个错误消息，那么这个sentinel会主观地（单方面的）认为这个master已经不可用了
     2> 当主节点出现故障，此时假设3个Sentinel节点共同选举了Sentinel3节点为领导者sentinel,负责处理主节点的故障转移
     3> 由Sentinel3领导者节点执行故障转移，过程和主从复制一样，但是自动执行
     a, slave-1执行: slaveof no one 解除从节点身份，变为master
     b, slave-2变成新master的从节点 slave of new master
     c, 同样如果原主节点恢复也变成新主节点的从节点
     d, sentinel3通知应用程序新主节点的地址
     4> 主节点故障，哨兵选择新主节点的条件
     a,健康的节点，发送ping会有Pong回复的节点
     b,slave-priority优先级最高的从节点
     c,从节点复制主节点最完整的节点

  6. RedisSentinel如何安装与部署（示例：3个Sentinel,1个主节点，2个从节点）
     1> 先搭建一主两从redis的主从复制，修改redis.conf文件
     a,修改redis6379.conf,修改requirepass 12345678,注释掉#bind 192.168.19.22
     b,修改redis6380.conf和redis6381.conf,修改requirepass 12345678,注释掉#bind 192.168.19.22, 加上masterauth 12345678, 加上slaveof 192.168.19.22 6379
     tips:当主节点起来后，主节点可读写，从节点可读不可写
     2> 哨兵主从配置，修改sentinel文件,三个配置一样
     a, 监听主机节点6379：sentinel monitor mymaster 192.168.19.22 6379 2
     b, 连接主节点时的密码：sentinel auth-pass mymaster 12345678
     tips: 至此哨兵机制可正常启动运行
     3> 启动sentinel服务

     ./redis-sentinel conf/sentinel_26379.conf &
     ./redis-sentinel conf/sentinel_26380.conf &
     ./redis-sentinel conf/sentinel_26381.conf &
     

  4> 哨兵的其他配置
  a,sentinel config-epoch mymaster 2 //执行故障转移时，最多可以有多少个从节点同事对新的主机诶单进行数据同步
  b,sentinel leader-epoch mymaster 2
  c,sentinel failover-timeout mymaster 180000 //故障转移超时时间180s
  (1) 如果转移超时失败，下次转移时时间为之前的2倍
  (2) 从节点变主节点时，从节点执行slaveof no one 命令一直失败的话，当时间超过180s时，则故障转移失败
  (3)从节点复制新主节点时间超过180s转移失败
  d,sentinel down-after-milliseconds mymaster 300000 //sentinel节点定期向主节点Ping命令
  5> RedisSentinel节点测试
  a, 测试： kill -9 6379 杀掉6379的redis服务。看日志是分配6380，还是6381作为主节点，当6379服务再启动时，已变成从节点
  b, 假设6380升级为主节点，进入6380>info replication
  c, 打开sentinel_26379等三个配置
  sentinel monitor mymaster 192.168.19.22 6380 2 //有2个sentinel认为master下线
  d, 打开redis6379.conf等三个redis配置，slaveof 127.0.0.1 6380,所属主节点也变成6380
  tips:
  (1)生产环境建议让redis sentinel部署到不同的物理机上
  (2)sentinel monitor mymaster 192.168.19.22 6379 2 //切记不要将IP写成127.0.0.1，否则使用JedisSentinelPool取jedis连接的时候会变成取127.0.0.1 6379 的错误地址
  6> 部署建议
  a, sentinel节点应部署在多台物理机上
  b, 至少三个且奇数个sentinel节点
  c, 3个sentinel可同时监控一个主节点或多个主节点，当监听N个主节点较多时，如果sentinel出现异常，会对多个主节点有影响，同时还会造成sentinel节点产生过多的网络连接，一般线上建议还是，3个sentinel监听一个主节点
  7> 哨兵的API(进入哨兵的命令模式，使用redis-cli进入：redis-cli -p 26379)

  26379> sentinel masters 或 sentinel master mymaster 
  26379> sentinel slaves mymaster 
  26379> sentinel sentinels mymaster //查sentinel节点集合（不包括当前6379）
  26379> sentinel failover mymaster //对主节点强制故障转移，没喝其他节点协商
  ./redis-cli -p 26380 shutdown //关闭

8> 如果要远程客户端连接时，要修改配置protected-mode no。代码JedisSentinelPool