FE層的架構都能在網上找到說明. 但BE層的架構模式、一致性保障、與FE層之間的請求邏輯，數據傳輸邏輯等，我個人暫時沒有找到相應的博客說明這些的。當然這些是我個人在學習與使用Doris過程中，對內部交互邏輯與實現感興趣才有這些疑問. 還好現在有GPT這類大模型，有了疑問，只要問題描述得當，大多可以解 ...
FE層的架構都能在網上找到說明. 但BE層的架構模式、一致性保障、與FE層之間的請求邏輯，數據傳輸邏輯等，我個人暫時沒有找到相應的博客說明這些的。當然這些是我個人在學習與使用Doris過程中，對內部交互邏輯與實現感興趣才有這些疑問. 還好現在有GPT這類大模型，有了疑問，只要問題描述得當，大多可以解惑.
BE節點選擇策略
FE（Frontend）節點與 BE（Backend）節點之間的通信是通過 HTTP 協議進行的。
以下是 FE 節點選擇 BE 節點的一般策略：
-
負載均衡： FE 節點會考慮集群中各個 BE 節點的負載情況，選擇負載相對較低的節點來發送請求。這有助於確保集群資源得到均勻利用，避免出現單一節點負載過高的情況。
-
數據分佈： Doris 使用分區來存儲數據，FE 節點在執行查詢請求時通常會選擇負責相應分區的 BE 節點。這樣可以最大程度地減少數據的傳輸和處理時間，提高查詢效率。
-
Replication 策略： 如果表的 replication_allocation 屬性配置了多個副本和相應的節點信息，FE 節點可能會考慮選擇其中一個副本所在的 BE 節點。這也涉及到數據的複製和容錯機制。
-
故障容忍： FE 節點需要考慮 BE 節點的健康狀態。如果某個 BE 節點出現故障，FE 節點可能會選擇其他正常的節點來發送請求。這也與 Raft 協議中的 Leader-Follower 模型有關，查詢和寫入請求通常由 Leader 節點處理。
-
就近原則： 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，期待回覆吧.
