聊聊分布式 SQL 数据库Doris(四)

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节点集群是主副本架构么？

如下是文心一言的回答:

在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，期待回复吧.