老师， 各个task都对bc做快照， 防止恢复的时候从一个task做恢复，造成热点压力， 这个该怎么理解？

视频中给的例子，是不是可以理解为就是把配置数据进行广播？

老师，我在实践的过程中发现connect broadcast流会出现主流和广播流的顺序性问题，导致主流无法关联到广播流中的数据，我在网上找到了两种解决这个问题的方案：1.配置流通过jdbc获取，使用fromCollection，然后再union之前CDC获取的实时流，这样测出的结果是肯定能关联到，但是我想不通为什么union这种预先获取的数据肯定会在connect的时候先流进来... 2.使用ListState的方式，关联不到配置的数据都缓存起来，等配置流加载完毕再进行关联处理，但是这种方式我无法知道何时配置流已经加载完毕，而且在某些情况下会缓存大量数据，清理的时机也不好把控

单就这节课而言，保存Pattern使用 ValueState 就行了吧

“更新state是不能依赖元素到达的顺序”是什么意思？

CEP的实现是基于BroadcastState吗？

有个疑问，这里在外部定义的那个Map类型状态描述符是什么意义呢，实际是用的richfunction里面定义的键控状态

老师，我有一个场景。是定时从mysql获取数据作为广播流。这里遇到两个问题:1，任务运行的时候主数据流会比广播流先到。2，读取广播流这个任务每天0点状态就会变成state。 问题一我在BroadcastProcessFunction中的open方法加了一个初始化加载数据的处理方法。 问题2现在还是没有头绪，怎么能保持这个广播流一直处于running状态啊

通过接入广播流然后去匹配规则，符合规则则进行输出，不符合就等待下次符合输出？本次案例我产生如下疑点：1、我们的行为流是我们用户的实时的行为数据产生发送到我们的消息队列，那么我的规则流呢？规则流跟行为流是并行关系吗？这一点没搞明白，因为规则流消费消费完了kafka消费点更新完了就没了，那么这个规则是怎么触发产生呢？ 2、不符合的要一直等待吗？一直没有结束呢？如何处理？