
1 dzdh 2022-07-11 21:50:02 +08:00 比如下单 大量下单请求实时操作数据库进行扣减,可能会慢、卡顿、甚至数据库崩溃等等。 MQ 不会,大量订单下来一股脑全扔到 MQ ,隔壁的消费者慢慢的一个个消费,顺序操作数据库,然后再返回下单成功与否。 保持系统负载最高在某个点。 |
2 sawyera 2022-07-11 21:53:04 +08:00 via Android mq 的 consumer 一般是单线程跑 for 循环消费消息。所以不管有多少消息,消费端都按自己的消费速率一点一点处理,自然就削峰填谷了。 |
3 MakHoCheung 2022-07-11 22:13:25 +08:00 @sawyera 问下,多线程来消费信息的怎么保证消费的顺序 |
4 JasonLaw 2022-07-11 23:21:29 +08:00 |
5 qping 2022-07-12 09:08:58 +08:00 @MakHoCheung #3 什么场景下要保证消费的顺序? |
6 cxe2v 2022-07-12 09:22:57 +08:00 @MakHoCheung #3 再开一个 topic ,后续操作丢到新的 topic 下,然后下一步的 consumer 按照自己节奏来 |
8 cxe2v 2022-07-12 10:02:12 +08:00 @fatyoung #7 要求消费顺序必然是第二步要在第一步后面,现在将消息进行了拆分,第二个 topic 里全是第二步,它们的第一步已经都是被操作过的,所以第二个 topic 的 consumer 就是多线程也不会影响这些已经完成第一步的消息的顺序 |
9 fatyoung 2022-07-12 10:14:58 +08:00 @cxe2v 哦哦我理解你的意思了。你说的消费顺序是指每个消息里面不同操作的顺序,我说的是序号 1 到 100 的消息按顺序发到服务器之后,消费者也要从序号 1 到 100 按顺序消费。 |
11 fatyoung 2022-07-12 11:09:01 +08:00 @cxe2v 我的理解是:生产者的消息确实是顺序发送的,但是到了 broker 之后,存储可能不是顺序的,而且可能是存在多个分区的,同一个分区下消息确实是先进先出,多个分区就不能保证了。 |
12 MakHoCheung 2022-07-12 13:12:54 +08:00 @qping 处理有状态( a->b->c )的消息,比如网络延迟可能状态 c 的消息先被处理,b 的消息后被处理。我能想到就是丢掉 c 然后让生产者重发 c |
13 qping 2022-07-12 13:17:23 +08:00 |