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

[feng1o]

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 数据量很大的情况下，用什么消费组件能做到水平扩展？ 有大数据处理经验的给些建议，感谢

[snappyone]

数据统一上报到一个 topic，这个 topic 后面接多个 kafka 的消费者组再分发到不同的 db。topic 消费压力大就多加 partition 并行消费，不知道你这个数据到底有多大，还有是不是有顺序要求

[chibupang]

为什么不用 clinet1 订阅 topic1，负责 topic1 数据的入库，client2 负责 topic2 的入库，数据流量根本不需要 double。

[chibupang]

不好意思，没申清楚题目，忽略我....

[LeeSeoung]

分两个 topic 合适，一是所有数据都堆积在同一个 topic 影响性能，二是消费的时候可以针对一类数据单独处理，kafka 是顺序消费，有其他观点欢迎交流。

[qq976739120]

如果一条消息,有发送到不同仓库的需求,那就按不同的 topic 去发多次(在没有生产者性能要求的情况下),因为你接下来很有可能街道对发送消息做额外处理的需求,别问我怎么知道的.至于水平扩展,kafka 可以说是相当简单了,改改配置就行

[feng1o]

@LeeSeoung 分 2 个 topic 实际上是一份数据分别上报两个，procedure 端网络流量要 double ； 可能会有问题

[feng1o]

@qq976739120 上报多个 topic，和单个 topic ； 消费端走 double 到不同的 topic 转发，好像确实没什么区别；额外处理，可以再第一次转发的 topic 里消费再做

[j2gg0s]

数据按数据类型上报到不同的 topic，消费端按需订阅一个或多个 topic ；
消息队列的一个重要意义是在生产和消费解藕；
想象下之后有变动的时候，你的方案能不能轻松兼容

[feng1o]

@j2gg0s 比如使用公有云厂商的 kafka，有很多 topic，有一个消费端默认是都要消费的，那就很难做到

[heixiongtt]

@feng1o 不同客户仓库的消费者分成不同 consumer group,然后添加一个订阅所有 topic 的 consumer group

[lithium4010]

选 b