FE層的架構(gòu)都能在網(wǎng)上找到說明. 但BE層的架構(gòu)模式、一致性保障、與FE層之間的請求邏輯，數(shù)據(jù)傳輸邏輯等，我個人暫時沒有找到相應(yīng)的博客說明這些的。當然這些是我個人在學(xué)習與使用Doris過程中，對內(nèi)部交互邏輯與實現(xiàn)感興趣才有這些疑問. 還好現(xiàn)在有GPT這類大模型，有了疑問，只要問題描述得當，大多可以解惑.

BE節(jié)點選擇策略

FE（Frontend）節(jié)點與 BE（Backend）節(jié)點之間的通信是通過 HTTP 協(xié)議進行的。

以下是 FE 節(jié)點選擇 BE 節(jié)點的一般策略：

1. 負載均衡： FE 節(jié)點會考慮集群中各個 BE 節(jié)點的負載情況，選擇負載相對較低的節(jié)點來發(fā)送請求。這有助于確保集群資源得到均勻利用，避免出現(xiàn)單一節(jié)點負載過高的情況。

2. 數(shù)據(jù)分布： Doris 使用分區(qū)來存儲數(shù)據(jù)，F(xiàn)E 節(jié)點在執(zhí)行查詢請求時通常會選擇負責相應(yīng)分區(qū)的 BE 節(jié)點。這樣可以最大程度地減少數(shù)據(jù)的傳輸和處理時間，提高查詢效率。

3. Replication 策略： 如果表的 replication_allocation 屬性配置了多個副本和相應(yīng)的節(jié)點信息，F(xiàn)E 節(jié)點可能會考慮選擇其中一個副本所在的 BE 節(jié)點。這也涉及到數(shù)據(jù)的復(fù)制和容錯機制。

4. 故障容忍： FE 節(jié)點需要考慮 BE 節(jié)點的健康狀態(tài)。如果某個 BE 節(jié)點出現(xiàn)故障，F(xiàn)E 節(jié)點可能會選擇其他正常的節(jié)點來發(fā)送請求。這也與 Raft 協(xié)議中的 Leader-Follower 模型有關(guān)，查詢和寫入請求通常由 Leader 節(jié)點處理。

5. 就近原則： FE 節(jié)點可能會選擇距離較近的 BE 節(jié)點，以減少網(wǎng)絡(luò)延遲。這對于提高查詢和寫入的響應(yīng)速度至關(guān)重要。

這些策略和配置項通常是 Doris 內(nèi)部的機制，直接由系統(tǒng)管理。在一般情況下，用戶無需手動配置 BE 節(jié)點的選擇策略，而是通過合理配置表的副本和集群的負載均衡機制來實現(xiàn)。

副本

在創(chuàng)建表時，可以指定BE層的節(jié)點副本配置. 個人覺得這個博客寫得蠻詳細，可以詳細的看看 數(shù)據(jù)分布和副本

BE節(jié)點數(shù)據(jù)一致性

BE節(jié)點上，有著眾多的Tablet副本，這些副本的數(shù)據(jù)一致性是如何保障的？BE節(jié)點集群是主副本架構(gòu)么？

如下是文心一言的回答:

在Apache Doris中，BE節(jié)點間的數(shù)據(jù)一致性是通過副本同步和增量同步機制實現(xiàn)的。

首先，Apache Doris支持基于Paxos協(xié)議的分布式鎖機制，確保在寫入數(shù)據(jù)時，所有BE節(jié)點都能獲得相同的鎖信息。當一個BE節(jié)點獲得寫入權(quán)限并完成數(shù)據(jù)寫入后，它會將修改操作記錄到本地日志中，并利用Paxos協(xié)議將日志同步到其他BE節(jié)點。其他BE節(jié)點在接收到日志后，會根據(jù)日志內(nèi)容對數(shù)據(jù)進行相應(yīng)的修改，以保證所有節(jié)點數(shù)據(jù)的一致性。

