技術文章 » 聊聊分散式 SQL 資料庫Doris(四)

聊聊分散式 SQL 資料庫Doris(四)

2023-11-22 15:01:30

FE層的架構都能在網上找到說明. 但BE層的架構模式、一致性保障、與FE層之間的請求邏輯，資料傳輸邏輯等，我個人暫時沒有找到相應的部落格說明這些的。當然這些是我個人在學習與使用Doris過程中，對內部互動邏輯與實現感興趣才有這些疑問. 還好現在有GPT這類大模型，有了疑問，只要問題描述得當，大多可以解惑.

BE節點選擇策略

FE（Frontend）節點與 BE（Backend）節點之間的通訊是通過 HTTP 協定進行的。

以下是 FE 節點選擇 BE 節點的一般策略：

  1. 負載均衡： FE 節點會考慮叢集中各個 BE 節點的負載情況，選擇負載相對較低的節點來傳送請求。這有助於確保叢集資源得到均勻利用，避免出現單一節點負載過高的情況。

  2. 資料分佈： Doris 使用分割區來儲存資料，FE 節點在執行查詢請求時通常會選擇負責相應分割區的 BE 節點。這樣可以最大程度地減少資料的傳輸和處理時間，提高查詢效率。

  3. Replication 策略： 如果表的 replication_allocation 屬性設定了多個副本和相應的節點資訊，FE 節點可能會考慮選擇其中一個副本所在的 BE 節點。這也涉及到資料的複製和容錯機制。

  4. 故障容忍： FE 節點需要考慮 BE 節點的健康狀態。如果某個 BE 節點出現故障，FE 節點可能會選擇其他正常的節點來傳送請求。這也與 Raft 協定中的 Leader-Follower 模型有關，查詢和寫入請求通常由 Leader 節點處理。

  5. 就近原則： FE 節點可能會選擇距離較近的 BE 節點，以減少網路延遲。這對於提高查詢和寫入的響應速度至關重要。

這些策略和設定項通常是 Doris 內部的機制，直接由系統管理。在一般情況下，使用者無需手動設定 BE 節點的選擇策略，而是通過合理設定表的副本和叢集的負載均衡機制來實現。

副本

在建立表時，可以指定BE層的節點副本設定. 個人覺得這個部落格寫得蠻詳細，可以詳細的看看 資料分佈和副本

BE節點資料一致性

BE節點上，有著眾多的Tablet副本，儲存結構如下所示：

這些副本的資料一致性是如何保障的？BE節點叢集是主副本架構麼？是否有可能存在查詢資料時，從BE中返回不到資料，因為此時BE節點的tablet還未從其他節點同步資料過來.

如下是文心一言的回答:

在Apache Doris中，BE節點間的資料一致性是通過副本同步和增量同步機制實現的。

首先，Apache Doris支援基於Paxos協定的分散式鎖機制，確保在寫入資料時，所有BE節點都能獲得相同的鎖資訊。當一個BE節點獲得寫入許可權並完成資料寫入後，它會將修改操作記錄到本地紀錄檔中，並利用Paxos協定將紀錄檔同步到其他BE節點。其他BE節點在接收到紀錄檔後，會根據紀錄檔內容對資料進行相應的修改，以保證所有節點資料的一致性。

其次，Apache Doris還支援基於時間戳的資料掃描機制，定期掃描不同節點上的資料，發現不一致的情況及時進行修復。當發現資料不一致時，BE節點會利用Paxos協定重新協商一致性，並根據協商結果進行資料修復。

此外，Apache Doris還提供了多種資料同步設定項，使用者可以根據實際需求進行設定和調整，以滿足不同的業務場景和效能需求。例如，使用者可以設定同步的副本數、同步延遲時間等引數，以確保BE節點間的資料一致性。

總之，Apache Doris通過副本同步和增量同步機制以及多種資料同步設定項的結合使用，實現了BE節點間的資料一致性保證。這些機制的結合使用使得Apache Doris在分散式環境下能夠提供可靠的資料一致性保證。

如下是ChatGPT的回答:

在 Apache Doris 中，BE（Backend）節點間的資料一致性是通過 Raft 一致性協定來實現的。Raft 協定是一種分散式一致性演演算法，用於確保在叢集中的多個節點之間維持資料的強一致性。

以下是 BE 節點間資料一致性的基本流程：

1. Raft 組（Replica Group）： Doris 中的每個表都會被分為多個 Raft 組，每個 Raft 組包含一個 Leader 節點和多個 Followers 節點。Leader 負責處理寫入請求，而 Followers 節點負責複製 Leader 的資料。

2. Leader-Follower 模型： 在每個 Raft 組中，有一個節點被選為 Leader，其他節點成為 Followers。Leader 節點接收使用者端的寫入請求，並負責將這些寫入請求的變更復制到 Followers 節點。

3. 寫入請求的處理： 當 Leader 節點接收到寫入請求時，它會將這個寫入請求的變更記錄到其本地紀錄檔，並通過 Raft 協定將這個變更通知給 Followers 節點。

4. Quorum Commit： 在 Raft 協定中，寫入操作需要在 Leader 和大多數 Followers 節點上完成才算成功。Leader 將等待大多數節點確認成功後，再向使用者端返回寫入成功的響應。

5. Followers 資料同步： Followers 節點接收到 Leader 的寫入請求後，會將這些變更應用到原生的儲存中，確保所有節點上的資料保持一致。

6. Leader 故障轉移： 如果 Leader 節點發生故障，Raft 協定會進行新一輪的選舉，選擇新的 Leader 節點。這確保了即使在節點故障的情況下，資料仍然能夠得到一致性的維護。

通過 Raft 協定，Doris 確保了 BE 節點之間的資料一致性。這包括對寫入操作的 Quorum Commit、Leader-Follower 模型以及節點故障時的 Leader 重新選舉等機制。Raft 協定的設計目標是在分散式環境下提供強一致性，確保資料的可靠性和一致性。

最後在github上提了個discussions，期待回覆吧.