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

槽点过多……
这不就是并发一致性问题么

无论是同步的 http ，还是异步的 mq ，你这业务场景都是命令消息，都是请求-响应模式的
一致性冲突的话直接把该失败的请求失败掉不就行了

http 就不说了，mq 的话

1.：发送请求上架消息，等待上架结果消息
2.：处理请求上架消息，发布上架结果消息
3.：收到上架结果消息，完成上架

如果这个流程时间很长的话，就给个“上架中”的中间状态来跟踪
锁用来保证局部的一致性

关区块链啥事啊，你这不是中心化的数据存储吗

你这个图也挺抽象的，第一次见到这种图，solidworks 画的吗

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

@blessingcr

你这交互是 请求-响应 模式的，内部实现可以用 http grpc 或者 mq 都行

> 有的在内网有的在外网，MQ 不能暴露在外网
mq 是个内部系统的基础设施，和外界交互肯定还是得用 [接口] 啊
比如其中一个选择就是 B 系统启动是注册自己的位置，提供一个监听接口，A 和 B 通讯的时候调用 B 注册的接口
或者 A 系统将待发送的消息放在 outbox ，B 系统通过 polling 来取消息
或者 更简单的，直接建立 websocket 连接，使用类似聊天室的框架（比如 signalr ），单播、广播也一块支持了
类似的方案到处都是

> 确保对于某一业务而言消费串行

这个和区块链有啥关系，用区块链性能不更低了
这就看一致性在哪保证，如果是数据库来保证就是用数据库事务，你反正也是中心存储的
如果是分布式系统，数据分散在不同数据库，就用分布式锁来保证强一致性，或者 saga 来实现最终一致性

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

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


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