V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Euthpic
V2EX  ›  Kafka

求一个基于 kafka 的消息消费框架

  •  
  •   Euthpic · 189 天前 · 622 次点击
    这是一个创建于 189 天前的主题,其中的信息可能已经有所发展或是发生改变。

    背景: 我们现有的缓存同步方案基于 canal 和 kafka,db 更新时 canal 拉取 binlog 发消息到 kafka,然后多个业务方各自消费消息.

    缺点: 1.缺少统一的调度,消费者零散地散落在各个项目里,消息堆积时不好扩容. 2.同一条消息(对同一张表的一条操作记录)会下发到多个消费者(不同的业务逻辑),浪费网络资源.同时 binlog 的消息是全量下发(所有表的操作记录推到同一个 topic),消费者还得各自筛选自己需要的消息,浪费 cpu 资源. 3.消费者之间可能有依赖关系,但是业务逻辑是解耦的,不能相互调用,因此无法感知到依赖的资源是否已经到位.

    所以我们计划把这些消费者整合到同一个项目里面统一管理,统一调度. 深思熟虑了 5 分钟之后,我感觉可能遇到这些问题: 1.如何协调消费者之间的依赖关系?如果直接把它们丢到一个串行的方法里面,那么调用链就很长,消息延迟就很严重,有些消费者本来没有前置依赖,但却要白白等前面的消费者执行完,不合理.如果都是异步去调用它们的话,就无法感知到依赖关系. 2.消息消费的速度会不会受到影响?以前一条消息开了很多消费者去消费,现在整合到一起,调用链变长了.

    所以想问问大家有没有现成的开源框架是解决这类问题的? 我们开发的语言是 scala 和 java,mq 是 kafka,当然消息源最好也能支持其他 mq

    2 条回复    2021-07-22 09:50:32 +08:00
    RichardYyf
        1
    RichardYyf  
       189 天前 via Android
    所有表的操作记录都到一个 topic 就非常不合理。牵一发动全身?我们都是每个表单独 topic 的,除非是分库分表那种
    ipwx
        2
    ipwx  
       189 天前
    1. 同意 1L,只用一个 topic 这也太不合理了。这哪里解耦了,明明是宇宙无敌大杂烩。运维都要哭了。
    2. 业务之间的依赖关系,总感觉这不是 Kafka 的事情。你这么想,如果这些消息不是一个 topic,而是每个消费者(我觉得应该改个时髦的名词,“微服务”)自己有自己的 topic 。那么你后继微服务只要消费前驱微服务产生的 topic 就行了。整个系统自然而然就充分并行化了。

    所以关键是,对相同功能的“消费者”进行合并,区分 topic 。我觉得该这么改。
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3444 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 09:50 · PVG 17:50 · LAX 01:50 · JFK 04:50
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.