实时流计算这条线上待久了，会摸出一个规律：凡是作业跑着跑着开始抖、重启之后数字对不上、延迟曲线无缘无故抬头，八成最后都会指到同一个地方——状态管理。前面算子写得再漂亮，状态这一层没设计好，整条链路就是建在沙子上。我前后经手过几个实时链路，从最早的纯内存无状态写法，到后来被逼着上分布式状态存储、做检查点、做状态迁移，踩的坑基本都集中在这块。这篇文章想聊的就是这件事：大数据实时流计算的状态管理，重点把两个经常被混为一谈的概念拆开——流数据状态和流信息状态。
前者是业务数据在计算过程中留下的中间结果，后者是描述这条流"是什么、走到哪、怎么跑"的上下文。很多团队出问题，就是把这两类东西一股脑塞进同一个状态容器里，结果业务规则一变更，历史状态全废；或者元信息没做持久化，作业一重启水位线回退，迟到数据把已经算好的结果又冲了一遍。不管你是正在做实时链路落地、被状态膨胀和恢复慢折磨过的老手，还是刚接手流作业、还没搞清状态后端选型逻辑的新人，这套拆法都用得上。下面从设计思路开始，一层一层往下剥。
1. 两类状态的分野：先想清楚你在存什么
1.1 "无状态计算"的假象
刚接触流计算的人容易有个错觉：我写的是 map、filter、简单字段清洗，没有聚合没有 join，所以我的作业是无状态的。这个判断在代码层面成立，在系统层面基本不成立。哪怕只是做实时清洗，你也得回答"这条消息处理到哪了"这个问题，而位点信息本身就是状态。
更常见的是把状态偷偷外包出去。比如实时去重要求同一个用户五分钟内只放行一次，很多人的第一反应是查一次远端缓存，查到了就丢弃，查不到就写入并放行。代码看起来干净，实际上是把状态从引擎内部搬到了外部存储，每一次处理都多了一次网络往返。平时流量小看不出来，大促一到，远端存储的连接池先崩，接着是超时重试把整个链路拖垮。
真正的无状态作业只存在于教科书里。业务一旦沾上窗口、去重、关联、排序、模式匹配，状态就是刚需。所以问题不是"要不要状态"，而是"状态往哪儿放、放多久、怎么保证它和计算结果一致"。
1.2 一条判定标准，把状态切成两半
我在实际项目里用的判定标准很简单：这份状态是不是由业务数据本身驱动的。
如果它随每一条输入记录变化、直接参与结果计算、丢掉之后历史结果就复现不出来，那就是流数据状态。典型代表是窗口里的累加器、去重的 key 集合、双流 join 缓存的另一侧数据、TopN 维护的堆。
如果它描述的是"作业怎么跑、流走到哪、规则长什么样"，不直接作为业务字段输出，但决定了计算结果对不对，那就是流信息状态。典型代表是水位线、源端消费位点、检查点元信息、广播下发的配置规则、维表版本号、算子拓扑与并行度。
两者的差别不在于存在哪个存储里，而在于生命周期和变更频率完全不同。数据状态跟着业务数据量涨，量级可能是 GB 到 TB；信息状态通常只有 KB 到 MB 级别，但变更极其频繁，而且一旦不一致，后果比数据状态丢失更严重——数据状态丢了顶多是重算，信息状态错位了是算错。
| 维度 | 流数据状态 | 流信息状态 |
|---|---|---|
| 驱动来源 | 业务记录逐条驱动 | 运行时上下文、配置、进度驱动 |
| 数据量级 | 随 key 数量线性增长，GB 至 TB | 通常在 KB 至 MB 量级 |
| 变更频率 | 每条记录都可能变更 | 按检查点周期或配置下发时变更 |
| 丢失后果 | 结果可重算，代价是回追历史 | 结果错乱，往往难以自动修复 |
| 典型载体 | 值状态、列表状态、映射状态 | 广播状态、位点元数据、版本号 |
| 治理重点 | 容量、倾斜、TTL、序列化效率 | 一致性、时序、版本兼容 |
这张表建议贴在设计方案第一页。后面所有的选型和参数调整，基本都能对应回这两列。
2. 流数据状态：把计算过程钉在存储上
2.1 形态与算子的对应关系
流数据状态不是一种东西，它按访问模式分成几类，选错了性能差一个数量级。我一般这么对应：
- 单值累加，比如统计某个商户当日交易笔数，用值状态，读写都是 O(1)。
- 需要遍历或者按序访问，比如维护最近 N 条行为做风控打分，用列表状态，注意它只适合小规模，别拿它当队列使。
- 按 key 随机读写，比如用户画像标签集合、去重集合，用映射状态，底层是哈希结构，注意单 key 内部元素过多会形成大 key。
- 只需要聚合结果不要明细，比如求平均、求最大，用聚合状态或归约状态，引擎只存累加器和计数器，能省掉大量序列化开销。
这里有个容易忽略的点：列表状态和映射状态在写入时是全量序列化的。也就是说你往一个已经存了十万条记录的列表状态里追加一条，某些实现下会把十万条重新写一遍。这个坑我在一个做会话轨迹的项目里踩过，单条处理耗时从 2 毫秒涨到 80 毫秒，排查了半天才定位到是列表状态反复全量写。后来改成映射状态按 sessionId 分桶存，问题立刻消失。
2.2 状态后端选型的三个硬指标
状态后端决定了状态存在哪儿、怎么读写、怎么做快照。主流选择就三类：堆内存、嵌入式 LSM 存储、远端存储服务。没有绝对优劣，看你的状态规模和恢复时间要求。
| 后端类型 | 读写性能 | 可支撑状态规模 | 快照方式 | 适用场景 |
|---|---|---|---|---|
| 堆内存 | 最快，纳秒级 | 受 JVM 堆限制，通常几 GB | 全量快照，写入快照文件 | 状态小、对延迟极敏感 |
| 嵌入式 LSM | 微秒级，走本地磁盘 | 可到 TB 级 | 支持增量快照 | 大状态、长窗口、需要低成本恢复 |
| 远端存储服务 | 毫秒级，走网络 | 理论上无上限 | 依赖服务端能力 | 状态极大、多作业共享 |
选型的判断顺序我一般是这样：先估状态规模，超过堆内存的 30% 就直接排除纯内存方案，因为 JVM 还需要留空间给计算和 GC，状态一挤，Full GC 会把延迟尖刺拉到你无法接受的程度。如果状态规模在百 GB 以上，优先考虑支持增量快照的后端，全量快照每次都要把几百 GB 写到远端，检查点周期根本排不开。
提示：不要用"当前状态很小所以选内存"来做长期决策。业务是会长大的，去重集合的 key 数量往往以周为单位翻倍。留出至少三倍的容量冗余，比后期迁移状态要省事得多。
2.3 容量估算：一个能直接抄的算法
状态容量靠拍脑袋是最容易翻车的。我用的公式是：
状态总大小 ≈ 活跃 key 数量 × 单 key 状态序列化后大小 × 放大系数 放大系数 ≈ 1.3（索引与元数据开销）+ 0.2（快照期间的双份占用）举个例子。某实时去重场景，要求统计某类事件当日独立主体数，日均活跃主体约 2000 万，单条状态是主体标识加首次出现时间戳，序列化后约 60 字节。
基础大小 = 2000 万 × 60 B ≈ 1.2 GB 加索引与元数据 = 1.2 GB × 1.3 ≈ 1.56 GB 快照双份冗余 = 1.56 GB × 1.2 ≈ 1.87 GB结论是单个并行度下大约需要 2 GB 状态空间。如果作业并行度设成 8，按 key 均匀分布算，每个子任务约 250 MB，这个量级用堆内存后端完全扛得住，但如果并行度设成 2，每个子任务接近 1 GB，加上计算内存和 GC 压力，就必须换嵌入式 LSM 了。
这里有个隐藏变量：key 的分布从来不是均匀的。真实业务里头部主体可能占据 30% 以上的数据量，所以按平均值算出来的单任务容量要再乘一个 1.5 到 2 的安全系数，否则一定会出现某几个子任务先 OOM、整体反复重启的情况。
2.4 TTL 与清理：不清理的状态就是负债
状态不设过期，等于给自己埋定时炸弹。我见过一个实时会话分析的作业，状态里存了每个会话的完整行为路径，上线三个月状态涨到 1.4 TB，恢复一次要 40 分钟。
清理策略有三层，建议叠着用：
第一层是状态 TTL，按业务语义设置存活时间。比如去重场景设 24 小时，会话场景设 30 分钟无活动即过期。配置 TTL 时要注意清理策略是"只看创建时间"还是"读写都刷新时间"，前者适合固定窗口类场景，后者适合滑动会话类场景，选错了会导致该活的被清掉、该死的清不掉。
第二层是定时器清理。窗口结束、会话超时这些事件本身就是清理信号，在处理逻辑里显式把不需要的状态条目删掉，比等 TTL 后台扫描更及时，也更可控。
第三层是按时间分区存储。如果业务允许按天或按小时切分状态，把日期编进 key 前缀，配合定期整体清理，能把状态规模控制在常量级而不是无限增长。
注意：TTL 不是删除的即时保证。多数实现是懒删除加周期扫描，配置了 TTL 之后状态文件不会立刻变小，别拿磁盘占用曲线去判断 TTL 生效没生效，看的是活跃 key 数量。
3. 流信息状态：被忽视的那一半
3.1 信息状态到底包含什么
很多人听到"状态管理"，脑子里只有聚合中间结果。真正的信息状态清单要长得多，我按用途分成四组：
进度类：源端消费位点、水位线、处理时间与事件时间的映射关系。这类状态决定了作业重启后从哪儿接着算。
配置类：广播下发的业务规则、黑白名单、阈值参数、维表快照。这类状态决定了单条记录怎么被处理。
结构类：算子唯一标识、拓扑结构、并行度、序列化版本号。这类状态决定了作业能不能从旧快照恢复。
统计类：全局计数器、脏数据计数、限流令牌、作业级开关。这类状态决定了运行时的自适应策略。
这四组里，前两组是必须持久化的，第三组是恢复的前提条件，第四组看情况，但至少要保证重启后不会因为计数器归零导致限流失效、把下游打穿。
3.2 为什么它比数据状态更容易出事
数据状态出问题，表现通常是慢、是内存涨，你有一堆监控指标可以看。信息状态出问题，表现往往是"结果就是不对"，而且很难复现。
我遇到最典型的一次是水位线回退。作业因为一次配置变更重启，从检查点恢复后，源端分区的水位线没有跟着恢复，几个空闲分区的水位线被重置成初始值，导致整个作业的水位线被拖回到几分钟前。结果是已经触发过的窗口又被触发了一次，下游的报表数字直接翻倍。这个问题在监控上完全看不出来——吞吐正常、延迟正常、没有报错，只有对账的时候才发现。
另一个高频问题是广播配置的版本错位。规则从管理端下发，经过消息中间件到广播流，再更新到广播状态。如果作业在"配置已更新但广播状态还没写入检查点"这个时间窗口里重启，恢复后用的就是旧规则，而下游的埋点已经标记了新规则版本。这种不一致会持续到下一次配置更新才被发现。
还有序列化版本演进。给状态里的实体类加了一个字段，编译没问题，跑起来从旧快照恢复时反序列化直接抛异常。这类问题在状态里存的是复杂对象而不是基本类型时特别容易发生。
3.3 广播状态：规则热更新的正确姿势
动态规则是信息状态最典型的应用。我的实现套路是"全量快照 + 版本号 + 灰度生效"。
全量快照指的是每次规则变更都下发完整规则集合，而不是单条增删改。看起来浪费带宽，实际上省掉了顺序问题——增量更新最怕乱序，旧消息后到会把新规则覆盖掉，全量下发天然幂等。
版本号的作用是让算子能判断"我现在用的规则是不是最新"。广播状态的每个条目带一个单调递增的版本号，处理数据时如果发现本地快照版本低于某个阈值，可以选择短暂阻塞等待同步，或者把这批数据打上待重算标记，而不是用旧规则算完就完事。
灰度生效则是应对规则本身有问题的场景。新规则带上生效时间和流量比例，算子按主体标识做哈希决定用新规则还是旧规则，出问题时改一下比例就能回滚，不用整个作业重启。
// 广播状态中存放的规则快照结构，示例 public class RuleSnapshot implements Serializable { private long version; // 单调递增版本号 private long effectiveAt; // 生效时间戳 private int rolloutPercent; // 灰度比例 0-100 private Map<String, Rule> rules; // 全量规则 public boolean hitNewRule(String subjectId) { int bucket = Math.floorMod(subjectId.hashCode(), 100); return bucket < rolloutPercent; } }这段代码重点在hitNewRule这个方法。灰度判断放在状态内部而不是外部，是为了保证同一个主体在规则切换过程中不会一会儿用新规则一会儿用旧规则。哈希取模计算成本几乎为零，但它让灰度具备了确定性。
4. 实操：把两类状态装进同一个作业
4.1 骨架与状态定义
下面是一个完整可参考的作业骨架，业务场景是实时风控：统计主体近一小时的行为次数，同时用广播下发的规则做打分，两类状态都涉及。
public class RiskScoreJob { // 数据状态：主体近一小时计数 private ValueState<CountWithWindow> countState; // 信息状态：规则快照 private BroadcastState<String, RuleSnapshot> ruleState; // 信息状态：已处理到的水位线，用于迟到数据判定 private ValueState<Long> watermarkState; public void open(Configuration conf) { ValueStateDescriptor<CountWithWindow> countDesc = new ValueStateDescriptor<>("count-state", CountWithWindow.class); // 数据状态设 2 小时 TTL，覆盖窗口滑动余量 countDesc.enableTimeToLive( StateTtlConfig.newBuilder(Duration.ofHours(2)) .setUpdateType(StateTtlConfig.UpdateType.OnCreateAndWrite) .setStateVisibility(StateTtlConfig.StateVisibility.NeverReturnExpired) .build()); countState = getRuntimeContext().getState(countDesc); ruleState = getRuntimeContext().getBroadcastState( new MapStateDescriptor<>("rule-state", String.class, RuleSnapshot.class)); watermarkState = getRuntimeContext().getState( new ValueStateDescriptor<>("watermark-state", Long.class)); } }这里有三个设计取舍值得说明。
第一个是CountWithWindow这个结构，我把窗口起点和计数打包成一个对象，而不是只存一个整数。原因是纯计数在窗口切换时无法判断当前计数属于哪个时间窗，重启后从检查点恢复，如果水位线有微妙偏差，就可能把上一小时的计数继续累加到下一个窗口上。多存一个窗口起点字段，序列化开销增加不到 20 字节，换来的是窗口边界的强一致。
第二个是 TTL 的更新时间类型选了OnCreateAndWrite。风控计数是按固定窗口统计的，窗口内部每次写入都刷新时间没关系，但读操作不应该延长存活期，否则一个被反复查询但不写入的 key 会永远不过期。
第三个是水位线单独做成了值状态。它理论上可以从框架的运行时上下文拿到，但独立持久化一份，在恢复后做迟到数据判定时更可靠，也能在日志里留下清晰的水位线轨迹方便排查。
4.2 检查点参数：别用默认值
检查点是数据状态和信息状态的共同快照点，参数调不好，前面所有设计都白搭。我常用的一组参数如下，具体值要按状态规模调整：
| 参数 | 建议值 | 说明 |
|---|---|---|
| 检查点间隔 | 60 秒至 3 分钟 | 间隔越短恢复越快，但对正常处理干扰越大 |
| 检查点超时 | 间隔的 10 倍 | 低于这个值容易因偶发慢节点误判失败 |
| 两次检查点最小间隔 | 不小于间隔的 50% | 防止前一次没完就排队，造成堆积 |
| 并发检查点数 | 1 | 大状态场景设 1，避免快照 IO 抢占处理带宽 |
| 失败容忍次数 | 2 至 3 次 | 允许偶发失败自动重试，避免频繁全量重启 |
| 非对齐检查点 | 状态大于百 GB 时开启 | 跳过屏障对齐，牺牲部分快照体积换速度 |
关于非对齐检查点，我的经验是：如果检查点超时的原因是对齐等待，也就是说总有那么一两个分区数据来得慢，屏障卡住导致反压，那开启非对齐是立竿见影的。代价是快照里会包含处理中的数据，快照体积变大，恢复时重放的数据变多。如果状态本身不大，不值得开，反而增加复杂度。
还有一个常被忽略的参数是检查点存储路径的并发写入能力。状态几十 GB 的时候，快照写入是串行 IO，如果存储端限流，检查点会一直超时。我一般会把检查点目录和作业日志目录分开挂载，避免日志刷盘影响快照写入。
4.3 状态版本演进与迁移
业务在变，状态结构必然要变。这一块如果没提前设计，等到需要加字段的时候就是一次事故。
第一条铁律是给每个有状态的算子固定唯一标识。这个标识一旦上线就不能改，它是快照里状态的寻址 key。我见过有团队为了"代码整洁"重命名了算子，结果从快照恢复时状态全部对不上，只能丢弃状态从零开始，历史数据全部重算。
第二条是序列化兼容策略。状态里存的对象，新增字段要有默认值，删除字段不要立刻删而是标记废弃保留至少两个版本，字段类型不要改。如果用的是通用序列化框架，建议开启 schema 演进支持，并且写一个反序列化兼容性测试用例，每次改实体类都跑一遍，从旧版本快照样本恢复验证。
第三条是重大变更走双写过渡。比如要把状态结构从"按主体维度存计数"改成"按主体加业务线二维维度存计数"，直接切换会导致新旧 key 完全对不上。我的做法是让新逻辑同时写新结构和旧结构，旧结构保留一个版本周期只写不读，确认新逻辑稳定后再把旧结构下线。这一个周期的存储成本，远比一次全量数据重算的风险低。
4.4 灰度发布与回滚
带状态的作业发布，跟无状态服务完全不是一个思路。无状态服务滚动更新即可，有状态作业要考虑的是"新版本能不能读到旧版本的状态"。
我常用的流程是：先用新版本从旧版本的快照启动一个影子作业，消费同一份数据流但不对外输出，跑两小时对比影子作业和线上作业的结果差异。差异率在可接受范围内，再把线上作业停掉、从最新快照用新版本启动。这个过程中线上会有分钟级的延迟，如果业务不能接受，就得上双作业并行加结果比对，通过切流量的方式过渡。
回滚同理，必须保证新版本写入的状态能被旧版本读取。这就是为什么前面强调删除字段要保留两个版本——不是因为舍不得，是因为回滚时需要。
5. 排障实录：状态相关的五类高频故障
5.1 检查点持续超时
现象：检查点成功率从 99% 掉到 60% 以下，作业本身还在跑，但恢复能力实际上已经丧失。
排查顺序我一般是这么走的：先看超时时间点是不是集中在反压期间，如果是，问题在处理能力不足而不是检查点本身；再看各子任务的快照大小是否严重不均，如果某个子任务快照是别人的十倍，那是数据倾斜；最后看快照写入耗时，如果写入阶段占了总耗时八成以上，说明存储端带宽或限流有问题。
对应的处理：反压导致的，加并行度或者优化算子逻辑；倾斜导致的，对 key 做加盐打散；存储带宽导致的，换存储路径或者开启增量快照。
心得：检查点超时很少是单一原因。我遇到过一次是倾斜和存储限流叠加，单独解决任一个都只能把成功率从 60% 拉到 75%，两个一起改才回到 99%。
5.2 状态膨胀导致恢复以小时计
现象：作业重启后，从快照恢复到正常处理要花一个小时以上，业务方无法接受。
先定位膨胀来源。用状态大小按子任务的分布图看，如果整体均匀增长，说明是业务量真实增长，需要做容量规划；如果集中在少数几个子任务，是热点 key；如果是历史累积而非活跃数据，说明 TTL 或者清理逻辑有问题。
我处理过的一个案例是去重集合无界增长。业务方的需求是"全局去重"，听起来必须存全量，实际上业务语义是"同一主体当日不重复"，只需要保留当天数据。把 key 加上日期前缀、按天切换命名空间后，状态规模从 800 GB 降到 90 GB，恢复时间从 50 分钟降到 4 分钟。
5.3 数据倾斜与热点 key
现象：整体并行度 16，但总有 2 到 3 个子任务 CPU 打满，其余空闲。
倾斜的根治要靠 key 设计。如果业务 key 天然不均匀，比如按商户维度，头部商户数据量是长尾的几百倍，那就得在 key 里加随机后缀，把单 key 拆成 N 份分别聚合，下游再做一次合并。这个方案的代价是多一次聚合，但换来的是并行度真正生效。
另一种情况是空 key 倾斜。某些记录的关键字段为空，全部分到同一个子任务。这种要在入口就过滤或者打上随机值，不要让空值进入状态。
5.4 重启后指标对不上
现象：作业重启后，下游报表数字出现重复或者缺失，但对账口径是一样的。
这类问题九成出在信息状态上。核对三个点：水位线是否回退导致窗口重复触发；源端位点是否精确到分区级别而不是全局级别；广播配置版本在恢复时是否和实际生效版本一致。
还有一个隐蔽的原因：输出端的幂等性。状态恢复做到精确一次，但下游写入如果没有按主键覆盖而是追加，重复数据照样会进去。这种情况要在输出端加去重键，或者用两阶段提交保证。
5.5 问题速查表
| 现象 | 高概率原因 | 首选动作 |
|---|---|---|
| 检查点超时 | 反压、倾斜、存储限流 | 看子任务快照分布，确认瓶颈在计算还是 IO |
| 恢复耗时长 | 状态膨胀、全量快照 | 查 TTL 与清理逻辑，评估增量快照 |
| 单任务 CPU 打满 | 热点 key、空 key | 加盐打散，入口过滤空值 |
| 结果重复或缺失 | 水位线回退、位点粒度、下游非幂等 | 核对三类信息状态，检查输出端 |
| 反序列化异常 | 实体类字段变更 | 补兼容测试，旧快照样本回归 |
| 广播规则未生效 | 版本错位、下发乱序 | 改全量下发加版本号 |
6. 几条踩出来的经验
第一，状态设计要从"能不能重算"倒推。如果一个状态丢了，能不能从源数据重新算出来？如果能，恢复策略可以放宽，接受重算；如果不能，那它就必须进检查点，而且要保证精确一次。这个判断比任何参数调优都重要。
第二，信息状态要单独做可观测性。数据状态有大小、有 key 数量，天然好监控；信息状态往往是几个数字躺在内存里，出问题才知道重要。我现在会给水位线、规则版本、源端位点各打一个指标出来，曲线一异常立刻能发现。
第三，不要在一个作业里塞太多职责。有的团队为了省资源，把清洗、聚合、去重、打分全塞进一个作业，状态混在一起，任何一个逻辑变更都要全量恢复。拆成两三个作业，每个的状态边界清晰，出问题影响面也小。
最后分享一个我常用的自检方法：每次作业上线前，强制从检查点恢复一次，记录恢复耗时和恢复后的前一百条输出，跟正常启动对比。这个动作花不了十分钟，但能把绝大多数状态相关的问题在线上暴露之前拦下来。踩过几次恢复失败的坑之后，这条已经成了我们这边的固定流程。
