Fluss流存储实战：双11万亿级消息下的Flink实时计算架构与排障

双11的零点，流量曲线能冲到什么程度，经历过的人都不会忘。以电商核心链路的实时计算为例，每秒峰值消息量可以到亿级，Flink作业的吞吐必须跟着这个节奏走，而底层的消息队列一旦成为瓶颈，整个实时链路就会被拖垮。过去几年大家普遍用Kafka扛这类场景，但在双11这种“流量洪峰+长尾稳定性+成本控制”同时压过来的极端条件下，Kafka的短板其实很明显——分区热、Rebalance抖动、存储成本高、冷读延迟大。这也是Fluss这类实时流存储（Streaming Storage）出现并被阿里大规模落地的直接原因。

Fluss，简单说，是一套面向实时数据流场景的分布式存储系统，核心定位不是做消息队列，而是做“能支撑大规模流式读写、同时具备强一致语义和低成本存储”的流存储底座。它天然适配Flink生态，在阿里双11这种万亿级消息量场景里，承担的是实时特征、实时数仓、近实时湖仓分析等链路的存储与分发职责。这篇文章，我就基于双11保障过程中的实际经验，把Fluss在超大规模场景下的架构思路、核心设计、落地步骤、容量规划以及典型排障经验一次性讲透。无论你是在做实时数仓、消息中间件选型，还是在头疼大促链路保障，这篇都值得收藏。

1. 为什么是Fluss，而不是继续用Kafka

1.1 大促场景对消息链路提出的几个苛刻要求

先回到双11的场景本身。零点大促一开闸，流量不是平滑爬坡，而是在几十秒内陡增数倍甚至十几倍。第一轮冲击打在接入层，紧接着就是实时链路。实时链路里最常见的是两类负载：一类是流式计算，典型如Flink作业在做实时ETL、实时特征拼接、实时风控；另一类是近实时分析，典型是把实时写入的数据在分钟级延迟内同步到湖仓，供BI查询和离线任务读取。

这两类负载叠加在一起，对大促核心消息链路的要求可以拆成四条：

• 写入峰值吞吐要足够高。大促的写入不是单topic的均匀写入，而是成千上万的topic同时高吞吐写入，单集群需要支撑的写入QPS要用“亿条/秒”这个量级去估。
• 消费端要能跟得上。流式任务最怕的不是写入慢，而是某个分区消费端积压。积压一旦出现，实时特征就变成延迟特征，风控规则、推荐排序全都会受影响。
• 存储成本不能失控。大促消息要保留一段时间供回放和追数据，按Kafka的方式每个分区多副本落本地磁盘，几十TB甚至PB级别的存储成本是很吓人的。
• 大促结束后的缩容、扩容以及长尾任务的稳定性。Kafka的Rebalance在大规模、高频扩容场景下会放大抖动，而大促恰恰是需要频繁调整资源的时段。

这四条，单靠Kafka去优化，基本是打补丁式的。你可以在服务端调参数，可以在客户端做自适应，但分区的Replica模型、日志分段存储模型、依赖ZooKeeper或KRaft做元数据协调这些根子上的设计，决定了它的瓶颈在天花板上就已经被框死了。

1.2 Fluss的核心定位：流存储，而不是消息队列

Fluss的设计思路，是做一个专门的流存储层，让上层计算引擎（尤其是Flink）可以直接对它做流式读写，同时让底层数据以低成本的方式落到云存储上。它最开始在阿里内部落地时，瞄准的就是Kafka在超大规模场景下暴露的那些根因性问题，比如分区均衡、副本同步开销、冷数据存储成本、Schema演进。从外部视角看，Fluss有三个非常核心的差异化点：

第一，存算分离与分层存储。Fluss把热数据放在高性能本地或云盘层，把冷数据异步下沉到远端廉价对象存储。这样既保证热数据读取的低延迟，又不需要为大促的“历史尾巴”付出高昂的本地磁盘成本。你可以把它理解成一个冰箱——最常拿的可乐放在冷冻层随取随用，囤的年货放在冷藏室大仓位存着，不挤占冷冻层的空间。

