随着业务需求的复杂化，企业应用规模不断扩大，在后端开发中经常会遇到以下问题：

  • 业务的并发要求非常高，对应的业务需要通过微服务拆分，甚至分库分表等架构设计才能满足并发需求，此时业务操作无法在同一个数据库中通过本身的事务来实现

  • 资源的分布问题（比较常见），有的业务资源是部门A负责的，有的业务资源是部门B负责的，这样的情况下怎么实现一个事务？

  • 大时间跨度的问题，完成一个事务需要很长很长时间，这种情况怎么处理？

在这种情况下，分布式事务应运而生，成为上述问题的最优解。但许多初学分布式事务的朋友经常遇到这些问题：

学习分布式事务时，有多种分布式事务实现方案，不知学习重点在哪

基于不同业务开发场景，无法做出合适的技术选型

引入分布式事务后，团队过度设计，让人疲惫不堪

项目中集成了 Seata ，不同业务场景，没有选择合适的事务模型，性能差强人意