本片博文主要介紹：

rediscluster 主要實現的是 數據分片到每一個節點，各節點之間如何通訊并保持數據的一致性、節點狀態的同步性！如何即時刷新整個集群系統的狀態更新。

1）數據分片

??? 16384個slot

2）客戶端對每個節點請求的時候，如果是服務器端分片策略，那么當客戶端請求過來，會出現重定向的過程。

???? 服務器計算出正確的節點，并回送地址。

???? MOVE

???? ASK

3）數據同步

??? 心跳機制 ======》? header (自己的信息） + gossip（自己所知的其他節點的信息）?

4）故障恢復

??? master宕機，slave轉主。獲取版本號。發送投票請求，獲取請求回復，票數過半，轉主，發送廣播消息同步各節點信息。

Redis Cluster 實現

本文將從設計思路，功能實現幾個方面介紹Redis Cluster。（下面提到的epoch（類似于Raft算法“term”（任期））

假設讀者已經了解Redis Cluster的使用方式,不了解可以先看之前一篇介紹Redis Cluster的博客。

簡介

Redis Cluster作為Redis的分布式實現，主要做了兩個方面的事情：

1，數據分片

• Redis Cluster將數據按key哈希到16384個slot上
• Cluster中的不同節點負責一部分slot

2，故障恢復

• Cluster中直接提供服務的節點為Master
• 每個Master可以有一個或多個Slave
• 當Master不能提供服務時，Slave會自動Failover

設計思路

性能為第一目標

• 每一次數據處理都是由負責當前slot的Master直接處理的，沒有額外的網絡開銷

提高可用性

• 水平擴展能力 ：由于slot的存在，增加機器節點時只需要將之前由其他節點處理的一部分slot重新分配給新增節點。slot可以看做機器節點和用戶數據之間的一個抽象層。
• 故障恢復：Slave會在需要的時候自動提升為Master

損失一致性

• Master與Slave之間異步復制，即Master先向用戶返回結果后再異步將數據同步給Slave，這就導致Master宕機后一部分已經返回用戶的數據在新Master上不存在
• 網絡分區時，由于開始Failover前的超時時間，會有一部分數據繼續寫到馬上要失效的Master上

功能實現

1，數據分片

我們已經知道數據會按照key哈希到不同的slot，而每個節點僅負責一部分的slot，客戶端根據slot將請求交給不同的節點。將slots劃分給不同節點的過程稱為數據分片，對應的還可以進行分片的重新分配。這部分功能依賴外部調用命令：

分片

• 對每個集群執行CLUSTER ADDSLOTS slot [slot ...]
• RedisCluster將命令指定的slots作為自己負責的部分

再分配

再分配要做的是將一些slots從當前節點(source)遷移到其他節點(target)

• 對target執行CLUSTER SETSLOT slot IMPORTING [node-id]，target節點將對應slots記為importing狀態；
• 對source執行CLUSTER SETSLOT MIGRATING[node-id]，source節點將對應slots記為migrating狀態，與importing狀態一同在之后的請求重定向中使用
• 獲取所有要遷移slot對應的keys，CLUSTER GETKEYSINSLOT slot count
• 對source?執行MIGRATE host port key db timeout REPLACE [KEYS key [key ...]]
• MIGRATE命令會將所有的指定的key通過RESTORE key ttl serialized-value REPLACE遷移給target
• 對所有節點執行CLUSTER SETSLOT slot NODE [node-id]，申明target對這些slots的負責，并退出importing或migrating

2，請求重定向（服務器端分片策略，客戶端和任意的服務器節點進行連接）

由于每個節點只負責部分slot，以及slot可能從一個節點遷移到另一節點，造成客戶端有可能會向錯誤的節點發起請求。因此需要有一種機制來對其進行發現和修正，這就是請求重定向。有兩種不同的重定向場景：

1)，MOVE

• ‘我’并不負責‘你’要的key，告訴’你‘正確的吧。
• 返回CLUSTER_REDIR_MOVED錯誤，和正確的節點。
• 客戶端向該節點重新發起請求，注意這次依然又發生重定向的可能。

2），ASK

• ‘我’負責請求的key，但不巧的這個key當前在migraging狀態，且‘我’這里已經取不到了。告訴‘你’importing他的‘家伙’吧，去碰碰運氣。
• 返回CLUSTER_REDIR_ASK，和importing該key的節點。
• 客戶端向新節點發送ASKING，之后再次發起請求
• 新節點對發送過ASKING，且key已經migrate過來的請求進行響應

3），區別