其次，Apache Doris還支持基于時間戳的數(shù)據(jù)掃描機制，定期掃描不同節(jié)點上的數(shù)據(jù)，發(fā)現(xiàn)不一致的情況及時進行修復(fù)。當發(fā)現(xiàn)數(shù)據(jù)不一致時，BE節(jié)點會利用Paxos協(xié)議重新協(xié)商一致性，并根據(jù)協(xié)商結(jié)果進行數(shù)據(jù)修復(fù)。

此外，Apache Doris還提供了多種數(shù)據(jù)同步配置項，用戶可以根據(jù)實際需求進行設(shè)置和調(diào)整，以滿足不同的業(yè)務(wù)場景和性能需求。例如，用戶可以設(shè)置同步的副本數(shù)、同步延遲時間等參數(shù)，以確保BE節(jié)點間的數(shù)據(jù)一致性。

總之，Apache Doris通過副本同步和增量同步機制以及多種數(shù)據(jù)同步配置項的結(jié)合使用，實現(xiàn)了BE節(jié)點間的數(shù)據(jù)一致性保證。這些機制的結(jié)合使用使得Apache Doris在分布式環(huán)境下能夠提供可靠的數(shù)據(jù)一致性保證。

如下是ChatGPT的回答:

在 Apache Doris 中，BE（Backend）節(jié)點間的數(shù)據(jù)一致性是通過 Raft 一致性協(xié)議來實現(xiàn)的。Raft 協(xié)議是一種分布式一致性算法，用于確保在集群中的多個節(jié)點之間維持數(shù)據(jù)的強一致性。

以下是 BE 節(jié)點間數(shù)據(jù)一致性的基本流程：

1. Raft 組（Replica Group）： Doris 中的每個表都會被分為多個 Raft 組，每個 Raft 組包含一個 Leader 節(jié)點和多個 Followers 節(jié)點。Leader 負責處理寫入請求，而 Followers 節(jié)點負責復(fù)制 Leader 的數(shù)據(jù)。

2. Leader-Follower 模型： 在每個 Raft 組中，有一個節(jié)點被選為 Leader，其他節(jié)點成為 Followers。Leader 節(jié)點接收客戶端的寫入請求，并負責將這些寫入請求的變更復(fù)制到 Followers 節(jié)點。

3. 寫入請求的處理： 當 Leader 節(jié)點接收到寫入請求時，它會將這個寫入請求的變更記錄到其本地日志，并通過 Raft 協(xié)議將這個變更通知給 Followers 節(jié)點。

4. Quorum Commit： 在 Raft 協(xié)議中，寫入操作需要在 Leader 和大多數(shù) Followers 節(jié)點上完成才算成功。Leader 將等待大多數(shù)節(jié)點確認成功后，再向客戶端返回寫入成功的響應(yīng)。

5. Followers 數(shù)據(jù)同步： Followers 節(jié)點接收到 Leader 的寫入請求后，會將這些變更應(yīng)用到本地的存儲中，確保所有節(jié)點上的數(shù)據(jù)保持一致。

6. Leader 故障轉(zhuǎn)移： 如果 Leader 節(jié)點發(fā)生故障，Raft 協(xié)議會進行新一輪的選舉，選擇新的 Leader 節(jié)點。這確保了即使在節(jié)點故障的情況下，數(shù)據(jù)仍然能夠得到一致性的維護。

通過 Raft 協(xié)議，Doris 確保了 BE 節(jié)點之間的數(shù)據(jù)一致性。這包括對寫入操作的 Quorum Commit、Leader-Follower 模型以及節(jié)點故障時的 Leader 重新選舉等機制。Raft 協(xié)議的設(shè)計目標是在分布式環(huán)境下提供強一致性，確保數(shù)據(jù)的可靠性和一致性。

最后在github上提了個discussions，期待回復(fù)吧.

總結(jié)

以上是生活随笔為你收集整理的聊聊分布式 SQL 数据库Doris(四)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。