播面 讲讲Doris 的整体架构，FE 的三种角色（Leader、Follower、Observer）各有什么作用？
Apache Doris 是一款现代化的 MPP（大规模并行处理）分析型数据库，以其极简的架构和极致的查询性能而闻名。
下面为您详细解析 Doris 的整体架构，以及 FE（Frontend）中 Leader、Follower、Observer 三种角色的具体作用。
一、 Doris 的整体架构
Doris 的架构非常简单，只有两类进程：FE（Frontend，前端节点） 和 BE（Backend，后端节点）。它不依赖任何外部系统（如 Hadoop、Zookeeper 等），部署和运维极其简便。
1. FE (Frontend) - 前端节点
FE 是 Doris 的“大脑”，主要负责系统的元数据管理、用户连接、SQL 解析、查询计划生成以及请求路由。
- 用户接入：支持 MySQL 协议，用户可以直接使用 MySQL 客户端或 JDBC 连接 FE。
- 元数据管理：存储和管理数据库、表、分区、Tablet 等元数据信息。
- 查询规划：接收 SQL 后，进行语法分析、语义分析、优化，生成分布式的查询执行计划。
- 调度执行：将生成的执行计划分发给 BE 节点执行，并协调汇总最终结果。
2. BE (Backend) - 后端节点
BE 是 Doris 的“四肢”，负责数据的实际存储和查询计划的物理执行。
- 数据存储：负责按列格式将数据物理存储在本地磁盘上，支持多副本，后台自动执行数据压缩（Compaction）和副本修复。
- 查询执行：接收 FE 下发的执行片段（Plan Fragment），读取本地数据进行过滤、聚合、Join 等计算，并将结果返回给 FE 或其他 BE 节点。
3. 数据流与控制流
- 写入（Load/Insert）：客户端向 FE 发起写入请求，FE 规划写入路由，客户端（或 FE）直接将数据发送给相应的 BE 节点组，完成多副本写入。
- 查询（Query）：客户端向 FE 发送 SQL，FE 制定计划并下发给多个 BE 节点并行计算，BE 将结果汇总给 FE，FE 再返回给客户端。
二、 FE 的三种角色：Leader、Follower、Observer
为了保证系统的高可用（HA）和读写性能，Doris 的 FE 采用了基于 BDB-JE（Berkeley DB Java Edition）的 Paxos 共识算法来管理元数据。在这个集群中，FE 被划分为了三种角色：
1. Leader（也常被称为 Master）
Leader 是 FE 集群的唯一“真神”，在同一时刻，整个 Doris 集群只有一个 Leader 节点。
- 核心作用：
- 唯一写节点：所有对元数据的修改（如建表、删表、导入数据产生的元数据变更、用户权限修改等）都必须由 Leader 执行。
- 集群管理：负责处理节点（FE/BE）的加入和下线、心跳检测、副本均衡、后台任务调度（如发起 Compaction 等）。
- 工作机制：如果客户端将写请求发送给了 Follower 或 Observer，它们会将写请求转发（Forward）给 Leader 执行。
2. Follower（跟随者）
Follower 是 Leader 的“备胎”和“表决团”。
- 核心作用：
- 高可用保障（热备）：实时同步 Leader 的元数据日志（Edit Log）。当 Leader 节点宕机时，Follower 们会通过 Paxos 协议发起投票，选举出新的 Leader，保证集群可用。
- 分担读请求：可以处理客户端的连接请求，直接执行只读的查询（SELECT）操作，减轻 Leader 的压力。
- 工作机制：Follower 参与元数据写入的多数派投票。Leader 在写入一条元数据日志时，必须等待半数以上的 Follower（包括 Leader 自己）确认写入成功，这条记录才算真正提交。
3. Observer（观察者）
Observer 是 FE 集群的“旁观者”和“读扩展器”。
- 核心作用：
- 纯粹的读扩展：它的主要目的是为了横向扩展 FE 的查询并发能力。当有大量的并发连接和查询请求时，可以通过增加 Observer 来分担负载。
- 不参与投票：它实时异步地从 Leader 同步元数据，但不参与 Leader 的选举，也不参与元数据写入时的多数派确认。
- 工作机制：因为不参与投票，增加 Observer 不会拖慢 Leader 的写入性能（Leader 写元数据不需要等 Observer 确认）。但它的元数据可能会比 Leader 稍微有几毫秒的延迟。
三、 三种角色的对比与部署建议
| 特性 | Leader | Follower | Observer |
|---|---|---|---|
| 数量 | 1个 | 多数派（通常与 Leader 合计 3 个） | 0 到 N 个 |
| 元数据修改 (DDL/DML) | 直接执行 | 接收后转发给 Leader | 接收后转发给 Leader |
| 查询请求 (SELECT) | 直接执行 | 直接执行 | 直接执行 |
| 是否参与写入确认 | 是 | 是 | 否 |
| 是否参与 Leader 选举 | 是（自身可能宕机） | 是（可能被选为新 Leader） | 否 |
| 主要定位 | 集群大脑、写入口 | 高可用热备、参与共识 | 扩展查询并发、不影响写入 |
💡 生产环境部署最佳实践：
- FE 节点总数推荐：至少部署 3 个 FE 节点组成高可用集群（1 个 Leader + 2 个 Follower）。
- 避免偶数个 Follower：由于共识算法需要“多数派”，部署 2 个或 4 个 Follower/Leader 是没有意义的（抗灾能力与少一个节点一样，即 2 个节点的容灾能力等于 1 个，4 个等于 3 个）。所以 Follower 组（包含 Leader）一般是 1、3、5 台。
- 何时使用 Observer：如果 3 个 FE（1 Leader + 2 Follower）已经满足了元数据的高可用，但由于业务并发极大，导致 FE 成为查询瓶颈时，不要再增加 Follower，而是增加 Observer。这样既提升了查询并发，又不会增加元数据同步的投票开销。