海门网站建设制作,网站虚拟主持人,山东省网站备案,湖北网站建设路在上一节中咱们已经把分布式事务问题交代了一遍，包括两大定理、五大解决方案和一个成熟的开源框架，而咱们最终的目标是用Spring Cloud实现一个实际创业项目的可靠消息最终一致性的分布式事务方案。 先交代一下项目背景。 前几年，社会上慢慢兴起一种称为C2C同城快递的业务，也… 在上一节中咱们已经把分布式事务问题交代了一遍，包括两大定理、五大解决方案和一个成熟的开源框架，而咱们最终的目标是用Spring Cloud实现一个实际创业项目的可靠消息最终一致性的分布式事务方案。 先交代一下项目背景。 前几年，社会上慢慢兴起一种称为C2C同城快递的业务，也就是俗称的跑腿闪送。比如我需要送个东西给某位朋友，而你刚好也去他那个地方，那就可以顺便可以帮我把东西带给他，也顺便挣点跑腿费，当时创业的时候做的就是这么一个简单的应用。其中有一个需求场景，就是用户可以通过钱包余额支付跑腿费。针对这一块，当时提出的要求是必须保证结算（也就是负责跑腿的用户可以提现）时是正确的，结算前允许出现短暂的不一致现象。 当时综合考虑过上一节所说的五大解决方案，比较来比较去，得出的结论是2PC/3PC相对来说延迟比较高，比较适合传统的单体应用，不适合高并发和高性能要求的场景；TCC最大的问题是对代码的侵入性太高，不适合作为通用解决方案；而且那时Seata尚未出现，Saga也没有合适的框架可以落地。只有基于MQ的方式既能满足弱一致性要求，而且还支持操作幂等，并且有对账/校验系统兜底，完全能够满足要求。因为是做自己的余额支付，所以也没必要做最大努力通知。因此，最终的技术选型是可靠消息最终一致性分布式事务解决方案。 这就是整个需求的背景说明。 之前的项目使用的是Springboot、MyBa
