有一个消息同步的问题请教各位 dalao

[blessingcr]

背景：

• A 系统是一个面向用户的 saas 系统，用户的所有操作都会在 A 系统上操作。
• B 系统是一个独立的系统，A 系统的几乎所有核心操作都需要转发到 B 系统，等 B 系统通过以后，再重新下发到 A 系统做其他操作。

目前存在问题：

• 1. AB 系统通信使用 HTTPS, 有时会有多个消息，有相对应的顺序关系，比如有一个商品上架请求，再有一个商品库存变更请求，如果 B 系统下发给 A 系统时，A 先收到了库存变更，再收到上架，第一个库存变更就会失败。
• 1. 虽然通信使用 HTTPS ， 但是其实很多操作都是 A 系统的 MQ 处理后，HTTPS 到 B 系统，B 系统放 MQ ，然后 B 系统处理，即便业务中先调用的接口也不一定 B 系统先收到。
• 1. 如果 A 系统消费失败某个消息，不好重试。
• 1. A 系统是一个 saas 系统，每个租户都会收到一次 B 系统给他发的信息（因为后期考虑独立化部署，B 系统都发给每一个租户），压力比较大

思考的解决方案：

• 1. 一个是考虑用区块链，B 系统每次把内容丢到链上，A 系统慢慢消费，这样顺序可以保证，但是如果不用智能合约的话这个开发成本很高，如果用的话我司没有非常专业的合约开发，我这种半吊子怕到时生产有问题解决不了。
• 1. 第二种就是考虑直接 mq 通信，但是这样其实也没有解决消息先后的问题，两个系统都是微服务，除非 mq 强制顺序，但这样性能过差

想问问各位 dalao 有没有合适的解决方案，或者有什么中间件云服务能解决此类问题，thk~

[aarontian]

我依然认为分 partition 能解决所谓的性能问题，不知道你们是什么样的业务解决不了，除非连每个业务 flow 的 id 都没法分，那就是场景本身的问题了。

算了跳过性能问题，“一个 partition 只能对应一个消费者”这难道不是默认行为么？ partition 和 consumer 多对一，跟是不是顺序消息没有关系，感觉你对 mq 有深刻的误解。。（当然也可能是我没懂你的顾虑）

[siweipancc]

你这个队列解决不了，除非你规定一个序列跟计数器，计数不对扔回去队列

[litchinn]

Aeron ，但是门槛有点高