作者：山猎，阿里云解决方案架构师
https://mp.weixin.qq.com/s/XA-CsdBxgbXdsIjKOdyoGQ
最近看到一篇分布式事务解决方案文章
柔性事务，要求最终一致性，允许中间状态短期不一致。相对于强一致性事务（刚性事务）而言，它锁定的资源范围小，阻塞性弱，更为高效。
柔性事务有多种实现方式，包括TCC、Saga、事务消息、最大努力通知等，本文将重点介绍通过事务消息实现柔性事务。
以下为部分正文
前言
在电商领域，抢购和秒杀是非常普遍业务模式，抢购类业务在快速拉升用户流量并为消息者带来实惠的同时，也给电商系统带来了巨大考验。在高并发、大流量的冲击下，系统的性能和稳定性至关重要，任何一个环节出现故障，都会影响整体的购物体验，甚至造成电商系统的大面积崩溃。和电商领域抢购场景极为类似的业务模式还有很多，比如大型赛事和在线教育的报名系统，以及各类购票系统等。
针对抢购类业务在技术上带来的挑战，业界有一系列解决方案，通过不同维度来提升系统的性能与稳定性，包括动静分离、定时上架、异步处理、令牌队列、多级缓存、作弊行为侦测、流量防护、全链路压测等。
本文重点聚焦在如何确保抢购类业务的一致性上，分布式事务一直是IT界老大难的问题，而抢购业务所具备的高并发、大流量特征，更是成倍增加了分布式一致性的实现难度。以下将介绍如何通过事务消息构建满足抢购类业务要求的高性能高可用分布式一致性机制。
事务一致性原理回顾
事务是应用程序中一系列严密的操作，这一系列操作是一个不可分割的工作单位，它们要么全部执行成功，要么一个都不做。事务具有四个特征：原子性（ Atomicity ）、一致性（ Consistency ）、隔离性（ Isolation ）和持续性（ Durability ），这四个特性简称为 ACID 特性。
在非并发状态下，保证事务的 ACID 特性是轻而易举的事情，如果某一个操作执行不成功，把前面的操作全部回滚就 OK 了。而在并发状态下，由于有多个事务同时操作同一个资源，对于事务 ACID 特性的保证就会困难一些，如果考虑得不周全，就会遇到如下几个问题：
脏读：事务 A 读到了事务 B 还没有提交的数据。
不可重复读：在一个事务里面对某个数据读取了两次，读出来的数据不一致。
幻读：在一个事务对某个数据集用同样的方式读取了两次，数据集的条目数量不一致。
为了应对上述并发情况下出现的问题，就需要通过一定的事务隔离级别来解决。当事务的隔离级别越高的时候，上述问题发生的机会就越小，但是性能消耗也会越大。所以在实际生产过程中，要根据实际需求去确定隔离级别：
- READ_UNCOMMITTED（读未提交）：最低的隔离级别，可以读到未提交的数据，无法解决脏读、不可重复读、幻读中的任何一种。
- READ_COMMITED （读已提交）：能够防止脏读，但是无法解决不可重复读和幻读的问题。
- REPEATABLE_READ （重复读取）：对同一条数据的多次重复读取能保持一致，解决了脏读、不可重复读的问题，但是幻读的问题还是无法解决。
- SERLALIZABLE （ 串行化）：最高的事务隔离级别，避免了事务的并行执行，解决了脏读、不可重复读和幻读的问题，但性能最低。
关系型数据库提供了对于事务的支持，能够通过不同隔离级别的设置，确保并发状态下事务的ACID特性。但关系型数据库提供的能力是基于单机事务的，一旦遇到分布式事务场景，就需要通过更多其他技术手段来解决问题。
抢购业务中的分布式事务
有如下三种情况可能会产生分布式事务：
1、一个事务操作包含对两个数据库的操作：数据库所提供的事务保证仅能局限在对于自身的操作上，无法跨越到其他数据库。
2、一个事务包含对多个数据分片的操作：具体的分片规则由分库分表中间件或者分库分表 SDK 来实现，有可能跨越多个数据库或同一个数据库的多个表。对于业务逻辑而言，底层的数据分片情况是不透明的，因此也没有办法依赖于数据库提供的单机事务机制。
3、一个事务包括对多个服务的调用：在微服务领域，这是极为常见的场景，不同的服务使用不同的数据资源，甚至涉及到更为复杂的调用链路。在这种情况下，数据库提供的单机事务机制，仅仅能保证其中单一环节的 ACID 特性，没有办法延伸到全局。
微服务技术在电商领域的普及程度是非常高的，比较大型的电商应用还会通过中台思想将共性业务能力进行沉淀，因此抢购业务中的很多环境都属于跨服务的分布式调用，会涉及到上述第三种分布式事务形态。比如在订单支付成功后，交易中心会调用订单中心的服务把订单状态更新，并调用物流中心的服务通知商品发货，同时还要调用积分中心的服务为用户增加相应的积分。如何保障分布式事务一致性，成为了确保抢购业务稳定运行的核心诉求之一。
