当前场景的架构演进过程。首先,在 Flink + MQ 架构中,当前场景的消息类型为 Changelog。因为 MQ 并不支持传递 Changelog 类型数据,所以在指标计算之前,需要按照用户粒度 + 直播间粒度,使用 Last_Value 等聚合函数手动构建 Retract 消息,再根据直播间 ID 聚合,得到直播间的用户举报人数。在此过程中,Flink 链路会产生大量的 Keyed State,并且由于审核完成时间不固定,无法确定状态到底需存储多久,这导致 Flink 任务中的状态会线性膨胀,引发任务不稳定。
最终,团队采用 Doris 方案实现,将用户的举报明细直接写入 Doris 的明细表中,在查询服务层实现整体的计算逻辑。根据主播 ID 和直播间的开播 / 关播时间,点查 Doris 明细表,解决了 Flink + MQ 链路中的大状态问题。但是,为保障 Doris 集群的整体稳定性,对接口进行了限流,将限流阈值设置为 150 QPS。因此,当查询遇到高并发时,经常会触发限流,影响用户的查询体验。