Redis高可用部署

redis 高可用原理：

Redis使用sentinel机制来实现高可用，sentinel是另外一个集群，主要是用来监控所有的Redis服务器，所有redis主节点和redis从节点，监控方式使用的是ping指令，sentinel每隔1秒向master发送【ping】，如果在一段时间内没有收到【pong】或者收到无效回复，则认为master下线。
sentinel对下线有两种定义：
a.主观下线（sdown）：sentinel实例本身对服务实例的判断
b.客观下线（odown）：多个sentinel实例对同一个服务SDOWN的状态做出协商后的判断，只有master才可能在odown状态。
简单的说，一个sentinel单独做出的判断只能是sdown，是没有任何官方效力的，只有多个sentinel大家商量好，得到一致，才能将某个master状态从sdown置为odown，只有确定master的状态转换为odown状态后，才能做后续failover的操作。
sentinel能够实现监控整个主从复制架构，你只要告诉sentinel谁是主服务器就行了，它会从主服务器上，也就是向主服务发送info指令，了解这个主下面有哪些从服务器，如果发现主服务器离线了，它会自动从这个主服务器下面的某个从服务器中选举一个当新的主节点，那么此前从节点连的主节点是原来的老主，原来的主节点不在了怎么办，sentinel告诉客户端新的主是谁 ,向客户端发送slaveof指定让从节点重新选择主节点。
如果sentinel连不主节点或者sentinel本身故障了怎么办，所以sentinel需要做一个集群。由集群中的每个节点来共同判断redis节点是否down了。
Sentinel作用是管理多个redis服务实现HA
监控：Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
通知：当被监控的某个Redis服务器出现问题时， Sentinel可以通过API向管理员或者其他应用程序发送通知。
自动故障转移：当一个主服务器不能正常工作时， Sentinel会开始一次自动故障迁移操作，它会将失效主服务器的其中一个从服务器升级为新的主服务器，并让失效主服务器的其他从服务器改为复制新的主服务器；当客户端试图连接失效的主服务器时，集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器。
使用的是流言协议，投票协议。

坚守“ 做人真诚 · 做事靠谱 · 口碑至上 · 高效敬业 ”的价值观，专业网站建设服务10余年为成都门窗定制小微创业公司专业提供成都企业网站定制营销网站建设商城网站建设手机网站建设小程序网站建设网站改版，从内容策划、视觉设计、底层架构、网页布局、功能开发迭代于一体的高端网站建设服务。

sentinel的启动

启动方式有两种：

#通过redis-server 的sentinel参数启动：
    redis-servier /etc/sentinel.conf  --sentinel
#通过redis-sentinel命令启动：
    redis-sentinel /etc/sentinel.conf

Sentinel依赖于配置文件，它必须用配置文件不停保存自已的状态信息。

启动一个sentinel有以下几个步骤：

服务器自身初始化。
运行 redis-server 中专用于sentinel功能的代码
初始化sentinel状态，根据给定的配置文件，初始化监控的master服务器列表
创建连向master的连接。

sentinel专用配置文件解析

 #sentinel.conf为其专用配置文件，主要设置如下参数：
#默认Port
   port 26379 
#指定要监控的master，mymaster是定义的master名字，quorum为法定票数2，此处指的是sentinel的数，只有指定的sentinel同意时才认为sentinel做的决策是有效的，一般大于sentinel数量的半数。可以有多个master，一组sentinel集群可以监控N个主从复制架构 
   sentinel monitor mymaster 127.0.0.1 6379 2   
#指定要连接的redis master密码 
   sentinel auth-pass mymaster redis  
#至少多长时间 连不上才认为主的离线了。单位为ms，   即连接超时时长
   sentinel down-after-milliseconds mymaster 30000 
# 刚刚设定为新主时，允许同时有多少个从向主发起同步请求。 
   sentinel parallel-syncs 1 
#当master故障时，把新的从提升为master，多长时间提不上就认为故障转移失败。 
   sentinel failover-timeout mymaster 180000 #故障转移的超时时长

sentinel专用命令：

sentinel masters  #获取所有监控的master
sentinel slaves   #列出该master的所有从节点 
sentinel  get-master-addr-by-name #根据master名字来获取地址 
sentinel  reset    #重置所有，从头再来 
sentinel failover   #手动故障转移,并指明向哪组master发起手动

