我有一个事件流需要用订阅信息来丰富。有些事件是广播事件，这意味着当收到这样的事件时，我需要去数据库表，找到事件的所有订阅者，在我的用例中可以是10000行，然后将单个广播事件转换为10000个通知事件。对于正常的事件类型，可以使用额外的user_id键来加入订阅表，这没有问题。
面临的挑战
- 如何加入一个大型ResultSet，将它们返回内存似乎不是一个可扩展的解决方案。有没有办法将其划分为许多较小的并行任务
- 我如何组织处理管道，使正常事件和广播事件不会相互干扰。我不希望连续长时间运行的广播事件阻塞正常事件的处理管道
我刚开始使用Flink，这个用例的正确架构或性能架构是什么？如果需要，广播事件类型和正常事件类型可以分为两个源。
理想情况下，您可以提供辅助信息(数据库表(作为Flink的额外输入，然后只需使用联接。只有当Flink连接器可以获取信息时，这才是可行的。其优点是，如果操作正确，即使表上的更新也会适当地反映在输出中。您也不需要关心结果大小，因为Flink会自动处理结果大小。
或者，您可以使用asyncIO，它特别用于与外部系统交互。asyncIO的缺点是，当前所有活动请求的所有结果都必须放入主存中。但这对于10_000行来说应该是可行的，尤其是因为相应的事件似乎很少发生。