Flink中广播状态的高效清理方案咨询

我现在运行着一个采用广播状态模式的Flink作业，通过将广播流与事件流连接，为业务决策提供上下文支撑。广播流的数据都是体积较小的对象，吞吐量处于中等水平。

由于广播状态只能在广播侧进行操作，目前我采用的状态清理方案是：在processBroadcastElement方法中遍历整个状态集合，根据对象的特定属性删除符合清理条件的条目，以此避免状态在内存中无限膨胀。

正常运行时这个方案表现不错，不会对算力造成明显压力。但遇到需要清空状态并重新加载数十万条广播流数据的场景时（当前checkpoint大小约为15MB × 2个并行实例），Co-Process-Broadcast算子会直接跑满100%负载，导致两个数据源都出现完全背压的情况。

我构思了几个可能更优的解决方案：

• 将当前的广播数据存储改为MapState，同时把事件流调整为按Key分区的流，这样就能在RichMapFunction中访问状态，需要时在该函数内完成状态清理
• 同样采用MapState存储广播数据+按Key分区的事件流，但改为在事件流的KeyedProcessFunction中设置定时器，定期触发全量状态清理
• 参考双流连接的实现思路，将两个流按照同一个ID进行分区，把广播数据存入MapState中，待事件流的对象到达时再取用这些数据

想请教各位，哪种方案是这类场景下最“标准”的实现模式？同时哪一种方案的性能表现会最优呢？

备注：内容来源于stack exchange，提问作者Noah