Redis高可用配置示例

Redis版本：3.2.2
一主两从：
主：10.3.1.15 6379
从：10.3.1.15 6378
从：10.3.1.15 6376
一个Sentinel：10.3.1.17

在每个从节点的redis.conf 加上slaveof即可成为主从关系：
```
slaveof  
```
在redis.conf配置文件中bind监听如果有多个IP，应将本机IP放在前面，回环地址放在最后，因为redis通常用最前面的IP与master通信。

连接到主服务器上查看：

#可以看到主从关系已正常
127.0.0.1:6379> INFO replication
# Replication
role:master
connected_slaves:2
slave0:ip=10.3.1.15,port=6378,state=online,offset=5204,lag=1
slave1:ip=10.3.1.15,port=6376,state=online,offset=5204,lag=1
master_repl_offset:5218
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:5217
127.0.0.1:6379>

配置sentinel.conf
sentinel.conf的配置参数上面已经描述。
在前台启动sentinel

#启动sentinel 
./bin/redis-sentinel /data/service/redis/sentinel.conf  
18844:X 23 Mar 18:34:58.053 * Increased maximum number of open files to 10032 (it was originally set to 1024). 
...
...
18844:X 23 Mar 18:34:58.054 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128. 

18844:X 23 Mar 18:34:58.056 # Sentinel ID is 524c94beed78f379e4a0b3b641992449b0cdcf7f 

18844:X 23 Mar 18:34:58.056 # +monitor master mymaster 10.3.1.15 6379 quorum 2 

18844:X 23 Mar 18:34:58.057 * +slave slave 10.3.1.15:6378 10.3.1.15 6378 @ mymaster 10.3.1.15 6379 

18844:X 23 Mar 18:34:58.059 * +slave slave 10.3.1.15:6376 10.3.1.15 6376 @ mymaster 10.3.1.15 6379 
#启动完成，从控制台上面可以看到sentinel已经找到master和slave。

下面是连入sentinel 查看master信息：

root@ubuntu17:$ redis-cli -h 10.3.1.17 -p 26379 
10.3.1.17:26379> info 
DENIED Redis is running in protected mode because protected mode is enabled, no bind address was specified, no authentication password is requested to clients. In this mode connections are only accepted from the loopback interface. If you want to connect from external computers to Redis you may adopt one of the following solutions: 1) Just disable protected mode sending the command 'CONFIG SET protected-mode no' from the loopback interface by connecting to Redis from the same host the server is running, however MAKE SURE Redis is not publicly accessible from internet if you do so. Use CONFIG REWRITE to make this change permanent. 2) Alternatively you can just disable the protected mode by editing the Redis configuration file, and setting the protected mode option to 'no', and then restarting the server. 3) If you started the server manually just for testing, restart it with the '--protected-mode no' option. 4) Setup a bind address or an authentication password. NOTE: You only need to do one of the above things in order for the server to start accepting connections from the outside.

如上，输入info后报错说是redis工作在保护模式下，通过'CONFIG SET protected-mode no 来关闭，因为默认protected-mode 为yes。
所以在所有的redis，即一主两从上都加上这句话，然后再进入sentinel输入info，仍然报此错，于是尝试在sentinel本身的sentinel.conf文件中加入了这句，保存并重启sentinel，然后执行info就不报错了。

部署成功性验证：

#显示正常
10.3.1.17:26379> INFO 
# Sentinel 
sentinel_masters:1 
sentinel_tilt:0 
sentinel_running_scripts:0 
sentinel_scripts_queue_length:0 
sentinel_simulate_failure_flags:0 
master0:name=mymaster,status=ok,address=10.3.1.15:6379,slaves=2,sentinels=1 
10.3.1.17:26379>

#获取sentinel 所监控的redis master服务器信息 
10.3.1.17:26379> sentinel masters 
1)  1) "name" 
     2) "mymaster" 
     3) "ip" 
     4) "10.3.1.15" 
     5) "port" 
     6) "6379" 
     7) "runid" 
     8) "3520e56cadc7a3cd591da0094199d46a83771318" 
     9) "flags" 
   10) "master"
   11) "link-pending-commands" 
   12) "0" 
   13) "link-refcount" 
   14) "1" 
   15) "last-ping-sent" 
   16) "0" 
   17) "last-ok-ping-reply" 
   18) "697" 
   19) "last-ping-reply" 
   20) "697" 
   21) "down-after-milliseconds" 
   22) "30000"

