这是一个创建于 1889 天前的主题，其中的信息可能已经有所发展或是发生改变。
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 数据量很大的情况下，用什么消费组件能做到水平扩展？ 有大数据处理经验的给些建议，感谢
 |
1
snappyone 2019-10-10 00:56:15 +08:00 via Android
数据统一上报到一个 topic，这个 topic 后面接多个 kafka 的消费者组再分发到不同的 db。topic 消费压力大就多加 partition 并行消费，不知道你这个数据到底有多大，还有是不是有顺序要求
|
 |
2
chibupang 2019-10-10 00:58:25 +08:00 via Android
为什么不用 clinet1 订阅 topic1，负责 topic1 数据的入库，client2 负责 topic2 的入库，数据流量根本不需要 double。
|
|
3
chibupang 2019-10-10 00:59:53 +08:00 via Android
不好意思，没申清楚题目，忽略我....
|
 |
4
LeeSeoung 2019-10-10 09:24:12 +08:00
分两个 topic 合适，一是所有数据都堆积在同一个 topic 影响性能，二是消费的时候可以针对一类数据单独处理，kafka 是顺序消费，有其他观点欢迎交流。
|
 |
5
qq976739120 2019-10-10 09:42:22 +08:00
如果一条消息,有发送到不同仓库的需求,那就按不同的 topic 去发多次(在没有生产者性能要求的情况下),因为你接下来很有可能街道对发送消息做额外处理的需求,别问我怎么知道的.至于水平扩展,kafka 可以说是相当简单了,改改配置就行
|
 |
6
feng1o OP @LeeSeoung 分 2 个 topic 实际上是一份数据分别上报两个，procedure 端网络流量要 double ； 可能会有问题
|
|
7
feng1o OP @qq976739120 上报多个 topic，和单个 topic ； 消费端走 double 到不同的 topic 转发，好像确实没什么区别；额外处理，可以再第一次转发的 topic 里消费再做
|
 |
8
j2gg0s 2019-10-10 12:25:56 +08:00
数据按数据类型上报到不同的 topic，消费端按需订阅一个或多个 topic ；
消息队列的一个重要意义是在生产和消费解藕； 想象下之后有变动的时候，你的方案能不能轻松兼容 |
 |
10
heixiongtt 2019-10-11 13:55:58 +08:00
@feng1o 不同客户仓库的消费者分成不同 consumer group,然后添加一个订阅所有 topic 的 consumer group
|
 |
11
lithium4010 2019-10-12 15:58:01 +08:00
选 b
|
Select Language