Flink Broadcast State 怎么用？有哪些注意点？
面试怎么回答
Broadcast State 适合把低频变化的小规模规则流复制到所有并行实例，再与 Keyed 业务流 connect。广播侧负责更新 MapState，业务侧只读并按规则处理事件。我会重点控制规则规模、保证更新逻辑确定且幂等，并设计删除、版本和过期机制。因为每个并行实例都保存并 Checkpoint 一份状态，所以不能把大维表直接当广播规则使用。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
实时作业里经常有一种需求：业务规则会动态变化，而且每个并行实例都必须拿到同一份规则。
规则放外部数据库会频繁查询，放普通 Keyed State 又无法保证所有 Key 都能看到。
这就引出了一个更实用的问题：Flink Broadcast State 应该怎么用？
Broadcast State 的核心不是“广播一条消息”，而是把低频变化的规则流复制到所有下游并行实例，再与高吞吐业务流连接处理。
典型架构：规则流 + 业务流
常见步骤是：
- 为规则定义
MapStateDescriptor； - 将规则流调用
broadcast()； - 业务流按业务 Key 执行
keyBy()； - 两条流
connect()； - 使用
KeyedBroadcastProcessFunction处理。
在广播侧的 processBroadcastElement 中，可以更新 Broadcast State；在业务侧的 processElement 中，只能读取广播状态并处理当前业务事件。
适合哪些场景？
- 动态风控规则
- 实时路由配置
- 指标阈值下发
- 小规模黑白名单
- 需要所有并行实例共享的模型版本信息
它适合“小而变化不频繁”的控制数据，不适合把超大维表全部复制到每个并行实例。
四个注意点
第一：广播状态保存在每个并行实例
规则有 1GB、并行度 100，并不意味着集群只保存 1GB。Broadcast State 会被每个实例持有和 Checkpoint，规模必须受控。
第二：更新逻辑必须确定性
不同并行实例接收广播事件的顺序可能不同，因此状态更新不能依赖不稳定顺序。相同输入最终必须得到相同状态。
第三：业务侧只能只读
普通业务事件不能随意修改 Broadcast State，否则各并行实例很容易产生不一致。
第四：规则删除和版本也要设计
不能只处理新增规则。还要定义更新、删除、过期、版本回退和重复下发的幂等语义。
一个典型反例
比如把完整商品维表广播到 200 个并行实例，希望消除外部查询。
开始数据量不大时运行正常，随着维表增长，每个 TaskManager 都保存一份副本，状态和 Checkpoint 同步膨胀，恢复速度越来越慢。
更合理的做法是只广播真正小而必要的规则数据；大维表使用异步 IO、Lookup Join 或其他外部存储方案。
广播解决的是全局可见性，不是无限容量。