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

又見阿郎發表於2023-11-22
分散式SQL資料庫

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副本，儲存結構如下所示：
1.jpg

這些副本的資料一致性是如何保障的？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，期待回覆吧.

相關文章