談一談redis集羣(二)

Redis在集羣時，你們比較關心的有二點: 1.高併發性性 2.高可用性

上一次講redis集羣時，只要集羣節點的數量增長，就能夠提升併發性。今天來聊聊redis 集羣時的可用性。此次模擬生產環境中redis的節點崩潰或者失去鏈接，這個節點恰巧是master,驗證集羣的可用性.

測試場景 windows , 3個redis 節點  127.0.0.1:7001(slaver) ，127.0.0.1:7002(master) ， 127.0.0.1:7003(slaver)。

首先，啓動節點及哨兵文件，具體方法再也不詳細說明，詳見上一篇 談一談 redis 集羣.

 7002做爲master,咱們看一下7002的啓動日誌:

7002 完成對 7001 ，7003 的集羣。

測試一下數據，首先在7002中，加了一條記錄： yu3 lei3

查看7001，7003的數據：

2個slaver都是數據從無到有，集羣已經完成。

如今測試一下把 7002這個master down掉，看看會發生什麼。

執行命令：redis-cli -p 7002 debug sleep 100 

讓7002這個主節點休息100秒。

這個時候主節點休眠的狀況下測試redis集羣是否能夠工做。客戶端試着向7001插入一條記錄

剛開始查詢一下redis內存，提示 鏈接停止了. 設想一下，爲何client會斷開，是由於master崩潰而斷開嗎？

我感受不像，redis server一直開着工做正常，僅僅是client斷開，強制client 做一次reset. 接下來咱們重連 插入一條記錄。

再來看一下7003:

一樣也須要重連client, slave7001插入的記錄在slave7003獲取到了。

這時7002的休眠也結束了，看一下7002中的數據

7002這個原來的master獲取到了7001slave的數據。

這證實了咱們的集羣在master崩潰時，仍然能夠工做的. redis集羣的的可用性真的很強大.

看一下7001的server日誌:

能夠看出7001 經歷了3個過程:1.做爲slave,並從master7002同步了47字節的數據

2.發現訪問不到master7002了

3. 成爲master開始同步7003,過了大概106秒左右(咱們將7002休眠了100秒),

又開始同步7002.

看下7002 的server日誌：

剛開始是master,後來斷開了鏈接，最後成爲了slave.

再看一下7003的log:

sentinal 7001日誌: 

sentinal 7002日誌: 

sentinal 7003日誌: 

日誌比較多，能夠大概看一下quorum， 這是動物園飼養員的技能。還有epoch, 更加肯定了。

此次日誌不少，整理一下日誌顯示出來的結果。

3個redis 節點 7001 7002（master) 7003作集羣。

7002 休眠100秒，7001成爲新master ，7003仍是slave,7002 醒來時7001已經成爲新一代的master，7002 再也不繼續作master而成爲slave .