柔性事务之前我们先来回归传统事务
传统事务
第一次接触事务的时候，被人告知事务是原子的，要么都成功要么都失败。再进一步就有ACID这四个属性，原子性（Atomictiy）、一致性（Consistency）、隔离性（Isolation）、持久性（Durabilit）。
我们首先看下一些书籍中的官方描述：
- 原子性：事务是一个包含一系列操作的原子操作。事务的原子性确保这些操作全部完成或者全部失败。
- 一致性：一旦事务的所有操作结束，事务就被提交。然后你的数据和资源将处于遵循业务规则的一直状态。
- 隔离性：因为同时在相同数据集上可能有许多事务处理，每个事务应该与其他事务隔离，避免数据破坏。
- 持久性：一旦事务完成，他的结果应该能够承受任何系统错误（想象一下在事务提交过程中机器的电源被切断的情况）。通常，事务的结果被写入持续性存储。
--《Spring攻略》
原子性：在一个事务李，动作序列的每一个步骤都必须是要么全部成功，要么所有的工作都将回滚。部分完成不是一个事务的概念。
一致性：在事务开始和完成的时候，系统的资源都必须处于一致的、没有被破坏的状态。
隔离性：一个事务，直到它被成功提交之后，它的结果对于任何其他的事务才是可见的。
持久性：一个已提交事务的任何结果都必须是永久性的，即“在任何系统崩溃的情况下都能保存下来”。
--《企业应用架构模式》
为什么列举的是这两本书中的描述呢，《spring攻略》是关于spring的书籍，因为我们都知道spring有很好的对事务支持的接口及组件，《企业应用架构模式》是我看过的较早的一本书籍，迄今还记得这本书中关于这四个属性的描述，同时这两本书的作者都是世界顶级的技术专家。（《企业应用架构模式》 和《重构-改善既有代码的设计》是同一位作者）
OK，那这四个属性，我们自己到底该如何理解呢。个人理解如下：
如果给事务下一个定义：事务是一个有边界的工作序列，开始和结束都有明确的定义。
- 原子性
举例1-比如现在有一个事务，包含3个sql语句（工作序列，或者是指令序列），sql-1，sql-2，sql-3，这3个sql语句，每一个在执行的时候，都是一个单元，这个单元的执行结果，有且仅有两种可能：成功和失败。
举例2-再比如，我从账户1中转出1000人民币到账户2，当我从账户1中把钱转出来之后，系统就崩溃了。那么系统应该将我的账户状态置成我还没有转出钱之前的状态。 - 一致性
举例1-有一个在线商务网站系统，有两张表，一张用户账户表（用户名、个人余额），一张商品库存表（商品ID，库存数量），用户花费30元购买1件商品，商品库存减1，账户余额减30.那么这样的结果就是一致的。否则，如果商品库存减1，账户余额没有变化，那么这样的结果就是不一致的。
举例2-银行账户转账的例子，也一样，账户1中的钱减少1000，账户2中的钱就增加1000，这样的是一致的，否则不一致。 - 隔离性
没有隔离性就没有一致性
举例1-我们现在有两个事务方法，一个方法是查询数据的库存，一个是购买下单，那么这两个事务方法应该互不影响，不然会造成一系列的问题，个人一直认为，事务造成的下面这些问题是跟并发密不可分的，没有并发操作，单一的请求事务是不会有这样的问题的。并发事务产生的问题可以分为4类
读脏数据
不可重复读
幻读
更新丢失
是不是跟并发导致的问题一直的呢。其实在《企业应用架构模式》一书中，有一句话描述就是：处理并发最主要的工具就是事务。 - 持久性
对于数据库来讲，我的理解是这样，当我把sql-1、sql-2、sql-3提交之后，这个结果就一定会保存到数据库中，那如果提交-到写入这中间，突然断电，也没有关系，数据库服务器在重新启动之后一样会把数据写入磁盘，应该是通过日志的方式-仅个人理解。
数据库一般都是通过事务日志的方式，write-ahead transaction log来保证持久性。write-ahead transaction log的意思是，事务中对数据库的改变在写入到数据库之前，首先写入到事务日志中。而事务日志是按照顺序排号的（LSN）。当数据库崩溃或者服务器断点时，重启动数据库，首先会检查日志顺序号，将本应对数据库做更改而未做的部分持久化到数据库，从而保证了持久性.
柔性事务
在电商领域等互联网场景下，传统的事务在数据库性能和处理能力上都暴露出了瓶颈。在分布式领域基于CAP理论以及BASE理论，有人就提出了 柔性事务 的概念。CAP（一致性、可用性、分区容忍性）理论大家都理解很多次了，这里不再叙述。说一下BASE理论，它是在CAP理论的基础之上的延伸。包括 基本可用（Basically Available）、柔性状态（Soft State）、最终一致性（Eventual Consistency）。
基本可用：分布式系统出现故障的时候，允许损失一部分可用性。比如，京东618大促的时候，对一些非核心链路的功能进行降级处理。
柔性状态：允许系统存在中间状态，这个中间状态又不会影响系统整体可用性。比如，数据库读写分离，写库同步到读库（主库同步到从库）会有一个延时，这样实际是一种柔性状态。
最终一致性：那上面数据库主从复制的例子，经过数据同步延时之后，最终数据能达到一致。
ACID是传统数据库常用的设计思想，它追求的是强一致性。BASE是大型分布式系统场景下的设计思想，通过牺牲强一致性获得高可用性。
柔性事务是在互联网的各种应用场景下产生的，互联网最核心的需求是什么？高可用。比如每年的京东618大促，交易高峰期间如果有10S不可用，那么损失的订单量大家可想而知。
老的方式实现分布式事务是通过两阶段提交来实现的。分为准备阶段和提交阶段。两阶段事务的关键是在准备阶段，在这个阶段所有参与者必须完成约束检查，达成关于分布式事务一致性的共识。第二阶段，根据之前达成的共识，完成相应的操作。提交事务的过程中需要在很多个资源节点之间进行协调，而且每个节点对锁资源的释放必须等到事务最终提交的时候。这样两阶段事务提交会耗费更长的时间。事务执行时间长意味着锁资源发生冲突的概率增加，当事务的并发量积累到一定数量的时候，很可能出现事务积压甚至出现死锁。系统的性能和吞吐量就会下降。
柔性事务针对分布式事务的解决方法：
1、记录日志+补偿
记录事务的开始和结束状态。事务根据日志记录找回事务的当前执行状态，并根据状态决定重试异常步骤，也就是正向补偿，或者回滚上一次执行步骤，也就是反向补偿。
2、消息
多次重试，也就是发送多次消息，由于要多次重发，所以程序必须是幂等（同一操作反复执行多次结果不变），这是非常具有互联网特征的一种模式。
3、“无锁”设计
放弃锁是一个解决问题的思路。比如通过乐观锁，大多数是基于版本号来实现。
update goods
set name=#{name},
remaining_number=#{remainingNumber},
version=version+1
where id=#{id} and version=#{version}
总结
从理念上梳理了传统事务和柔性事务。在现在的电商领域里绝大部分场景下，我们都不会使用两阶段提交这样低效的方式来实现分布式事务。我们都会采取上面柔性事务的方式来实现分布式事务来保证系统的性能和业务的最终一致。柔性事务的实现需要有下面2点作为保证：
1、应用程序一定要做幂等实现，特别是对数据库进行数据修改操作的时候。
2、远程模块之间采用异步消息驱动，异步消息还可以起到检查点的作用。
在支付宝架构与技术 中对柔性事务有大致的描述：
可以看出，柔性事务（遵循BASE理论）是指相对于ACID刚性事务而言的。
支付宝所说的柔性事务分为：两阶段型、补偿型、异步确保型、最大努力通知型几种。
由于支付宝整个架构是SOA架构，因此传统单机环境下数据库的ACID事务满足了分布式环境下的业务需要，以上几种事务类似就是针对分布式环境下业务需要设定的。
其中：
1、两阶段型：就是分布式事务两阶段提交，对应技术上的XA、JTA/JTS。
这是分布式环境下事务处理的典型模式。
2、补偿型：
TCC型事务（Try/Confirm/Cancel）可以归为补偿型。
补偿型的例子，在一个长事务（long-running）中，一个由两台服务器一起参与的事务，服务器A发起事务，服务器B参与事务，B的事务需要人工参与，所以处理时间可能很长。如果按照ACID的原则，要保持事务的隔离性、一致性，服务器A中发起的事务中使用到的事务资源将会被锁定，不允许其他应用访问到事务过程中的中间结果，直到整个事务被提交或者回滚。这就造成事务A中的资源被长时间锁定，系统的可用性将不可接受。
WS-BusinessActivity提供了一种基于补偿的long-running的事务处理模型。还是上面的例子，服务器A的事务如果执行顺利，那么事务A就先行提交，如果事务B也执行顺利，则事务B也提交，整个事务就算完成。但是如果事务B执行失败，事务B本身回滚，这时事务A已经被提交，所以需要执行一个补偿操作，将已经提交的事务A执行的操作作反操作，恢复到未执行前事务A的状态。这样的SAGA事务模型，是牺牲了一定的隔离性和一致性的，但是提高了long-running事务的可用性。
例子来源：OASIS的WS-BusinessActivity文档
3、异步确保型
将一些同步阻塞的事务操作变为异步的操作，避免对数据库事务的争用，典型例子是热点账户异步记账、批量记账的处理。
4、最大努力型
PPT中提到的例子交易的消息通知（例如商户交易结果通知重试、补单重试）
更详细的也可以参考OASIS的相关资料。
485
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
