支付宝蚂蚁金服——基于

xa 协议在架构上与 tcc 模型相比，比较大的不同是 xa 直接作用于资源层，而后者作用于服务层。

资源层更普适，但是为了适应各种业务场景使用，需要严格遵循事务 acid 规范；服务层更接近业务，可以针对不同业务做特定的优化处理，追求更高的极限性能。

当然，并不是说 xa 协议只能作用于单个服务内部的多资源场景，跨服务的多资源场景也是可以的，只不过同样需要额外的事务传递机制。

xa 协议通过每个资源管理器（resource manager）的本地事务隔离性来保证全局隔离，并且需要通过串行化隔离级别来保证分布式事务一致性。但是，串行化隔离级别存在一定的性能问题，如下所示：

在串行化隔离级别下，会为本来不加锁的 select 快照读操作都加上读锁，导致锁持有时间增加，并发性能进一步降低。当实现了无锁的全局一致性读取以后，比如分布式 mvcc，可以大幅减少锁持有时间，并发性能会获得较大提升。

但是不管怎么优化实现，分布式事务的热点数据并发性能比较高就是趋近于单机本地事务。所以，无论是基于 xa 协议实现的分布式事务，还是单机本地事务，都是存在热点数据并发性能极限的。

那么 xa 协议比较大的作用是什么呢？其比较大的作用在于数据库资源横向扩展时，能保证多资源访问的事务属性。

当单台资源管理器达到资源性能瓶颈，无法满足业务增长需求时，就需要横向扩展资源，形成资源管理器集群。通过横向扩展资源，提升非热点数据的并发性能，这对于大体量的互联网产品来说，是至关重要的。

以上图为例，假设单台资源管理器的非热点数据并发性能为 100 tps，那么 5台资源管理器就是 500 tps，就算一个分布式事务平均涉及 2 台资源管理器，也有 250 tps，提升了 2.5 倍的非热点并发能力。

综上所述，基于 xa 协议实现的分布式事务并不能提升热点并发性能，其意义在于横向扩展资源提升非热点数据并发性能时，能严格保证对多资源访问时的事务 acid 特性。

至于热点数据并发性能问题，对于一般的应用来说，经过 sql 层面一定的性能优化之后，其并发性能基本就能够满足业务的需求。如果经过优化，达到性能极限之后，还不能满足业务需求，就需要上升到业务层面，根据业务特点，通过专门的业务逻辑或业务架构优化来实现。

直接在资源层实现分布式事务的另外一点好处是其普适性，可以对上层业务屏蔽底层实现细节。这一点在云服务时代特别有用，云服务面对的是大量的中小企业，甚至是个人开发者，业务诉求不尽相同，普适、标准的分布式事务产品是非常有必要的，可以让开发者从底层技术细节中脱离出来，更专注于业务逻辑的实现，从而获得更高效、快速的业务发展。

若有收获，就赏束稻谷吧