公司创立之初，一个web服务和一个数据库实例即可满足户需求。随着业务量的增长，性能问题就会越来越突出。架构于是变成了多个web服务，和一个读写分离的数据库群( 主多从)，这种架构或许也能 撑上千万的用户。但随着进一步发展，会发现业务复杂度越来越高 ，耦合也比较严重，而且数据库也成了性能瓶颈。这时就不得不面临分布式改造。将相关业务抽取成独 的服务和独立的数据库。数据量的业务还要进行分库分表的改造。这就是分布式系统架构。

 

在分布式系统架构中，就不得不面临分布式事务这一巨大挑战。 什么是分布式事务?通俗点说，就是一个大的操作，调用了多个分布在不同机器上的小的服务。事务要保证这些小的服务，要么全部执行成功，要么全部回滚。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

 

分布式系统的事务一致性本身就是一个让人头疼的难题，没有一个简单完美的解决方案能够适 于所有业务场景。在一致性，高性能和易用性方面 ，往往三者很难兼得。

 

首先，一致性，一个大的操作结束，保证所有小的操作数据协同一致。这里说的是一致指的是强一致性。目前大部分互联网公司的分布式事务解决方案，采用的是最终一致性。大都是通过结合消息中间件来实现。比如说，A、B在一个操作事务里，A调用成功后发送一个消息到消息队列，另一个消费任务负责消费消息，然后执行B操作。这里有个问题就是，消息可能被重复消费，所以B操作需要支持幂等性调用，消费任务会一直调用B，直到成功为止，必要时候还需要人工介入。不得不承认，最终一致性是因为解决不了高性能强一致的无奈之举。

 

其次，高性能。性能很差，自然就没有实用价值。业界也有像两步提交这样的解决方案，如XA。但是并没有什么知名互联网公司在使用 ，究其原因还是性能问题严重，多数企业无法接受。所以他们更愿意转而求其次，使用最终一致性解决方案，或者放弃事务人工订正。

 

最后，易用性。如果非要追求强一致性和高性能，就不得不进行特殊场景特殊处理。但通常会要求业务开发者遵守一定的规则，对业务侵入性很强，也带来了很大的开发成本。比如有的 案要求数据库操作必须写成存储过程，有的方案要求必须实现它的一堆接口，有的方案必须侵 入业务按照它的套路改造，等等。这都给产品开发、升级、运维带来困难。理想的方案是对业务无侵入，业务与事务分离，用户开发仅需要关注于业务本身，事务方面需要做的只是界定事务边界，事务一致性交给事务中间件处理。

 

看到这里，你肯定知道：什么是分布式事务，分布式事务为什么那么难解决。所以，如果初入职场者，面试中被问到分布式事务时，不用慌张，这本来就是个世界难题，答不上来也不必灰心，甚至你还可以反问面试官:你们是怎么解决的。