五月婷婷综合网,综合网伊人,综合久久99

因為項目的原因采用了redis cluster，3主3從，每臺主機1主1從，集群信息如下：

10.135.255.72:20011> cluster nodes

7b662b36489a6240aa21d1cf7b04b84019254b63 10.135.255.74:20012 slave 85c78164a448fb9965e22447429a56cab226c68f 0 1537239581900 43 connected

61c3e1a640e71f4801d850c901dd33f0b4f6876d 10.135.255.73:20012 slave 8e3491125e105333958dd752ee0d0b0a41ed2d90 0 1537239582300 41 connected

85c78164a448fb9965e22447429a56cab226c68f 10.135.255.73:20011 master - 0 1537239581999 43 connected 5461-10922

8e3491125e105333958dd752ee0d0b0a41ed2d90 10.135.255.72:20011 myself,master - 0 0 41 connected 0-5460

92eadfb6acbd0db74a8b8860286a7f63abce140e 10.135.255.74:20011 master - 0 1537239581799 44 connected 10923-16383

7084c1d7950b83abc1e4419500e1c24a9fa108e7 10.135.255.72:20012 slave 92eadfb6acbd0db74a8b8860286a7f63abce140e 0 1537239581499 44 connected

redis cluster經過運行一段時間后，會經常發生主從關系的自動切換，比如：10.135.255.74:20012變成master，10.135.255.73:20011變成slave，這樣就會導致10.135.255.74:20011和10.135.255.74:20012變成雙master，這樣假如10.135.255.74這臺主機發生宕機，就會導致2個master不可用，導致cluster down（ps:redis cluster中一半以上的master故障會導致 cluster down）。此問題困擾項目組很久，一直未找到根本原因。

后來經過多次查閱資料，應該是redis.conf里的集群節點的超時時限參數cluster-node-timeout配置的是2000（2秒），這里簡單講解下該參數的作用：

一、節點失效檢測

1.集群中當一個節點向另一個節點發送ping命令，但是目標節點未在給定的時限內返回ping命令的回復時，那么發送命令的節點會將目標節點標記為pfail(possible failuer，可能已失效)；

等待節點回復的時限稱為節點超時時限（node timeout），是一個節點選項（node-wise setting）;

二、集群狀態檢測

每當集群發生配置變化時（可能是哈希槽更新，也可能是某個節點進入失效狀態），集群中的每個節點都會對它所知道的節點進行掃描（scan）;

一旦配置完畢，集群就會進入兩種狀態中的一種：

fail：集群不能正常工作，當集群中有某個節點進入失效狀態時，集群不能處理任何命令請求，對于每個命令請求，集群節點都返回錯誤回復；

ok：集群可以正常工作，負責處理全部16384個槽節點中，沒有一個被標記為fail狀態；

三、從節點選舉

一旦某個主節點進入了fail狀態，如果這個主節點有一個或者多個從節點存在，那么其中一個從節點會被升級為主節點，而其它從節點會開始對這個新主節點進行復制；

在實際生產使用過程中，由于網絡順時延遲或者cluster某些節點正在進行持久化，aof重寫、master-slave同步數據這些耗時的操作，可能就會產生節點檢測超時（>2000ms）從而失效，為了避免節點檢測過于靈敏，經過多次調整實踐，在該項目的實際生產環境中，將cluster-node-timeout調整為12000ms后，比較穩定，既不輕易發生主從自動切換，也在真正master節點主機宕機后，slave能迅速選舉為主，保證redis cluster可用。

補充：記一次redis主從切換故障解決

問題描述：

在虛擬機機上配置了一主二從三哨兵，主機宕機后其中一臺從機自動切換為主機成功。重啟之前的主機卻連不上新的主機。

Redis Cluster集群主從切換的踩坑與填坑