搭建分布式数据库集群的时候，很多人都比较关心事务的问题。因为事务是数据库中非常核心的功能。

    在传统的集中式数据库架构中，事务的问题非常好解决，可以完全依赖数据库本身非常成熟的事务机制来保证。但是数据库作为分布式的架构之后，很多原来在单一数据库中所完成的事务现在需要跨多个数据库主机，这样原来的单机事务就需要引入分布式事务的概念。

    分布式事务本身是一个非常复杂的机制，不管是商业的大型数据库系统，还是各开源数据库系统。虽然大多数数据库厂家基本上都实现了这个功能，但或多或少地存在限制，而且存在一些Bug，可能造成某些事务不能很好的保证，或者是不能顺利地完成。

    这时候，就需要寻求其他的替代方案来解决这个问题，因为事务是不可忽视的，终究要实现的。就目前来说，主要存在的一些解决方案主要有以下三种。

    第一，进行scale out设计的时候合理设计切分规则，尽可能保证事务所需数据在同一个MySQL Server上，避免分布式事务。
如果可以，在设计数据切分规则的时候就做到所偶事务都能在单个MySQL Server完成，业务需求则比较容易实现，应用程序就可以做到通过最少的调整来满足架构的改动，使整体成本大大减少。因为数据库架构改造并不只是DBA的事情，还需要很多外围的配合与支持。即使是在设计一个全新系统的时候，同样要考虑到各个环境中各项工作的整体投入，既要考虑数据库本身的成本投入，同时也要考虑相应的开发代价。如果各环节之间出现“利益”冲突，就必须做出一个基于后续扩展及总体成本的权衡，寻找出一个最合适当前阶段的平衡点。

    不过，即使切分规则设计得再高明，也很难让所有的事务所需的数据都分布在同一个MySQL Server上。所以，虽然这种解决方案所需成本最小，但大多数时候只能兼顾大部分核心事务，也不是一个很完美的解决方案。

    第二，大事务切分成多个小事务，数据库保证各个小事务的完整性，应该控制各个小事务之间的整体事务完整性。

    和上一个方案相比，这个方案的应用改造更多，要求也更为苛刻。不仅需要分拆原来的很多大事务，同时还需要保证各个小事务之间的完整性。也就是说，应用程序需要具有一定的事务能力，这无疑会增加应用程序的技术难度。