请围绕 “论分布式事务及其解决方案” 论题，依次从以下三个方面进行论述。
1、概要叙述你参与分析设计的软件项目以及你在其中所承担的主要工作。
2、请介绍4种分布式事务的解决方案及简单说明。
3、具体阐述你参与的软件项目是如何做到分布式事务的，过程中遇到哪些问题，是如何解决的。
一、摘要
2024年06月，我作为系统架构设计师主导我司艺术品电商平台升级改造工作，目标是实现一个可支持百万级用户规模的艺术品在线消费平台，保障高并发场景下系统稳定性与交易数据一致性。平台集成在线交易、权益兑换及仓储物流管理，形成完整业务闭环，推动艺术价值与艺术消费生态建设。
本文基于艺术品电商平台实践，总结出tcc分布式事务技术演化应用方案。针对跨服务交易场景中的库存扣减、积分冻结、支付结算等业务的原子性、一致性难题，通过实现try逻辑、confirm逻辑、cancel逻辑，结合事务状态跟踪器与补偿调度器，构建标准化事务执行引擎。测试显示，日平均处理3万笔交易时系统链路响应稳定在300ms内，事务成功率与回滚效率分别达99.8%和100%。
该方案的成功实施，有效解决了我司艺术品电商平台在高并发交易场景下的数据一致性问题，为我司同类电商系统研发提供了可复用的架构范式和技术基准。
二、正文
我司艺术品电商务平台致力于构建支撑百万级用户规模场景的高性能艺术消费生态，核心服务于c端用户在线购买艺术品、积分权益兑换及会员身份管理三大业务闭环。平台集成了商品管理、库存服务、支付中心、积分系统、物流调度等六十多个微服务模块，通过全链路安全保障体系实现交易全流程可追溯。随着工美艺术品流通需求激增，平台日均交易量突破5w单，峰值达15w单，用户规模以季度15%的增速突破七百万规模量级，业务扩张倒逼系统架构持续升级。
该平台早期技术栈采用简单微服务架构，各服务如订单、库存、积分、仓储均采用独立部署模式，通过spring框架的@transactional注解实现本地数据库事务管理。例如：订单服务在修改订单状态时，通过注解的事务传播特性确保其mysql数据库的acid特性，但库存、积分等服务的数据库完全独立，缺乏跨服务事务协调机制。当用户支付成功后，订单服务本地事务提交，若后续库存服务因库存不足导致扣减失败，由于没有全局事务管理器或补偿机制，已持久化的"已支付"订单状态无法回滚，形成"支付成功但库存未扣减"的业务矛盾。这种架构过度依赖数据库行锁/表锁的本地锁机制，在跨服务调用链路上无法实现分布式事务的原子性，即要么所有服
本篇完！