Flink BroadcastProcessFunction与CoProcessFunction的区别及选型场景

两者虽然都能实现双流连接，但从底层机制到适用边界的差异非常明确：

• 状态同步机制不同
  普通connect搭配CoProcessFunction时，两个流的状态都存储在每个并行子任务的本地内存中，不会跨节点、跨实例做状态同步。如果手动把其中一个流做广播分发，所有实例上存的“广播值”是没有全局一致性保障的——比如规则流更新了一条配置，不同并行实例收到配置消息的时间差、或者Task故障重启后，很可能出现不同实例持有不同版本配置的情况。
  BroadcastProcessFunction依托Flink内置的广播状态机制，会保证所有并行子任务持有的广播状态完全一致：无论是正常运行时的状态更新，还是故障恢复、并行度调整的场景下，所有实例的广播状态都能对齐到同一个版本，不存在版本差。
• 消息路由逻辑不同
  CoProcessFunction的双流路由完全依赖上游的分区规则：如果两个流没有指定相同的key做分区对齐，同一个关联维度的两个流消息可能被分配到完全不同的子任务上，根本无法触发关联逻辑；哪怕是手动广播其中一个流，非广播流的消息也只会按照原来的分区规则被分配到对应实例，不会和广播流做全局的路由对齐。
  BroadcastProcessFunction的路由逻辑是天然适配广播场景的：广播流的所有消息会被复制分发到每一个并行子任务，非广播流不管按照什么规则分区，都会在本地直接匹配当前实例上存的全局广播状态做处理，不需要额外做key对齐或者shuffle。
• 开销模型不同
  CoProcessFunction的状态是纯本地的，没有跨节点同步、全局状态对齐的开销，在高吞吐场景下的处理延迟更低。
  BroadcastProcessFunction为了保障全局状态一致性，会在checkpoint阶段对所有实例的广播状态做全局快照校验，存在一定的同步开销，吞吐能力相比CoProcessFunction会低一些，更适配低吞吐的广播流场景。

适合用BroadcastProcessFunction（广播状态模式）的场景 #

• 需要用低吞吐的规则/配置流，控制全集群所有并行任务的处理逻辑。比如风控规则引擎、动态阈值配置，要求所有实例对同一条业务数据的处理逻辑完全一致，不能出现版本差异，这种场景手动用CoProcessFunction做广播很容易出现一致性bug，必须用内置广播状态。
• 需要用全量小维度表做流关联，替代高成本的shuffle join。比如把几MB的商品维度表广播到所有算子实例，避免主流和维度表join时产生的全量数据shuffle，大幅提升关联性能。
• 两个流的关联需要共享全集群统一的全局状态，不能出现单实例状态和全局规则脱节的情况。

适合直接用普通connect+CoProcessFunction的场景 #

• 两个流都是高吞吐数据流，且可以通过相同key做分区对齐。比如订单流和支付流都按照订单ID做keyBy，连接后完成同一订单的状态拼接，这种场景每个实例只需要存储自己负责的key对应的状态，完全不需要全局同步，CoProcessFunction的性能更高。
• 两个流的交互不存在严格的全局状态一致性要求。比如主流是业务日志流，另一个低吞吐流是本地日志级别配置，哪怕短时间内不同实例的日志级别不一致，也不会影响核心业务的计算结果，完全不需要为了极低收益承担广播状态的同步开销。
• 两个流仅需要在同一个算子内做独立并行处理，没有深度关联需求。比如一个算子同时处理业务流量和系统监控指标流，两个流的处理逻辑独立、输出通道独立，不需要互相共享状态，用CoProcessFunction写起来更轻量化，不需要额外定义广播状态描述器。

很多开发者觉得可以用CoProcessFunction手动实现广播状态，本质是忽略了故障恢复、并行度调整等异常场景下的状态一致性问题——比如线上曾出现过类似事故：手动做规则广播的作业，TaskManager宕机重启后，新起来的实例没有从广播流拿到最新的规则版本，导致同一笔交易被不同实例按不同规则处理，产生了资损。这种实现方式在生产环境的稳定性远低于Flink原生的广播状态机制，不建议在核心业务链路使用。

内容的提问来源于stack exchange，提问作者Sergey Postument