高可用验证：
当把主master 停掉，在sentinel控制台中可以看到详细的故障转移过程：

62360:X 24 Mar 13:05:53.197 # +sdown master mymaster 10.3.1.15 6379  #主观认为master已失效 

62360:X 24 Mar 13:05:53.197 # +odown master mymaster 10.3.1.15 6379 #quorum 1/1  #客观认为master已失效 

62360:X 24 Mar 13:06:07.965 # +new-epoch 13  #准备进master新一纪元，第13次选举。 

62360:X 24 Mar 13:06:07.965 # +try-failover master mymaster 10.3.1.15 6379  #尝试转移master 

62360:X 24 Mar 13:06:07.967 # +vote-for-leader 9cf767f451de09136054ccc6afc6dcc5f939b5a0 13  #投票选举leader 

62360:X 24 Mar 13:06:07.967 # +elected-leader master mymaster 10.3.1.15 6379  #之前被选举出来的 master 

62360:X 24 Mar 13:06:07.967 # +failover-state-select-slave master mymaster 10.3.1.15 6379 #Leader开始select合适的master 

62360:X 24 Mar 13:06:08.034 # +selected-slave slave 10.3.1.15:6376 10.3.1.15 6376 @ mymaster 10.3.1.15 6379 #已找到了合适的从10.3.1.15:6376为主 

62360:X 24 Mar 13:06:08.034 * +failover-state-send-slaveof-noone slave 10.3.1.15:6376 10.3.1.15 6376 @ mymaster 10.3.1.15 6379 #Leader 向 slave 发送“slaveof no one”指令，此时 slave 已经完成角色转换，此 slave 即为 master 

62360:X 24 Mar 13:06:08.093 * +failover-state-wait-promotion slave 10.3.1.15:6376 10.3.1.15 6376 @ mymaster 10.3.1.15 6379 #等待其他 sentinel 确认 slave 

62360:X 24 Mar 13:06:09.116 # +promoted-slave slave 10.3.1.15:6376 10.3.1.15 6376 @ mymaster 10.3.1.15 6379 #确认成功 

62360:X 24 Mar 13:06:09.116 # +failover-state-reconf-slaves master mymaster 10.3.1.15 6379 #开始对slaves进行reconfig 操作 

62360:X 24 Mar 13:06:09.176 * +slave-reconf-sent slave 10.3.1.15:6378 10.3.1.15 6378 @ mymaster 10.3.1.15 6379 #向指定的slave 发送“slaveof”指令，告知此 slave 跟随新的 master 

62360:X 24 Mar 13:06:10.132 * +slave-reconf-inprog slave 10.3.1.15:6378 10.3.1.15 6378 @ mymaster 10.3.1.15 6379 开始对slaves进行reconfig 操作

然后进入sentinel中查看新的master：

10.3.1.17:26379> sentinel masters 
 #可以看到master已经发生了改变
1)  1) "name" 
     2) "mymaster" 
     3) "ip"  
     4) "10.3.1.15"   
     5) "port" 
     6) "6376" 
     7) "runid"

回到某个slave节点查看：

10.3.1.15:6378> config get slaveof 
1) "slaveof" 
2) "10.3.1.15 6376" 
10.3.1.15:6378>

现在把原来的master 6379启动起来，再看下它是主还是从：

10.3.1.15:6379> config get slaveof 
1) "slaveof" 
2) "10.3.1.15 6376" 
#原来的master，此时已是从节点了

现在进入新选举出来的master查看：

10.3.1.15:6376> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=10.3.1.15,port=6379,state=online,offset=707098,lag=1
slave1:ip=10.3.1.15,port=6379,state=online,offset=707013,lag=1
master_repl_offset:707098
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:707097
10.3.1.15:6376>

以上就是Redis sentinel就是高可用功能，应用程序应该向sentinel发请求，去寻求新Master的地址，这时要用redis专用程序,根据sentinel反馈来联络新服务器。

分享标题：Redis高可用部署
文章源于：http://cqcxhl.com/article/jjssdo.html