揭秘 Fluss 架构组件

这是 Fluss 系列的第四篇文章了，我们先回顾一下前面三篇文章主要说了哪些内容。

前面三篇文章可以让大家上手玩起来 Fluss 这个框架，并说明了它与 Kafka、Paimon 数据湖的关系，接下来的文章

就深入 Fluss 细节来说一下它的实现原理了，今天给大家带来的是 Fluss 架构方法的知识。

Fluss 集群由两个主要进程组成：CoordinatorServer 和 TabletServer。

file

从上面的图片看 Fluss 是一个典型的主从架构，有Client、CoordinatorServer 、TabletServer等进程，我第一眼看到这个架构感觉就有点熟悉，这分区多副本和 Kafka 架构非常像。

下面我通过一条数据的生命周期的小故事给大家描述 Fluss 架构中这些服务组件的主要功能和工作流程。

一个风和日丽的早晨，小数据“订单 1001”诞生了。它的妈妈是个电商用户小明，爸爸是一条代码（API）。小明通过 Fluss 的 App（Client）下了一单，内容如下：

订单号：1001，金额：4999 元，状态：待发货，时间：2024-12-25 09:00:00

在被创建的瞬间，小数据便穿过了网络，奔向 Fluss 的大门。它的梦想是被记录、管理、查询，甚至有朝一日成为运营分析的明星数据！

小数据“订单 1001”刚一到达 Fluss，就立刻被送到了 CoordinatorServer（总部控制中心），它可是 Fluss 的大脑！CoordinatorServer 一看到小数据，立刻开始规划它的未来，像极了一个靠谱的职业规划师：

规划好这一切后，CoordinatorServer 给小数据指了条明路：“去吧，到东区分拣中心报道！”

小数据一路风尘仆仆，终于来到了 东区分拣中心（TabletServer）。这里是 Fluss 的数据加工厂，专门负责记录、存储和查询小数据。

东区分拣中心一看到小数据，马上给它安排了两份档案：

LogStore（日志部门）： LogStore 是个勤劳的“打工人”，专门记录小数据的每一步人生足迹：
```
[时间：2024-12-25 09:00:00] 创建订单：订单号 1001，状态：待发货
```
小数据兴奋极了：“我的人生从这里被记录下来啦！”
KvStore（仓库）： KvStore 是分拣中心的“仓库管理员”，专门保存小数据的状态和内容，以备后续查询。KvStore 给小数据安排了个“货架”：
```
货架位置：东区仓库 001，数据状态：待发货
```

“好耶！”小数据开心地在自己的货架上安顿下来。

就在 9:30，小数据的人生迎来了第一个重要的“更新”。妈妈小明得到了快递信息：“您的订单已发货！”

于是，小数据的状态从“待发货”更新为“已发货”。分拣中心马上展开协作：

LogStore 记录变更： LogStore 再次记录下小数据的人生足迹：
```
[时间：2024-12-25 09:30:00] 更新状态：已发货
```
KvStore 更新状态： KvStore 将仓库里的数据替换为最新状态：
```
货架位置：东区仓库 001，数据状态：已发货
```

小数据感叹：“原来我的人生是可以改写的！”

东区分拣中心最近有点忙，有些数据开始超载。就在这时，Fluss 的 “通信协调员”（ZooKeeper）站了出来：“不用慌！一切有我协调。”

ZooKeeper 通知总部，将一部分数据任务转移到北区的分拣中心，以确保整个系统的平稳运行。小数据惊叹：“原来我有这么多后备选项！”

随着时间的推移，越来越多的数据涌入东区分拣中心，小数据意识到它的时代要结束了。

为了让分拣中心有更多存储空间，小数据和它的伙伴们被转移到了 远程云存储（Remote Storage）。这就像是档案馆，它保存了所有历史数据。

“虽然我不再活跃，但我的人生还会被查阅！未来的人们可以分析我。”小数据在档案馆安然入眠。

就在小数据以为自己会默默无闻地躺着时，突然，一条查询指令将它唤醒：

SELECT status FROM orders WHERE order_id = 1001;

系统快速检索：

小数据以它的最新状态“已发货”再次出现在查询结果中：“原来，我一直在被需要！”

到了年底，Fluss 公司还通过批量分析指令：

SELECT SUM(amount) FROM orders WHERE year(order_time) = 2024;

运营团队惊喜地发现，小数据贡献了 4999 元销售额！“我成了分析中的重要一环！”