第二，与Flink的无缝集成。Fluss的Connector不是简单封装一个Producer/Consumer，而是深度参与到Flink的checkpoint、exactly-once、动态分区发现这些机制里。上游写入Fluss，下游从Fluss读，中间可以做实时物化、流表关联，整个链路的语义是完整闭环的。

第三，强一致的流式存储语义。Kafka在事务和一致性上做了不少努力，但跨分区、跨topic的原子操作在生态里用起来依然别扭。Fluss在设计上把流存储的一致性做成了内建能力，配合Flink使用时，能明显降低精确一次语义的实现成本。

2. Fluss核心设计拆解：它到底做对了什么

2.1 存储架构：LSM思想与分层存储的结合

Fluss的存储架构，大致可以分成两层来看。一层是内存和本地热存储，负责接收实时写入请求，提供低延迟的读写；另一层是远端存储（云存储或HDFS），负责承载冷数据和历史数据。这套架构借鉴了LSM-Tree（Log-Structured Merge-Tree）的思想，写入先落到内存表，达到一定阈值后刷盘并异步合并，再根据数据的冷热程度决定何时把Segment下沉到远端。

用LSM的思路做流存储，好处非常直接。写入路径是顺序追加，随机写被转化为顺序写，这在机械盘和云盘上都是性能最友好的方式。而且数据合并的过程可以异步执行，不会阻塞实时写入链路。大促场景下，零点峰值那十几分钟的写入毛刺会被内存层先接住，不会直接压到存储层，系统整体更容易保持平稳。

在文件组织上，Fluss把数据按Table和Bucket（分区）组织，每个Bucket对应一段连续的日志，日志内部又有分段（Segment）的概念。这种做法兼顾了流式读取（按顺序扫Log）和批量读取（按文件扫）两种访问模式。对Flink这种既需要流式消费、又需要做窗口聚合的计算引擎来说，这种双模访问能力非常实用。

2.2 一致性语义：从“至少一次”走向“端到端精确一次”

消息系统的Exactly-Once（精确一次）做起来比想象中难。Producer写消息，Broker存储消息，Consumer消费并更新外部状态，任何一环出现重试、故障恢复，都可能造成重复。传统做法是在消费端做幂等，或者在计算引擎内部通过Checkpoint机制去重，但这些都不是存储层自己能够保证的。

Fluss在这块做了一个很关键的设计：把事务和日志追加绑定在一起。写入方可以开启一个事务，在事务内写入一批消息，提交时消息对下游可见。配合两阶段提交协议和Flink的Checkpoint机制，可以实现端到端的精确一次。也就是说，Flink作业挂掉再恢复后，既不会丢消息，也不会重复处理已经写入下游的消息。

这个能力在大促场景里特别重要。实时特征链路一旦出现数据重复，可能导致推荐结果飘掉、库存扣减不准确，问题定位成本极高。用Fluss后，这些语义层面的脏活累活被系统兜住了，业务不需要在应用层做大量幂等逻辑。

2.3 动态分区分桶与弹性扩缩容

Kafka的分区数在创建topic时基本就定下来了，后期扩分区会涉及数据重分布，处理不当容易造成分区内数据倾斜和消费端Rebalance。Fluss在分桶模型上更灵活，支持在表运行时动态调整分桶数量。配合Flink的Dynamic Bucketing能力，可以在大促前预先扩容必要的分区，并在大促结束后缩容，整个过程不需要停写。

双11的流量模型里，不同业务线的峰值时间点是错开的。比如0点到0点10分是秒杀峰值，1点到2点是聚划算频道峰值，上午10点反而可能是某个品类的浏览峰值。静态的分区模型要么在每个时段都按最高峰值预留资源，浪费严重；要么按平均值分配，峰值时段出现热点。Fluss的弹性分桶思路，能够更平滑地适配这种随时间变化的流量模型。

2.4 与Kafka协议兼容的“柔性迁移”路径

