redis sentinel 主从切换(failover)解决方案

tedwhy

　　主
从复制简单来说就是把一台redis数据库中的数据同步到另一台redis数据库，并且按照数据流向，数据的发送者我们称作master，数据的接受者我
们称作slave（master/slave的划分并不是那么一定的，譬如B可以作为A的slave，但同时也可以作为C的master），下面就从
slave和master的角度分别说明主从复制流程。
　　首先是slave端，对于slave端来说，主从复制主要经历四个阶段：
　　第一阶段：与master建立连接
　　第二阶段：向master发起同步请求（SYNC）
　　第三阶段：接受master发来的RDB数据
　　第四阶段：载入RDB文件
　　下面我们就通过一个图来概述在每一个阶段中，slave究竟做了些什么：

　　关于上图，有一点说明下：redis接收到slaveof master_host
master_port命令后并没有马上与master建立连接，而是当执行服务器例行任务serverCron，发现自己正处于
REDIS_REPL_CONNECT状态，这时才真正的向maser发起连接，伪代码：
　　Python代码  

• 　　def serverCron():
  
• 　　# 服务器处于REDIS_REPL_CONNECT状态
  
• 　　if redisServer.repl_state == REDIS_REPL_CONNECT:
  
• 　　# 向master发起连接
  
• 　　connectWithMaster()
  
• 　　# 其他例行任务（省略）...
  

　　接着我们来看下主从复制过程中，master这边的流程是如何，在具体看细节之前，我们先综合来看master这边主要做的几件事情：

　　看完这个图，你也许会有以下几个疑问：
　　1. 为什么在master发送完RDB文件后，还要定期的向slave发送PING命令？
　　2. 在发送完RDB文件之后，master发送的“变更”命令又是什么，有什么用？
　　在回答问题之前1，我们先回答问题2：
　　master保存RDB文件是通过一个子进程进行的，所以master依然可以处理客户端请求而不被阻塞，但这也导致了在保存RDB文件期间，“键空间”
可能发生变化（譬如接收到一个客户端请求，执行"set name
diaocow"命令），因此为了保证数据同步的一致性，master会在保存RDB文件期间，把接受到的这些可能变更数据库“键空间”的命令保存下来，
然后放到每个slave的回复列表中，当RDB文件发送完master会发送这些回复列表中的内容，并且在这之后，如果数据库发生变更，master依然
会把变更的命令追加到回复列表发送给slave，这样就可以保证master和slave数据的一致性！相关伪代码：
　　Python代码  

• 　　def processCommand(cmd, argc, argv):
  
• 　　# 处理命令
  
• 　　call(cmd, argc, argv)
  
• 　　# 如果该命令造成数据库键空间变化and当前redis是一个master，则同步变更命令
  
• 　　if redisServer.update_key_space and len(redisServer.slaves) > 0:
  
• 　　replicationFeedSlaves(cmd, argc, argv)
  
• 
  
• 　　def replicationFeedSlaves(cmd, argc, argv):
  
• 　　# 把变更命令发送给每一个处于：REDIS_REPL_WAIT_BGSAVE_END状态的slave节点
  
• 　　for slave in redisServer.slaves:
  
• 　　if slave.replstate == REDIS_REPL_WAIT_BGSAVE_START:
  
• 　　continue
  
• 　　slave.updateNotify(cmd, argc, argv)
  

　　由于在发送完RDB文件之后，master会不定时的给slave发送“变更”命令，可能过1s，也可能过1小时，所以为了防止slave无意义等待（譬
如master已经挂掉的情况），master需要定时发送“保活”命令PING，以此告诉slave：我还活着，不要中断与我的连接
　　现在我们就看下，当master接受到slave发送的sync同步命令后究竟发生了哪些事：

　　上图看似分支复杂，但我们抓住以下几点即可：
　　1.保存RDB文件是在一个子进程中进行的；
　　2.如果master已经在保存RDB文件，但是没有客户端正在等待这次BGSAVE，新添加的slave需要等到下次BGSAVE，而不能直接使用这次生成的RDB文件（原因图中已经说明）
　　3.master会定期检查RDB文件是否保存完毕（时间事件serverCron）；
　　接下来我们看下，master是如何给每一个slave发送RDB文件的：

　　好了，至此我们已经分析完在主从复制过程中，master和slave两边分别是怎么一个处理流程;最后，我绘制了一个图，综述了主从复制这一过程（我们可以边看图，边回忆其中的具体细节）：

　　PS：在主从复制过程中，任何一步发生错误，都会导致整个过程重头开始，所以若RDB文件很大又或是此时正处在业务高峰期，对系统性能将会有非常大的影响！
　　总结：
　　1. 了解主从复制master和slave的概念；
　　2. 了解主从复制执行过程，特别是其中关键的几步；
　　3. 了解目前主从复制过程中尚存的不足之处；

• 　　查看图片附件
  
• 
  

