Redis Cluster 原理說的頭頭是道,這些配置不懂就是紙上談兵

Redis Cluster 原理說的頭頭是道,這些配置不懂就是紙上談兵

Redis Cluster 集羣相關配置,使用集羣方式的你必須重視和知曉。彆嘴上原理說的頭頭是道,而集羣有哪些配置?如何配置讓集羣快到飛起,實現真正的高可用卻一頭霧水,通過下面這些配置詳解也讓你對集羣原理更加深刻。

cluster-enabled

普通的 Redis 實例是不能成爲集羣的一員,想要將該節點加入 Redis Cluster,需要設置 cluster-enabled yes

cluster-config-file

cluster-config-file nodes-6379.conf 指定集羣中的每個節點文件。

集羣中的每個節點都有一個配置文件,這個文件並不是讓程序員編輯的,是我自己創建和更新的,每個節點都要使用不同的配置文件,一定要確保同一個集羣中的不同節點使用的是不同的文件。

cluster-node-timeout

設置集羣節點不可用的最大超時時間,節點失效檢測。集羣中當一個節點向另一個節點發送PING命令,但是目標節點未在給定的時限內返回PING命令的回覆時,那麼發送命令的節點會將目標節點標記爲PFAIL(possible failuer,可能已失效);

如果master 節點超過這個時間還是無響應,則用它的從節點將啓動故障遷移,升級成主節點。

注意,任何一個節點在這個時間之內如果還是沒有連上大部分的主節點,則此節點將停止接收任何請求。

默認配置是 cluster-node-timeout 15000,單位是毫秒數。

cluster-port

該端口是集羣總線監聽 TCP 連接的端口,默認配置爲 cluster-port 0,我就會把端口綁定爲客戶端命令端口 + 10000(客戶端端口默認 6379,所以綁定爲 16379 作爲集羣總線端口)。每個 Redis Cluster 節點都需要開放兩個端口:

  • 一個用於服務於客戶端的 TCP 端口,比如 6379.
  • 另一個稱爲集羣總線端口,節點使用集羣總線進行故障監測、配置更新、故障轉移等。客戶端不要與集羣總線端口通信,另外請確保在防火牆打開這兩個端口,否則 Redis 集羣接地那將無法通信。

cluster-replica-validity-factor

該配置用於決定當 Redis Cluster 集羣中,一個 master 宕機後,如何選擇一個 slave 節點完成故障轉移自動恢復(failover)。如果設置爲 0 ,則不管 slave 與 master 之間斷開多久,都認爲自己有資格成爲 master。

下面提供了兩種方式來評估 slave 的數據是否太舊。

  • 如果有多個 slave 可以 failover,他們之間會通過交換信息選出擁有擁有最大複製 offset 的 slave 節點。
  • 每個 slave 節點計算上次與 master 節點交互的時間,這個交互包含最後一次 ping 操作、master 節點傳輸過來的寫指令、上次可 master 斷開的時間等。如果上次交互的時間過去很久,那麼這個節點就不會發起 failover。

針對第二點,交互時間可以通過配置定義,如果 slave 與 master 上次交互的時間大於 (node-timeout * cluster-replica-validity-factor) + repl-ping-replica-period,該 slave 就不會發生 failover。

例如,``node-timeout = 30 秒,cluster-replica-validity-factor=10repl-ping-slave-period=10`秒, 表示slave節點與master節點上次交互時間已經過去了310秒,那麼slave節點就不會做failover。

調大 cluster-replica-validity-factor 則允許存儲過舊數據的 slave 節點提升爲 master,調小的話可能會導致沒有 slave 節點可以升爲 master 節點。

考慮高可用,建議大家設置爲 cluster-replica-validity-factor 0

cluster-migration-barrier

沒有 slave 節點的 master 節點稱爲孤兒 master節點,這個配置就是用於防止出現裸奔的 master。

當某個 master 的 slave 節點宕機後,集羣會從其他 master 中選出一個富餘的 slave 節點遷移過來,確保每個 master 節點至少有一個 slave 節點,防止當孤立 master 節點宕機時,沒有slave節點可以升爲 master 導致集羣不可用。

默認配置爲 cluster-migration-barrier 1,是一個遷移臨界值。

含義是:遷移後 master 節點至少還有 1 個 slave 節點才能做遷移操作。比如 master A 節點有2個以上 slave 節點 ,當集羣出現孤兒 master B 節點時,A 節點富餘的 slave 節點可以遷移到 master B 節點上。

生產環境建議維持默認值,最大可能保證高可用,設置爲非常大的值或者配置 cluster-allow-replica-migration no 禁用自動遷移功能。

cluster-allow-replica-migration 默認配置爲 yes,表示允許自動遷移。

cluster-require-full-coverage

默認配置是 yes,表示爲當 redis cluster 發現至少還有一個 哈希槽沒有被分配時禁止查詢操作。

這就會導致集羣部分宕機,整個集羣就不可用了,當所有哈希槽都有分配,集羣會自動變爲可用狀態。

如果你希望 cluster 的子集依然可用,配置成 cluster-require-full-coverage yes

cluster-replica-no-failover

默認配置爲 no,當配置成 yes,在master 宕機時,slave 不會做故障轉移升爲 master。

這個配置在多數據中心的情況下會很有用,你可能希望某個數據中心永遠不要升級爲 master 節點,否則 master 節點就漂移到其他數據中心了。

cluster-allow-reads-when-down

默認是 no,表示當集羣因主節點數量達不到最小值或者哈希槽沒有完全分配而被標記爲失效時,節點將停止所有客戶端請求。

設置成 yes,則允許集羣失效的情況下依然可從節點中讀取數據,保證了高可用。

cluster-allow-pubsubshard-when-down

配置成 yes,表示當集羣因主節點數量達不到最小值或者哈希槽沒有完全分配而被標記爲失效時,pub/sub 依然可以正常運行。

設置每個集羣總線連接的發送字節緩衝區的內存使用限制,超過限制緩衝區將被清空(主要爲了防止發送緩衝區發送給慢速連接時無限延長時間的問題)。

默認禁用,建議最小設置1gb,這樣默認情況下集羣連接緩衝區可以容納至少一pubsub消息(client-query-buffer-limit 默認是1gb);

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章