版权声明：本文为博主原创文章，转载请留下脚印，技术交流评论。 https://blog.csdn.net/ZLZ2017/article/details/86411277
上一篇Flink的状态管理中，我们提到了Operator state，本文介绍的广播状态（Broadcast State）是 Apache Flink 中支持的第三种类型的operator state。Broadcast State使得 Flink 用户能够以容错、一致、可扩缩容地将来自广播的低吞吐的事件流数据存储下来，被广播到某个 operator 的所有并发实例中，然后与另一条流数据连接进行计算。
广播状态与其他 operator state 之间有三个主要区别：
1、Map 的格式
2、有一条广播的输入流
3、operator 可以有多个不同名字的广播状态
广播状态注意事项
Apache Flink 官方文档提供了广播状态的功能以及有关 API 的详细指南。在使用广播状态时要记住以下4个重要事项：
- 使用广播状态，operator task 之间不会相互通信
这也是为什么(Keyed)-BroadcastProcessFunction上只有广播的一边可以修改广播状态的内容。用户必须保证所有 operator 并发实例上对广播状态的修改行为都是一致的。或者说，如果不同的并发实例拥有不同的广播状态内容，将导致不一致的结果。 - 广播状态中事件的顺序在各个并发实例中可能不尽相同。
虽然广播流的元素保证了将所有元素（最终）都发给下游所有的并发实例，但是元素的到达的顺序可能在并发实例之间并不相同。因此，对广播状态的修改不能依赖于输入数据的顺序。 - 所有 operator task 都会快照下他们的广播状态
在 checkpoint 时，所有的 task 都会 checkpoint 下它们的广播状态，并不仅仅是其中一个，即使所有 task 在广播状态中存储的元素是一模一样的。这是一个设计倾向，为了避免在恢复期间从单个文件读取而造成热点。然而，随着并发度的增加，checkpoint 的大小也会随之增加，这里会存在一个并发因子p的权衡。Flink保证了在恢复/扩缩容时不会出现重复数据和少数据。在以相同或更小并行度恢复时，每个 task 会读取其对应的检查点状态。在已更大并行度恢复时，每个 task 读取自己的状态，剩余的 task （p_newp_old）会以循环方式（round-robin）读取检查点的状态。 - RocksDB 状态后端目前还不支持广播状态
广播状态目前在运行时保存在内存中。因为当前，RocksDB状态后端还不适用于operator state。Flink 用户应该相应地为其应用程序配置足够的内存。
广播状态模式的应用
一般来说广播状态的主要应用场景如下：
1、动态规则：动态规则是一条事件流，要求吞吐量不能太高。例如，当一个报警规则时触发报警信息等。我们将这个规则广播到计算的算子的所有并发实例中。
2、数据丰富：例如，将用户的详细信息作业广播状态进行广播，对包含用户ID的交易数据流进行数据丰富。