　　oyhk 学习笔记
　　网站的访问量慢慢上来了。为了网站的性能方面，开始用了redis做缓存策略。刚开始的时候，redis是一个单点，当一台机器岩机的时候，redis的
服务完全停止，这时就会影响其他服务的正常运行。费话不多说了，下面利用redis
sentinel做一个主从切换的集群管理。做这个集群管理的时候，查过很多资料才完全了解，他是怎么做的。
　　java 客户端请看：
　　http://blog.mkfree.com/posts/52b146e6479e5a64742fddd0
　　参考资料：http://redis.io/topics/sentinel 我也是看这篇文章。
　　环境配置：
　　由于我这次配置没有太多的机器，我用了vagrant 去开了多台虚拟机。然后搭好了环境。
　　redis的安装请参考：redis 简单官方脚本安装方法(linux)
　　集群配置最少需要三台机器，那么我就三台虚拟机,三台虚拟机分别安装同样的redis的环境
　　ip分别：

• 　　192.168.9.17  （redis sentinel 集群监控）
  
• 　　192.168.9.18  （redis 主）
  
• 　　192.168.9.19  （redis 从）
  

　　redis配置:
　　主的redis配置文件,使用默认的配置文件就可以了，如果你需要设计其他参数
　　从的redis配置文件，添加
#从的redis配置文件，需要添加vim /etc/redis/6379.conf　　
slaveof 192.168.9.18 6379
　　启动主从redis
#启动主redis（192.168.9.18）/etc/init.d/redis_6379.conf start#启动从redis（192.168.9.19）/etc/init.d/redis_6379.conf start　　查看主redis信息
#查看主redis的信息redis-cli -h 192.168.9.18 info Replication# Replicationrole:master #代表192.168.9.18:6379 这台redis是主connected_slaves:1slave0:192.168.9.18,6379,online　　查看从redis信息
#查看主redis的信息redis-cli -h 192.168.9.19 info Replication# Replicationrole:slave #代表192.168.9.18:6379 这台redis是主master_host:192.168.9.18master_port:6379master_link_status:up　　
master_last_io_seconds_ago:4master_sync_in_progress:0slave_priority:100slave_read_only:1connected_slaves:0
　　配置redis sentinel集群监控服务
　　1.添加一份redis sentinel 配置文件
vim /etc/redis/sentinel.conf##redis-0##sentinel实例之间的通讯端口port 26379#master1　　
port 26379
　　
sentinel monitor mymaster 192.168.1.211 6379 2
　　
sentinel down-after-milliseconds mymaster 5000
　　
sentinel failover-timeout mymaster 900000
　　
sentinel parallel-syncs mymaster 2
　　2.有配置文件了，那么启动redis sentinel做redis集群监听
redis-sentinel sentinel.conf --sentinel　　好了，所有环境都搭好了。下面开始正式的演示
　　1.正常演示。

• 　　把主的redis启动
  
• 　　把从的redis启动
  
• 　　把redis sentinel 集群监听启动
  

　　观察redis sentinel 日志信息

　　这里很清楚地看到，从的redis加入了集群
[4925] 15 Oct 03:42:21.889 * +slave slave 192.168.9.19:6379 192.168.9.19 6379 @ master1 192.168.9.18 6379　　执行以下命令，查看redis主从信息
[root@localhost vagrant]# redis-cli -h 192.168.9.17 -p 26379 info Sentinel# Sentinelsentinel_masters:1sentinel_tilt:0sentinel_running_scripts:0sentinel_scripts_queue_length:0master0:name=master1,status=ok,address=192.168.9.18:6379,slaves=1,sentinels=1　　那么表示一切都正常了。你的redis sentinel集群已经配置成功！
　　2.故障演示
　　2.1当主的redis 服务器岩机了，会发生什么情况呢？
　　执行以下命令使用主的redis服务停止
redis-cli -h 192.168.9.18 -p 6379 shutdown #表示把192.168.9.18这台redis 关闭　　关闭后，我们再查看redis sentinel 的日志情况

　　这张图片很清晰地反应到，redis sentinel 监控到主的redis服务停止，然后自动把从的redis切换到主。
　　再执行以下命令，查看redis主从信息
[root@localhost vagrant]# redis-cli -h 192.168.33.111 -p 26379 info Sentinel# Sentinelsentinel_masters:1sentinel_tilt:0sentinel_running_scripts:0sentinel_scripts_queue_length:0master0:name=master1,status=ok,address=192.168.9.19:6379,slaves=1,sentinels=1　　把从已经升为主了。那么自动切换就已经成功了！
　　2.2 当我们已经发现，一台redis发生故障了，可能会收到一些故障信息，那么再把服务已关闭的redis恢复服务状态，会发生怎么样的情况呢？

　　redis sentinel 集群服务，会把上次主redis重新加入服务中，但是他再以不是主的redis了，变成从的reids。
　　哈.....完成了。。。下篇会写关于，客户端调用主从集群自动切换使用例子。我会以java为使用客户端.