基于SpringCloud的可靠消息最终一致性02：项目骨架代码（上）

湘王AI

于 2023-02-26 09:00:00 发布

阅读量569

点赞数

CC 4.0 BY-SA版权

分类专栏： CTO的几把刷子文章标签：分布式事务 Spring Cloud 可靠消息最终一致性项目骨架代码 Java

本文链接：https://blog.youkuaiyun.com/lostrex/article/details/129179499

CTO的几把刷子专栏收录该内容

28 篇文章 ¥69.90 ¥99.00

订阅专栏

超级会员免费看

本文介绍了基于Spring Cloud的可靠消息最终一致性分布式事务解决方案在C2C同城快递业务中的应用。通过项目背景和选择该方案的原因，展示了在Spring Cloud Alibaba环境下，如何构建项目骨架代码，包括数据准备、服务停止与恢复后的数据一致性验证。演示了服务启动后，MQ消息的消费过程，以及在数据暂时不一致情况下如何达到最终一致。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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

先交代一下项目背景。

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

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

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

之前的项目使