这是一个创建于 371 天前的主题，其中的信息可能已经有所发展或是发生改变。
原文： https://v2ex.com/t/1091247 思考着考虑了一下以下形式 不知道这样做有没有什么问题 辛苦各位 dalao 指点（我帮你或我吊你都行的
 | 1 csys 2024-11-22 16:03:26 +08:00  1 槽点过多…… 这不就是并发一致性问题么 无论是同步的 http ，还是异步的 mq ，你这业务场景都是命令消息，都是请求-响应模式的 一致性冲突的话直接把该失败的请求失败掉不就行了 http 就不说了，mq 的话 1.：发送请求上架消息，等待上架结果消息 2.：处理请求上架消息，发布上架结果消息 3.：收到上架结果消息，完成上架 如果这个流程时间很长的话，就给个“上架中”的中间状态来跟踪 锁用来保证局部的一致性 关区块链啥事啊，你这不是中心化的数据存储吗 你这个图也挺抽象的，第一次见到这种图，solidworks 画的吗 |
 | 2 blessingcr OP @csys 最后没有用区块链，因为没经验线上问题怕处理不了 mq 也不是不行，主要是多个业务耦合，上架的不能只处理上架，下架也不能只处理下架，同一关联的商品业务之间需要确保串行，但是不同商品的业务之间不需要保证串行。 为什么不能用纯 MQ 完成呢？因为这个 A 系统需要对外，B 系统是很多个的，有的在内网有的在外网，MQ 不能暴露在外网。 所以有一个奇怪的中间件类似 mq 的服务，那为什么这个服务需要一个像区块链一样的东西呢？因为需要确保对于某一业务而言消费串行。 |
| 3 csys 2024-11-22 16:49:12 +08:00 @blessingcr 你这交互是 请求-响应 模式的，内部实现可以用 http grpc 或者 mq 都行 > 有的在内网有的在外网，MQ 不能暴露在外网 mq 是个内部系统的基础设施，和外界交互肯定还是得用 [接口] 啊 比如其中一个选择就是 B 系统启动是注册自己的位置，提供一个监听接口，A 和 B 通讯的时候调用 B 注册的接口 或者 A 系统将待发送的消息放在 outbox ，B 系统通过 polling 来取消息 或者 更简单的，直接建立 websocket 连接，使用类似聊天室的框架（比如 signalr ），单播、广播也一块支持了 类似的方案到处都是 > 确保对于某一业务而言消费串行 这个和区块链有啥关系，用区块链性能不更低了 这就看一致性在哪保证，如果是数据库来保证就是用数据库事务，你反正也是中心存储的 如果是分布式系统，数据分散在不同数据库，就用分布式锁来保证强一致性，或者 saga 来实现最终一致性 |
| 4 blessingcr OP @csys 内部无所谓 > 比如其中一个选择就是 B 系统启动是注册自己的位置，提供一个监听接口，A 和 B 通讯的时候调用 B 注册的接口 或者 A 系统将待发送的消息放在 outbox ，B 系统通过 polling 来取消息 这个就是这个图右下角，主动拉取，类似于这个 outbox ，至于这个请求究竟是 https ，tcp ， 还是 websocket 无所谓 > 这个和区块链有啥关系，用区块链性能不更低了 这个类似于原文中的有人提到过，用 mq 细分业务，业务相互耦合的放在一起，每一个 topic 是一个链，我这里这个中心化消息服务只是类似的做了一个简单的 queue ，存的结构是一个链式的结构 用区块链性能并不更低的想法在于，一个有智能合约，可以减少 AB 系统之间的请求，有些直接找链条要就行了，第二个不是做成一条链，可以做成多条。 这个和区块链有关系吗？ 没有，只是样子像 > 如果是分布式系统，数据分散在不同数据库，就用分布式锁来保证强一致性，或者 saga 来实现最终一致性 当然有锁，锁的时候只要系统 A 保证他写入顺序，其他的系统 B 因为是通过拉取的方式获得数据，所以一定顺序，拉取后的消息系统 B 自行保证业务耦合的地方顺序即可 |
Select Language