关于分布式事务的方案,大家看看有没有漏洞?

Torreson 2018-05-10 11:15:54
1. 扣库存(服务A)
2. 扣钱(服务B)
3. 加物流信息(服务C)

+ 服务A(写数据库,调服务B,发消息到mq)
1. 写日志。(log或数据库,写请求信息)(调B系统还没返回时(其实成功了),服务重启或宕机的情况追踪),或者持久化任务表,后续异常重试调服务B,获取最终结果。
2. 扣库存,调服务B(同一个事务)
- 成功。提交数据库,扣库存。
- 失败。抛异常回滚。
- 超时。(重试几次,仍然失败则抛异常回滚,但是后续要继续重试取消扣库存)
3. 物流信息,非强一致性数据。发消息到mq,由各个业务方订阅。
- 持久化可靠mq,保证最终一致性
- 不可靠mq,服务A还要提供接口供服务C主动拉取
...全文
1144 6 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
6 条回复
切换为时间正序
请发表友善的回复…
发表回复
Linux技术狂 2021-07-20
  • 打赏
  • 举报
回复

1000+份计算机paper,卡耐基梅隆大学,芝加哥大学,facebook,google,微软,twitter等大牛一作,持续更新中...
地址链接

  • 打赏
  • 举报
回复
比如说我通过支付宝转账,结果支付宝告诉我转账失败,然后我查支付宝的交易明细——没有记录;我查支出方的银行卡,有支出记录;我查收入一方的银行卡,没有收入记录。由于用了那么多年支付宝,第一次遇到这个情况,我当时很担心!!!!!

然后过了10几个小时,支付宝跟银行对账了,我才发现支出方的银行卡上有退款记录了。而支付宝仍然是没有交易明细可查!

支付宝说这是“幂等的”。这算是事务吗?如果是事务那么我就不会担心了。但是正因为用幂等性这个借口来保证大公司的计算机系统的所谓“效率”,同时当然也是因为清算中心跟支付宝之间的合作问题的限制,所以牺牲了用户的体验。

这就不需要说是什么计算机概念“事务”。这只是业务流程而已。
  • 打赏
  • 举报
回复
引用 2 楼 Kingson_Wu 的回复:
[quote=引用 1 楼 yy1098029419 的回复:]
超时请求盲目重试会带来重复处理的隐患


接口参数和服务提供幂等性处理[/quote]

幂等处理本身就不是“事务”概念。那只能说明你这里也是标题党了。
  • 打赏
  • 举报
回复
你们的分布式“事务”的基本标准是什么?
Torreson 2018-07-10
  • 打赏
  • 举报
回复
引用 1 楼 yy1098029419 的回复:
超时请求盲目重试会带来重复处理的隐患


接口参数和服务提供幂等性处理
圆圆同学 2018-06-22
  • 打赏
  • 举报
回复
超时请求盲目重试会带来重复处理的隐患

1,233

社区成员

发帖
与我相关
我的任务
社区描述
企业软件 中间件技术
社区管理员
  • 中间件
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