考虑到存量系统里大量业务已经基于Kafka Client开发，Fluss做了一个非常务实的决定：兼容Kafka协议。这意味着，原本用Kafka Producer和Consumer写的代码，无需改动或只需少量改动，就可以把数据链路切到Fluss上。这对大规模落地来说价值巨大，因为你可以先做一个透明的协议层替换，跑一段时间观察稳定性，再逐步把业务逻辑往Flink+Fluss的深度集成方向上迁移，无需走“推倒重来”的路线。

3. 双11场景下的落地实操与关键步骤

3.1 容量规划：先算清楚这几个数字

我见过不少团队在大促前拍脑袋定分区数，结果不是资源浪费就是分区热点。做容量规划，其实可以套用一个相对朴素的公式：

峰值写入流量 = 单分区写入吞吐 × 分区数

假设你要支撑的峰值消息量是每秒5000万条，平均单条消息大小是1KB，那么写入带宽就是50GB/s。如果单分区稳定写入吞吐能做到5MB/s（这个数字要压测得出，不同机型、不同副本策略差异很大），那么理论需要的分区数就是50GB/s ÷ 5MB/s = 10000个。当然，这只是理论下限。实际还要留出至少30%的余量给消费端追赶、流量毛刺和故障恢复时的Buffer，所以建议起步规划为13000到15000个分区。

这里有一个经验值：大促流量评估可以参考历史上最大大促的峰值 * 预估增长系数 * 安全系数。大促增长系数结合业务目标定，一般在1.3到1.8之间；安全系数建议不低于1.2。宁可多规划一点，也不要让系统在峰值到来前就出现分区热点。

3.2 上下游链路改造与接入Fluss

在阿里内部的大规模实践里，业务链路接入Fluss并不需要从零开始。整体步骤可以这样拆：

1. 先明确哪些链路必须走Fluss。优先选择实时特征、实时数仓、近实时湖仓这类“写入多、读取频、回溯需求强”的场景。普通业务消息通知、日志采集链路暂时不迁移。
2. 创建流表并设置分桶。这一步需要根据消息量和分区估算结果，提前把桶数、副本数、存储策略配置好。Fluss的使用方式上，表和Kafka的Topic类似，但多了一些存储策略类参数。
3. 替换客户端。如果你的服务用的是Kafka Client，且不需要用Fluss特有的流表关联能力，可以直接切到兼容协议。随后把关键作业逐步迁移到Flink + Fluss Connector。
4. 配置Flink作业的Checkpoint与端到端精确一次。建议Checkpoint间隔设置合理，不要过于频繁，否则大促时状态后端压力会很大。一般建议大促时适当放宽Checkpoint间隔，比如默认3分钟，大促调到5分钟，减少状态备份对主链路的影响。
5. 配置数据保留策略。实时特征数据保留12到24小时，近实时湖仓数据保留3到7天，历史数据自动下沉到远端对象存储，降低热存储成本。

3.3 压测与演练：大促前的必做项目

大促前不做一次完整链路的压测，基本等于裸奔。压测不能只测单个组件，一定要做“端到端压测”：业务应用写入Fluss，Flink作业消费并计算，结果写入下游，全链路一起加压。

压测过程中要重点盯三类指标：一是写入延迟曲线，看P99是否在峰值时出现拐点；二是消费端Lag曲线，看Flink作业在峰值压力下是否能保持拉平，一旦Lag持续上涨，说明消费端计算能力不足或资源不够；三是存储层IO和网络IO，看是否打满网卡或磁盘。

大促演练时，有一个容易被忽略的环节：故障演练。比如模拟一个Broker节点挂掉、模拟网络分区、模拟某个分桶的Leader切换。很多问题在正常情况下测不出来，只有故障注入时才能暴露。比如Leader切换后消费端能否快速感知并切换，Checkpoint能否在故障恢复后自动续跑，这些都要提前验证。

3.4 监控体系搭建与阈值设定

实时链路最怕的是“问题发生后几分钟才有人发现”。Fluss相关的监控，建议至少覆盖以下五块：

