redis sentinel 主從切換(failover)解決方案，詳細配置

主從復制簡單來說就是把一臺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代碼  

1. def serverCron():  

2.     # 服務器處于REDIS_REPL_CONNECT狀態  

3.     if redisServer.repl_state == REDIS_REPL_CONNECT:  

4.         # 向master發起連接  

5.         connectWithMaster()  

6.     # 其他例行任務（省略）...  

接著我們來看下主從復制過程中，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代碼  

1. def processCommand(cmd, argc, argv):  

2.     # 處理命令  

3.     call(cmd, argc, argv)  

4.     # 如果該命令造成數據庫鍵空間變化and當前redis是一個master，則同步變更命令  

5.     if redisServer.update_key_space and len(redisServer.slaves) > 0:  

6.         replicationFeedSlaves(cmd, argc, argv)  

7.   

8. def replicationFeedSlaves(cmd, argc, argv):   

9.     # 把變更命令發送給每一個處于：REDIS_REPL_WAIT_BGSAVE_END狀態的slave節點  

10.     for slave in redisServer.slaves:  

11.         if slave.replstate == REDIS_REPL_WAIT_BGSAVE_START:  

12.             continue  

13.         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.confslaveof 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
sentinel monitor master1 192.168.9.18 6379 1sentinel down-after-milliseconds master1 5000sentinel failover-timeout master1 900000sentinel can-failover master1 yes
sentinel parallel-syncs master1 2#master2  可以添加多組主從的redis監聽.......

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。