在 Apache Flink 1.5.0 中引入了广播状态（Broadcast State）。本文将描述什么是广播状态模式，广播状态与其他的 Operator State 有什么区别，最后说明一下在 Flink 中使用该功能时需要考虑的一些重要注意事项。
1. 什么是广播状态模式
广播状态模式指的是将低吞吐量的事件流（例如，包含一组规则）广播到某个算子所有并发实例上的一种流应用程序，然后与来自另一条事件流的原始数据进行计算。广播状态模式的一些典型应用案例如下：
- 动态规则：假如我们有这样一条规则，当交易值超过100万美元时需要发警报，并将这一规则广播到算子所有并发实例上。
- 数据丰富：对只包含用户ID的交易数据流进行数据丰富，可以将广播数据与用户ID进行关联。
为了实现这样的应用，广播状态是关键组件，我们将在下文详细描述。
2. 什么是广播状态？
广播状态是 Flink 中支持的第三种类型的 Operator State。广播状态使得 Flink 用户能够以容错、可扩展地将来自广播的低吞吐的事件流数据存储下来。来自另一条数据流的事件可以流经同一算子的各个并发实例，并与广播状态中的数据一起处理。有关其他类型的状态以及如何使用它们的更多信息，可以查阅 Flink 文档。
广播状态与其他 Operator State 之间有三个主要区别。不同于其余类型的 Operator State，广播状态：
- Map 的格式
- 有一条广播的输入流
- 算子可以有多个不同名字的广播状态
广播状态怎么使用可以查看博文Flink 广播状态实战指南。
3. 重要注意事项
对于急切想要使用广播状态的 Flink 用户，Flink 官方文档提供了有关 API 的详细指南，以及在应用程序中如何使用该功能。在使用广播状态时要记住以下4个重要事项：
3.1 使用广播状态算子任务间不会相互通信
这也是为什么 (Keyed)-BroadcastProcessFunction 只有广播端可以修改广播状态内容的原因。用户必须保证对于到达的每个元素，算子所有并发任务必须以相同的方式修改广播状态内容（保证一致性）。或者说，如果不同的并发任务拥有不同的广播状态内容，将导致不一致结果。
3.2 广播状态中事件顺序在不同任务上不尽相同
尽管广播流元素保证所有元素（最终）可以到达下游所有任务，但是元素到达每个任务的顺序可能会不同。因此，对广播状态的修改不能依赖于输入数据的顺序。
3.3 所有算子任务都会快照下广播状态
在 checkpoint 时，所有任务都会快照他们的广播状态，并不仅仅是其中的一个，即使所有任务在广播状态中存储的元素是一样的。这样做的目的是为了避免在恢复期间从单个文件读取而造成热点。但是，我们还会通过权衡因子 p (=并发度)对增加的快照状态大小进行权衡（随着并发度的增加，快照的大小也会随之增加）。Flink 保证了在恢复/扩展时不会出现重复数据和丢失数据。在以相同或更小并行度恢复时，每个任务会读取其对应的检查点状态。在扩大并发度恢复时，每个任务优先读取自己的状态，剩下的任务（p_new-p_old）以循环方式读取先前任务检查点的状态。
3.4 RocksDB状态后端目前还不支持广播状态
广播状态在运行时保存在内存中。因为当前(博文发表事件为2018.9)，RocksDB 状态后端还不适用于 Operator State。Flink 用户应该相应地为其应用程序配置足够的内存。
欢迎关注我的公众号和博客：