告警阈值不要拍脑袋，最好结合一周的基线数据来定。把历史数据的P99和P999算出来，在基线基础上乘以1.5到2倍作为告警线，避免噪音告警。

4. 双11保障过程中遇到的典型问题与排查实录

4.1 分区热点问题：五个桶打满，剩余九千个桶在睡觉

第一次用Fluss做双11压测时，我们遇到过非常典型的分区热点问题。表现为：写入TPS没有打满，但延迟P99已经飙到300ms以上；集群总体吞吐远没到上限，但某几个分桶所在节点的CPU已经打满。查下来发现，上游业务在写入时指定了分区Key，而业务Key的分布非常倾斜——几个头部商家占了80%的流量。

排查思路：先用Fluss提供的监控面板按Bucket维度查看写入分布，确认热点发生在哪些Bucket；再结合写入Key的分布情况和业务同学确认是否是Key设计不合理；修复方案有两种，一种是改造Key设计，加盐或改用消息自带ID；另一种是将该表的分桶数加大，并开启Fluss的动态分桶重组，让数据在分桶间更均衡。

这里要特别说一句：大促前改造Key设计，风险不低，因为会扯出上游一堆逻辑改动。比较稳的路径是，在创建表的时候就把分桶数规划得大一些，让单桶承载的压力不过高，同时把动态分桶调成“自动模式”，让系统自己在后台做平衡。

4.2 消费端拉平Lag很慢：Flink作业的并行度不是越大越好

另一个高频问题是消费端Lag迟迟拉不平。大促期间某个实时特征作业的Lag从几百万涨到几千万，加了并行度之后反而更慢了。

排查后发现，问题不在Fluss本身，而在Flink作业的状态恢复。我们这个作业是一个带有10分钟滚动窗口的聚合任务，状态比较大，每次调整并行度后重启，都需要从最近一个Checkpoint恢复状态。并行度调大后，状态恢复时网络和磁盘IO开销成倍上涨，反而拖慢了启动速度。而且大促期间频繁调并行度，会导致作业频繁进入恢复状态，拖得越久Lag越高。

后来我们总结了一套经验：大促前就按峰值流量把Flink作业的并行度定好，大促期间非必要不动并行度；如果是状态较小的作业，可以考虑从最早位点直接重跑，反而比重启恢复更快；如果确实需要调整并行度，也要控制调整频率，避免连续调整导致作业一直处于“恢复中”的状态。

4.3 冷读延迟问题：追溯历史数据时到底卡在哪里

Fluss的分层存储把冷数据下沉到远端对象存储后，如果下游需要回溯很久之前的数据（比如大促后做数据核对），冷读延迟就会比读热数据高不少。这个问题不是缺陷，而是分层存储的固有特性。

实操中，我们一般会在数据核对任务开始前，先用“数据预热”操作把需要回溯的Segment从远端提前拉回到本地热存储。同时把这类回放任务的优先级调低，避免它跟实时任务抢资源。如果回放的窗口跨度过大，还可以按小时切分成多个小任务并行执行，控制单个任务的Segment加载量，降低对实时链路的影响。

4.4 常见问题速查表

5. 最后的几条实操感受

做双11保障这几年，我最大的感受是：没有银弹，但选对底座能让问题少一半。Fluss这套东西，在流存储这个位置上是想过大促场景才设计出来的——弹性分桶、分层存储、与Flink的深度集成，这些不是炫技，是针对最痛的那些问题实打实的解法。

如果你想在真实业务里试Fluss，我建议不要一上来就追求大规模改造，可以从一个非核心的实时链路开始，先跑通协议兼容路径，再逐步叠加流表关联、端到端精确一次这类高级特性。把压测和故障演练前置，把监控阈值调准，大促前把这些基本功做到位，比临时抱佛脚调参数管用得多。

还有一个细节我印象很深：无论底层系统多稳，大促前一定要把回滚方案准备好。流存储的切换不像改个配置那么轻量，一旦新链路出现严重问题，你要有快速切回旧链路的能力，否则再好的架构也顶不住“只能进不能退”的压力。这点，希望每个做大促保障的朋友都放在心上。