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

轉載于:https://blog.51cto.com/lookingdream/1812863

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的redis sentinel 主从切换(failover)解决方案，详细配置的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。