张颖月双11大促的流式计算链路，过去几年我一直觉得已经到了“天花板”：Kafka扛写入、Flink做计算、数仓出报表，这套组合拳打了这么多年，该挖的潜力都挖得差不多了。直到Fluss这个名字开始在团队内部被反复提起，我才意识到，流数据的存储和流转方式，可能真的到了要变天的时候。
当时第一反应是：又来一个“Kafka杀手”？但仔细看完Fluss的设计思路和阿里双11的落地数据后，我得说，这玩意儿不是来杀Kafka的，它是来革“流存储”这个概念的命的。今天就用一篇长文，把Fluss在双11万亿级消息场景下的落地实践、核心原理、踩坑记录和选型思考一次性讲透。这篇文章不涉及内部保密数据，所有指标和架构描述都基于公开分享和技术原理推导，重点是讲清楚“为什么这么做”和“这么做解决了什么”。
1. 双11流计算场景，到底难在哪
1.1 传统Kafka架构的“三座大山”
聊Fluss之前，必须先说清楚双11的流计算链路为什么需要一场变革。很多人对双11数据量的理解就是“大”，但大在哪里，大出什么麻烦，才是关键。
以核心交易链路为例，每秒钟产生的用户行为事件、订单状态变更、库存扣减消息，峰值时能到亿级条每秒。这个量级下，Kafka其实已经非常吃力了。我经历的几年大促，Kafka集群团队最怕的就是三件事：磁盘写满、分区热点、消费积压。
磁盘写满本质上是容量规划问题，双11的流量峰值是日常的几十倍，你不可能按峰值去常年准备机器，那成本没人扛得住。分区热点是数据倾斜问题，某个爆款商品的sku消息量可能是普通商品的几百倍，单个分区的写入和消费都会成为瓶颈。消费积压更头疼，下游Flink作业消费不过来，offset越拉越远，一旦积压超过Kafka的保留时间，数据就丢了，这对交易链路来说是绝对不可接受的。
更隐形的问题在于，Kafka里的数据和最终进数仓的数据是两套体系。Kafka里的消息是临时缓冲区，7天后清掉，数据湖里才是最终结果。这意味着实时链路和离线链路之间存在一条天然的“数据沟壑”——实时作业需要的数据，离线作业得重新从源头拉一遍，或者通过额外的同步任务去补齐。双11这种场景下，数据重复计算、链路重复建设带来的资源浪费，简直触目惊心。
1.2 为什么“流存储”不能只是消息队列
我自己的理解是，Kafka本质上是“消息管道”，它的核心设计目标是削峰填谷、解耦生产者和消费者。但出现了一个限制：消息一旦被消费，对应用而言就处于“已读”状态，数据本身不承载业务语义，只是一条字节流。下游要查询某个key的状态，对不起，Kafka不提供这个能力，你得自己去建索引、存状态。
这就导致一个很尴尬的局面：流计算作业为了做状态管理，必须依赖RocksDB这类嵌入式KV存储，状态一大了，checkpoint就慢，恢复就慢，双11这种对精确一次语义要求极高的场景，运维压力非常大。
Fluss切入的正是这个痛点。它不再把自己定位成“消息队列”，而是定位成“流存储”——一个既保留了消息队列的流式读写能力，又具备了存储系统该有的查询能力、更新能力和数据组织形式的新型存储层。换句话说，它让“流”和“表”不再是对立的，而是同一份数据的两种视图。
这个定位变化带来的影响是巨大的。数据写入Fluss后，实时计算可以消费它，离线分析可以直接查询它，两个链路共用同一份存储，不需要重复搬运数据。而且Fluss支持主键更新和点查，这意味着流计算的状态可以部分下沉到存储层，Flink作业的本地状态压力大幅降低，checkpoint和恢复的速度提升非常明显。这些都是传统Kafka链路里想都不敢想的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。