blessingcr

@csys
内部无所谓
> 比如其中一个选择就是 B 系统启动是注册自己的位置，提供一个监听接口，A 和 B 通讯的时候调用 B 注册的接口
或者 A 系统将待发送的消息放在 outbox ，B 系统通过 polling 来取消息
这个就是这个图右下角，主动拉取，类似于这个 outbox ，至于这个请求究竟是 https ，tcp ， 还是 websocket 无所谓

> 这个和区块链有啥关系，用区块链性能不更低了
这个类似于原文中的有人提到过，用 mq 细分业务，业务相互耦合的放在一起，每一个 topic 是一个链，我这里这个中心化消息服务只是类似的做了一个简单的 queue ，存的结构是一个链式的结构
用区块链性能并不更低的想法在于，一个有智能合约，可以减少 AB 系统之间的请求，有些直接找链条要就行了，第二个不是做成一条链，可以做成多条。
这个和区块链有关系吗？ 没有，只是样子像


> 如果是分布式系统，数据分散在不同数据库，就用分布式锁来保证强一致性，或者 saga 来实现最终一致性
当然有锁，锁的时候只要系统 A 保证他写入顺序，其他的系统 B 因为是通过拉取的方式获得数据，所以一定顺序，拉取后的消息系统 B 自行保证业务耦合的地方顺序即可

@csys 最后没有用区块链，因为没经验线上问题怕处理不了
mq 也不是不行，主要是多个业务耦合，上架的不能只处理上架，下架也不能只处理下架，同一关联的商品业务之间需要确保串行，但是不同商品的业务之间不需要保证串行。
为什么不能用纯 MQ 完成呢？因为这个 A 系统需要对外，B 系统是很多个的，有的在内网有的在外网，MQ 不能暴露在外网。
所以有一个奇怪的中间件类似 mq 的服务，那为什么这个服务需要一个像区块链一样的东西呢？因为需要确保对于某一业务而言消费串行。

@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