避不开的分布式事务

前言

关于前面系列的文章已经说到分布式服务之间的通信，则分布式事务接下来就是我们要一起学习的主题，走起。

数据库事务在现有大大小小的系统中几乎是避免不开的，或多或少总会有一些业务关联在一块；对于单机事务的应用场景和操作，相信小伙伴已经够熟练了；随着分布式、微服务的开发模式普及，分布式事务落地也成为了程序员的必备之技，接下来的几篇一起来学习和实操。

正文

1. 事务回顾

1. 1 事务简介

通俗一点理解就是将一组对数据的操作(增、删、改、查)看做成一个逻辑单元，要么都执行，要么都不执行，确保数据一致性。

1.2 事务特性(ACID)

• 原子性（Atomicity）

  指事务内所有操作要么一起执行成功，要么都一起失败(或者说是回滚)；如事务经典转账案例：A给B转账，A把钱扣了，但B没有收到；可见这种错误是不能接受的，最终会回滚，这也是原子性的重要性。

• 一致性（Consistency）

  指事务执行前后的状态一致，如事务经典转账案例：A给B互相转账，不管怎么转，最终两者钱的总和还是不变；

• 持久性（Durability）

  指事务一旦提交，数据就已经永久保存了，不能再回滚；

• 隔离性（Isolation）

  指多个并发事务之间的操作互不干扰，但是事务的并发可能会导致数据脏读、不可重复读、幻读问题，根据业务情况，采用事务隔离级别进行对应数据读问题处理。

1.3 事务隔离级别

• 读未提交(Read uncommitted)

  指一个事务读取到其他未提交事务的数据。可能导致数据脏读。

  转账案例：A正在给B转账，本来转的1000，A多输入了个0，变成10000，但此事务还未提交，但此时B查询到转入的是10000，但A取消事务回滚之后，B又查询不到转入的数据。这种情况就是脏读

• 读已提交(Read committed)

  指一个事务只能读取到其他事务已提交的数据，从而解决了脏读的问题。但可能导致数据不可重复读；

  转账案例：A要给B转账1000，A先查看了一下余额，有1000，然后开始给B转钱，但此时A家里电费通过开启的自动缴费功能，自动从A账户扣除200缴纳电费，并提交；当A转账准备提交，再次确认余额时，钱少了200。这样就导致同一个事务中多次查询的结果不一致，这种情况就是不可重复读；

• 可重复读(Repeatable read)

  指事务只要一开启，就不允许其他事务进行修改操作，从而解决了不可重复读问题。但可能导致数据幻读；

  转账案例：A经常给B转账，到年底了，需要查账，然后开启了一个事务进行查询统计，刚开始查询只是10条转账记录，正准备统计时，因为紧急情况A需要给B转一笔钱应急，从而新增了一条新记录，并提交；而查账事务正在统计中，最后发现转账额和看到的10条转账记录不匹配。这种情况就是幻读

• 序列化(Serializable )

  指事务之间只能串行话执行，就像队列一样，排队进行，这样就解决了幻读的问题，但是这种级别的并发性能不高，非特殊需求，这种级别一般不用。

2. 分布式事务场景

一个项目对应一个数据库，这种单机业务是平时处理的比较多的；这里主要归纳一下会出现分布式事务的场景。

2.1 一个项目多个数据库

这种情况一般是并发量不大，但数据量比较大的情况，就比如一些采集设备数据做实时分析的系统，如传感器数据、电机状态等，经过一段时间，数据量会很多，导致单个数据库效率变低，所以通常会采用分业务存储。

如上图，如果出现需要操作DB1中数据的同时又需要操作DB2数据，确保两次操作要么都成功，要么都失败，这就需要事务，而这种和单一系统(一个项目，一个数据库)的事务处理方式不一样，得分布式事务进行处理。

2.2 多个项目一个数据库

有些系统需要将业务分开开发和部署，便于代码管理和后期维护，在数据库资源允许的情况下可以共用一个数据库，在这种情况下如果有事务操作，同样需要分布式事务进行处理。

