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

项目中使用到 kafka 做 mq,大家看下架构设计有什么可改进的地方或可能的坑?

  •  
  •   feng1o · 2019-10-10 00:25:20 +08:00 · 2020 次点击
    这是一个创建于 1632 天前的主题,其中的信息可能已经有所发展或是发生改变。

    1. 需求:

        所有数据需要上报一个内部数据库,其中部分数据同时需要上报不同客户仓库;总的数据量很大。
    

    2.方案

       a. 所有数据 procedure 根据不同用户需求分别上报内部通用 topic1 和用户 topic2 ;
             特点:1.procedure 端数据流量 double (可能流量是瓶颈)
                   2.简单、直观;消费端直接消费即可,topic1 可用 kafka connect 消费转换存入 db
    
       b. 所有数据 procedure 全部上报通用 topic1 (需上报用户 topic 的消息加入 tag ),kafka stream 消费 topic1 数据流,并分别上报到内部数据库,或用户的 topic2...n ;
              特点:1.procedure 端数据统一上报一份 
                    2.增加 stream 消费处理分发环节,需要确保消费能力 > procedure,无数据积压,不丢数据;
                    3.stream 维护成本
               
    

    3.疑问

       对 kafka 不太了解;方案 a/b 感觉都存在问题。既然都要去 topic1 消费上报 db,那 b 和 a 比有绝对优势,改造下处理上报即可。
      
       topic1 数据量很大的情况下,用什么消费组件能做到水平扩展? 有大数据处理经验的给些建议,感谢
    
    11 条回复    2019-10-12 15:58:01 +08:00
    snappyone
        1
    snappyone  
       2019-10-10 00:56:15 +08:00 via Android
    数据统一上报到一个 topic,这个 topic 后面接多个 kafka 的消费者组再分发到不同的 db。topic 消费压力大就多加 partition 并行消费,不知道你这个数据到底有多大,还有是不是有顺序要求
    chibupang
        2
    chibupang  
       2019-10-10 00:58:25 +08:00 via Android
    为什么不用 clinet1 订阅 topic1,负责 topic1 数据的入库,client2 负责 topic2 的入库,数据流量根本不需要 double。
    chibupang
        3
    chibupang  
       2019-10-10 00:59:53 +08:00 via Android
    不好意思,没申清楚题目,忽略我....
    LeeSeoung
        4
    LeeSeoung  
       2019-10-10 09:24:12 +08:00
    分两个 topic 合适,一是所有数据都堆积在同一个 topic 影响性能,二是消费的时候可以针对一类数据单独处理,kafka 是顺序消费,有其他观点欢迎交流。
    qq976739120
        5
    qq976739120  
       2019-10-10 09:42:22 +08:00
    如果一条消息,有发送到不同仓库的需求,那就按不同的 topic 去发多次(在没有生产者性能要求的情况下),因为你接下来很有可能街道对发送消息做额外处理的需求,别问我怎么知道的.至于水平扩展,kafka 可以说是相当简单了,改改配置就行
    feng1o
        6
    feng1o  
    OP
       2019-10-10 10:30:45 +08:00
    @LeeSeoung 分 2 个 topic 实际上是一份数据分别上报两个,procedure 端网络流量要 double ; 可能会有问题
    feng1o
        7
    feng1o  
    OP
       2019-10-10 10:38:27 +08:00
    @qq976739120 上报多个 topic,和单个 topic ; 消费端走 double 到不同的 topic 转发,好像确实没什么区别;额外处理,可以再第一次转发的 topic 里消费再做
    j2gg0s
        8
    j2gg0s  
       2019-10-10 12:25:56 +08:00
    数据按数据类型上报到不同的 topic,消费端按需订阅一个或多个 topic ;
    消息队列的一个重要意义是在生产和消费解藕;
    想象下之后有变动的时候,你的方案能不能轻松兼容
    feng1o
        9
    feng1o  
    OP
       2019-10-10 14:40:41 +08:00
    @j2gg0s 比如使用公有云厂商的 kafka,有很多 topic,有一个消费端默认是都要消费的,那就很难做到
    heixiongtt
        10
    heixiongtt  
       2019-10-11 13:55:58 +08:00
    @feng1o 不同客户仓库的消费者分成不同 consumer group,然后添加一个订阅所有 topic 的 consumer group
    lithium4010
        11
    lithium4010  
       2019-10-12 15:58:01 +08:00
    选 b
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1373 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 17:41 · PVG 01:41 · LAX 10:41 · JFK 13:41
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.