blessingcr

@sujin190 确认了一下，这个我们在 A 系统可以做到说他确认了再给他发下一个，因为只是同一个商品流程在某一操作过程中的上链，A 系统可以自己做分布式锁，保证某一商品在上链过程中的顺序。因为我理解链上只需要保证生产的顺序，这个比较好保证，最差情况等 ack 了再发下一个，得益于这个是个区块链，消费的顺序一定是固定的。

kafka 分区 加分布式锁这个确实好像也可以，是一个方案，我晚点想想画画图

@ily433664 这个消费者的同一个服务下多节点有办法保证顺序吗？这个服务起多少个节点由 K8S 控制，非人为控制的

@helone 是个好方法，但我们的消息不能丢 QAQ
@murmur Y? 因为我把区块链理解为一本公开的账本，大家按照同样逻辑操作到同样高度的时候，保证了数据的一致和可靠，能辛苦解答一下吗

@sngxx 这个单一消费者性能过差了，如果不是单一消费者，服务多节点的时候，假设系统 B 可以做到 mq 的顺序，他保证了 mq 内消息的顺序，但是因为 B 系统和 A 系统用了 HTTPS 通信，所以 B 系统在消费 B 系统的 MQ 消息发送给 A 的时候，A 接收就已经没有顺序了。如果 AB 用 MQ 通信，则 A 系统在接收消息（假设消息已经由 B 系统做好了 hash 和规则分片）的时候，多个消费节点需要手动指定他需要的处理的 partition ，且这时要保证严格顺序，每一个 partition 只能有一个消费者。阿里嘎多
@aarontian 同上，阿里嘎多
@8355 同上，阿里嘎多

@chen11 因为 mq 真不能保证顺序，无论生产顺序和消费顺序我们都不能保证

@giao123 两个系统都是微服务架构，长链接这不好吧

@bcllemon 性能过差了 QAQ

@codegenerator 干掉我比较容易 QAQ

ruoyi 不行
建议 spring cloud pig