apache-flink - 并行度大于 1 的 Flink 广播状态
问题描述
让我说一下，我是 Flink 的初学者，并试图尽可能地抓住概念。
可以说，我有一个带有 10 个任务管理器的 flink 集群。我有一个在每个上面运行的 flink 作业。该作业也使用广播状态。这个广播状态是通过每 10 分钟读取 5 个 S3 文件，做一些处理，创建int to list of strings广播的 map。
问题：文件读取发生在哪里，是在 JobManager 读取和处理文件并将处理后的内容发送给任务管理器。
或者
是负责所有阅读和处理的任务管理器吗？如果是这种情况，那么 flink 如何确保如果一个任务管理器无法从 S3 读取，则所有任务管理器的广播状态都是相同的。
编辑
所以任务管理器读取广播流并将其广播到下游任务。
例如。假设有一个需要广播的 5 个分区的 Kafka 流。还有一个并行度为 5 的下游运算符。
- 分区 1 消费者任务，从流中读取元素并将其设置为广播状态。一旦设置好，状态就会广播到所有下游操作员 5 任务。
- 分区 2 消费者任务，从流中读取元素并将其设置为广播状态。
问题：此时，当我们从分区 2 元素设置广播状态时，我们是否需要确保不覆盖分区 1 中的元素，或者 flink 自己管理这一点。
或者
另外，我们如何确定在分区 2 消耗了一个元素并设置广播状态时，分区 1 的广播状态已达到分区 2 下游操作员任务。
解决方案
文件读取发生在哪里？
任务管理器。JobManager 只负责管理调度和故障转移等任务。
如何将处理后的内容发送给任务管理器？
您可以简单地将广播状态过程想象为向所有下游任务发送相同的消息，而不是发送给特定的任务。
如果任务管理器无法从 S3 读取，flink 如何处理？
如果源任务无法从 S3 读取，我相信会有重启（可能是完全重启，也可能是部分重启），检查点机制会确保状态的一致性。
所有任务管理器的广播状态都是相同的。
实际上，所有任务的广播状态并不完全相同。原因是在网络传输过程中，不能保证事件以相同的顺序传递给任务。