基于SpringCloud的可靠消息最终一致性02:项目骨架代码(上)

在上一节中咱们已经把分布式事务问题交代了一遍,包括两大定理、五大解决方案和一个成熟的开源框架,而咱们最终的目标是用Spring Cloud实现一个实际创业项目的可靠消息最终一致性的分布式事务方案。

先交代一下项目背景。

前几年,社会上慢慢兴起一种称为C2C同城快递的业务,也就是俗称的跑腿闪送。比如我需要送个东西给某位朋友,而你刚好也去他那个地方,那就可以顺便可以帮我把东西带给他,也顺便挣点跑腿费,当时创业的时候做的就是这么一个简单的应用。其中有一个需求场景,就是用户可以通过钱包余额支付跑腿费。针对这一块,当时提出的要求是必须保证结算(也就是负责跑腿的用户可以提现)时是正确的,结算前允许出现短暂的不一致现象。

当时综合考虑过上一节所说的五大解决方案,比较来比较去,得出的结论是2PC/3PC相对来说延迟比较高,比较适合传统的单体应用,不适合高并发和高性能要求的场景;TCC最大的问题是对代码的侵入性太高,不适合作为通用解决方案;而且那时Seata尚未出现,Saga也没有合适的框架可以落地。只有基于MQ的方式既能满足弱一致性要求,而且还支持操作幂等,并且有对账/校验系统兜底,完全能够满足要求。因为是做自己的余额支付,所以也没必要做最大努力通知。因此,最终的技术选型是可靠消息最终一致性分布式事务解决方案。

这就是整个需求的背景说明。

之前的项目使用的是Springboo

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值