2.3 多个项目多个数据库

这种方式其实就是微服务模式，分业务划分项目，每个业务对应一个数据库，这种场景下项目之间的事务肯定是分布式的啦

3. CAP了解

3.1 简介

对于分布式应用场景，有很多因素是不可控的，如网络不通、设备宕机、自然灾害等原因导致服务不可用，这种情况对于分布式而言需要有一定的取舍，不能因为个别服务的不可用，导致整个系统崩掉。通常CAP理论会成为分布式指标的取舍，根据系统业务需求，满足其中两个指标即可。如下图：

CAP是Consistency(一致性)、Availability(可用性)、PartitionTolerance(分区容错性)三个词的缩写，具体含义如下：

• C(Consistency-一致性)：是指在写操作之后，任意节点进行读取时，都能一致获取到最新的数据状态。为了保证数据一致性，在同步数据时会就资源短时进行锁定，目的为了避免获取的老的数据，导致数据不一致情况，但这样就会导致服务在短时间内不可用。
• A(Availability-可用性)：是指发起任何操作时都可以得到响应结果，不会出现响应超时或响应错误。就算是数据在同步过程中也要保证可用，即宁可拿到旧数据也不要报错。
• P(PartitionTolerance-分区容错性)：这里的分区是指网络分区，通常分布式系统，各节点会部署到不同子网，由于网络具有不可控性，可能会导致节点之间的通信失败；但在设计此类系统时，应该考虑这种情况，保证提供正常的服务，这其实可以理解为平时咱们说的高可用；这个指标是分布式系统必备的，不然就不能叫高可用系统啦。

3.2 CAP组合

其实通过上面的概述，C(一致性)和A(可用性)是互相排斥的，为了保证一致性，会锁定资源导致短时间不可用，而可用性的要求就是必须对操作有对应的响应结果，就算得到的数据不是最新的也行，目的是保证可用。而P(分区容错性)是分布式系统中必备指标，所以在分布式系统中经常的组合就是CP和AP。

• CP：放弃可用性，注重一致性和分区容错性，其实这就是所谓的强一致性，可能在银行跨行转账这种强一致业务场景才会用到，具体得根据业务场景做取舍。
• AP：放弃强一致性，注重可用性和分区容错性，这是现在绝大多数分布式业务场景的选择，只要最后能保证最终一致性(Base理论)即可。

3.3 简单理解一下BASE理论

BASE是Basically Available(基本可用)，Soft State（软状态）和Eventually Consistent（最终一致性）三个短语的缩写，是对AP的一种扩展，即当出现故障时允许部分服务不可用，但要保证核心服务正常。对于数据，允许一定时间内不一致，通过中间状态(软状态)过渡，最后保证最终一致即可。

举例说明：

Basically Available(基本可用)：比如一个系统注册用户成功时需要发送信息通知，允许发送信息不成功，但注册这个核心功能要保证可用。

Soft State（软状态）：平时见得最多的软状态有：“支付中”、“数据处理中”等，这些状态是为了满足可用性和最终一致增加的过渡状态。

Eventually Consistent（最终一致性）：比如在购买商品时，支付的过程中会显示“支付中”，最终会显示“支付成功”，这个时候其实就保证最终你的账户和收款账户这个事务最终一致了，这种事务可以理解为“柔性事务”。

4. 分布式事务常用的解决方案

• 2PC（Two-phase commit protocol），又称二阶段提交，是一种强一致性解决方案。对其进行补充的还有一个叫3PC的解决方案。
• TCC（Try Confirm Cancel），补偿事务。
• 本地消息表
• 消息事务
• 最大努力通知

这里先不细说，后续逐个击破，最终还是要用代码落地。

总结

这篇只是一个开端，主要是大概回顾一下分布式事务中常遇到的知识点，后续主要是针对各个解决方案的落地，一起撸码。

一个被程序搞丑的帅小伙，关注"Code综艺圈"，和我一起学~~~