这是一个创建于 1212 天前的主题，其中的信息可能已经有所发展或是发生改变。
背景: 我们现有的缓存同步方案基于 canal 和 kafka,db 更新时 canal 拉取 binlog 发消息到 kafka,然后多个业务方各自消费消息.
缺点: 1.缺少统一的调度,消费者零散地散落在各个项目里,消息堆积时不好扩容. 2.同一条消息(对同一张表的一条操作记录)会下发到多个消费者(不同的业务逻辑),浪费网络资源.同时 binlog 的消息是全量下发(所有表的操作记录推到同一个 topic),消费者还得各自筛选自己需要的消息,浪费 cpu 资源. 3.消费者之间可能有依赖关系,但是业务逻辑是解耦的,不能相互调用,因此无法感知到依赖的资源是否已经到位.
所以我们计划把这些消费者整合到同一个项目里面统一管理,统一调度. 深思熟虑了 5 分钟之后,我感觉可能遇到这些问题: 1.如何协调消费者之间的依赖关系?如果直接把它们丢到一个串行的方法里面,那么调用链就很长,消息延迟就很严重,有些消费者本来没有前置依赖,但却要白白等前面的消费者执行完,不合理.如果都是异步去调用它们的话,就无法感知到依赖关系. 2.消息消费的速度会不会受到影响?以前一条消息开了很多消费者去消费,现在整合到一起,调用链变长了.
所以想问问大家有没有现成的开源框架是解决这类问题的? 我们开发的语言是 scala 和 java,mq 是 kafka,当然消息源最好也能支持其他 mq
 |
1
RichardYyf 2021-07-22 09:17:05 +08:00 via Android
所有表的操作记录都到一个 topic 就非常不合理。牵一发动全身？我们都是每个表单独 topic 的，除非是分库分表那种
|
 |
2
ipwx 2021-07-22 09:50:32 +08:00
1. 同意 1L，只用一个 topic 这也太不合理了。这哪里解耦了，明明是宇宙无敌大杂烩。运维都要哭了。
2. 业务之间的依赖关系，总感觉这不是 Kafka 的事情。你这么想，如果这些消息不是一个 topic，而是每个消费者（我觉得应该改个时髦的名词，“微服务”）自己有自己的 topic 。那么你后继微服务只要消费前驱微服务产生的 topic 就行了。整个系统自然而然就充分并行化了。 所以关键是，对相同功能的“消费者”进行合并，区分 topic 。我觉得该这么改。 |
Select Language