區分這兩種重定向的場景是非常有必要的：

• MOVE，申明的是slot所有權的轉移，收到的客戶端需要更新其key-node映射關系
• ASK，申明的是一種臨時的狀態，所有權還并沒有轉移，客戶端并不更新其映射關系。前面的加的ASKING命令也是申明其理解當前的這種臨時狀態

3，狀態檢測及維護

Cluster中的每個節點都維護一份在自己看來當前整個集群的狀態，主要包括：

• 當前集群狀態
• 集群中各節點所負責的slots信息，及其migrate狀態
• 集群中各節點的master-slave狀態
• 集群中各節點的存活狀態及不可達投票

當集群狀態變化時，如新節點加入、slot遷移、節點宕機、slave提升為新Master，我們希望這些變化盡快的被發現，傳播到整個集群的所有節點并達成一致。

節點之間相互的心跳（PING，PONG，MEET）及其攜帶的數據是集群狀態傳播最主要的途徑。

心跳時機：

Redis節點會記錄其向每一個節點上一次發出ping和收到pong的時間，心跳發送時機與這兩個值有關。通過下面的方式既能保證及時更新集群狀態，又不至于使心跳數過多：

• 每次Cron向所有未建立鏈接的節點發送ping或meet
• 每1秒從所有已知節點中隨機選取5個，向其中上次收到pong最久遠的一個發送ping
• 每次Cron向收到pong超過timeout/2的節點發送ping
• 收到ping或meet，立即回復pong

心跳數據

• Header，發送者自己的信息
  • 所負責slots的信息
  • 主從信息
  • ip port信息
  • 狀態信息
• Gossip，發送者所了解的部分其他節點的信息
  • ping_sent, pong_received
  • ip, port信息
  • 狀態信息，比如發送者認為該節點已經不可達，會在狀態信息中標記其為PFAIL或FAIL

心跳處理

• 1，新節點加入
  • 發送meet包加入集群
  • 從pong包中的gossip得到未知的其他節點
  • 循環上述過程，直到最終加入集群
    • 2，Slots信息
      • 判斷發送者聲明的slots信息，跟本地記錄的是否有不同
      • 如果不同，且發送者epoch較大，更新本地記錄
      • 如果不同，且發送者epoch小，發送Update信息通知發送者
    • 3，Master slave信息
      • 發現發送者的master、slave信息變化，更新本地狀態
    • 4，節點Fail探測
      • 超過超時時間仍然沒有收到pong包的節點會被當前節點標記為PFAIL
      • PFAIL標記會隨著gossip傳播
      • 每次收到心跳包會檢測其中對其他節點的PFAIL標記
      • 對某個節點的PFAIL標記達到大多數時，將其變為FAIL標記并廣播FAIL消息

    注：Gossip的存在使得集群狀態的改變可以更快的達到整個集群。每個心跳包中會包含多個Gossip包，那么多少個才是合適的呢，redis的選擇是N/10，其中N是節點數，這樣可以保證在PFAIL投票的過期時間內，節點可以收到80%機器關于失敗節點的gossip，從而使其順利進入FAIL狀態。

    廣播

    當需要發布一些非常重要需要立即送達的信息時，上述心跳加Gossip的方式就顯得捉襟見肘了，這時就需要向所有集群內機器的廣播信息，使用廣播發的場景：

    • 節點的Fail信息：當發現某一節點不可達時，探測節點會將其標記為PFAIL狀態，并通過心跳傳播出去。當某一節點發現這個節點的PFAIL超過半數時修改其為FAIL并發起廣播。
    • Failover Request信息：slave嘗試發起FailOver時廣播其要求投票的信息
    • 新Master信息：Failover成功的節點向整個集群廣播自己的信息

    4，故障恢復（Failover）

    當slave發現自己的master變為FAIL狀態時，便嘗試進行Failover，以期成為新的master。由于掛掉的master可能會有多個slave。Failover的過程需要經過類Raft協議的過程在整個集群內達到一致，其過程如下：

    • slave發現自己的master變為FAIL
    • 將自己記錄的集群currentEpoch加1，并廣播Failover Request信息
    • 其他節點收到該信息，只有master響應，判斷請求者的合法性，并發送FAILOVER_AUTH_ACK，對每一個epoch只發送一次ack
    • 嘗試failover的slave收集FAILOVER_AUTH_ACK
    • 超過半數后變成新Master
    • 廣播Pong通知其他集群節點

?

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的Redis:redis cluster的实现细节的全部內容，希望文章能夠幫你解決所遇到的問題。

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