我有一个事件流需要丰富的订阅信息。有些事件是广播事件，这意味着当接收到此类事件时，我需要转到数据库表，找到事件的所有订户，在我的用例中可以是10000行，然后将单个广播事件转换为10000个通知事件。对于普通事件类型，还有一个附加的user\ id密钥可用于加入订阅表，而订阅表没有问题。
挑战是
如何加入一个大的结果集，将它们返回到内存似乎不是一个可伸缩的解决方案。有没有办法把它划分成许多更小的并行任务？
如何组织处理管道，使正常事件和广播事件不相互干扰。我不希望连续长时间运行的广播事件阻塞正常事件的处理管道。
我刚刚开始使用flink，对于这个用例，什么是正确的或性能良好的体系结构？如果需要，广播事件类型和正常事件类型可以分为两个源。
1条答案
按热度按时间wf82jlnq1#
理想情况下，您可以提供辅助信息（数据库表）作为flink的附加输入，然后只需使用连接即可。只有当信息可以通过flink连接器获取时，这才是可行的。这样做的好处是，如果操作正确，即使是表上的更新也会适当地反映在输出中。您也不需要关心结果的大小，因为这将由flink自动处理。
或者，您可以使用
asyncIO，特别是为了与外部系统进行交互。不好的一面asyncIO当前所有活动请求的所有结果都必须放入主内存。但对于10000行来说，这应该是可行的，特别是因为相应的事件似乎很少发生。