分布式事务总结

1. 分布式事务产生的背景

1.1 数据库水平拆分

对于大部分的业务而言，在起步阶段，为了快速上线，一般都是单库单表的。但是随着业务的扩张，数据量也随着扩增，单库的性能逐渐变差，就会有数据库的单点压力。因此我们就需要考虑数据库的分库分表方案了。分库分表的目的在于减少单库的负担，提高读写性能。策略可以归纳为拆表和拆分库，拆表是把表的字段进行拆分，即一张表拆分为多张表，这样就使得单表的行数降低，提升查询效率。但是单纯的库内分表只解决了单表的数据过大的问题，并不能解决在同一数据库服务器上的硬件瓶颈，因此需要同时考虑拆库，将原来的单库单表进行拆分数据片，如下图所示：

分库分表之后，原来在一个数据库上就能完成的写操作，可能就会跨多个数据库，这就产生了跨数据库事务问题。

1.2 SOA微服务化

随着业务以及技术的演进，单体架构的瓶颈也越来越明显。按照面向服务的架构（SOA）的原则，我们需要一个既能解决业务之间耦合性，又具备高可用、可伸缩的需求越来越强烈。在将单体架构，拆分为多个业务服务之后，每块业务只需要关注自己的服务即可，形成了一种高内聚、低耦合的架构设计方案，此时简易系统架构图如下：

业务系统按照服务拆分之后，一个完整的业务往往需要调用多个服务，此时，不可避免地会产生数据不一致的问题。由于涉及到多个服务以及多个数据库，本地事务肯定无法满足需求，因此分布式事务就登上了舞台。简单一句话概括分布式事务：为了保证不同服务、不同数据库的数据一致性的事务解决方案。

2. CAP原则

在计算机科学理论中，CAP定理指出，在一个分布式系统中，不可能同时满足以下三点，最多满足两个：

• 一致性（Consistence），所有节点每次读写都能保证获取最新数据，即分布式系统内所有节点的数据副本保持强一致性；
• 可用性（Availability），每次请求数据都能得到响应，但不一定是最新的数据，无论任何故障产生后，需要保证服务仍然可用；
• 分区容错性（Partition Tolerance），被分区的节点可以正常对外提供服务；