如何提高分布式事务性能
这两年来，随着NoSQL系统、CAP理论和Eventual Consistency的大热，关于分布式操作要保证强一致还是弱一致性的讨论络驿不绝。双方各执一词，倾向实现强一致性的一方认为弱一致性满足不了应用开发的需要，倾向实现弱一致性的一方则认为保证强一致性将导致系统性能与可伸缩性难以接受。弱一致性能否满足应用开发的需求这一点由应用特征决定，难以一概而论，但强一致性对系统性能、可伸缩性和可用性的影响则是可以作技术分析的。奇怪的是，找了很久，也没找到对这一问题的深入分析，决定自己来做一个。
对于分布式操作，一般来说有以下两种实现选择：
1、 在每个节点上使用单独的事务，只实现弱一致性。
2、 使用2PC保证强一致性。即分布式事务协调者先要求所有参与节点PREPARE，大家都说PREPARE成功后，再要求所有节点COMMIT。只要有一个节点PREPARE不成功，大家都要回滚。这样参与者要强制写两次日志，协调者在决定要COMMIT时也要强制写一次日志。
首先，假设用户发起分布式操作的速率为TpS（Transactions per Second），每个分布式操作平均会操作K个节点。在每个节点上，平均要操作RpT（Rows per Transaction）条记录，而操作每条记录平均要用时TpR（Time per Row），这样在每个节点上事务操作的执行时间为：
TExec=RpT×TpR
另外，设定以下参数：
- N：数据库中所有节点上的总记录数
- TCommit：在每个节点上PREPARE或COMMIT的时间，PREPARE和COMMIT的主要工作都是写相应的日志，执行时间接近
对分布式操作性能方面一种常见的认识是若使用2PC，将导致事务执行时间大为延长，从而导致过高的事务并发冲突和死锁。当然，从趋势上使用2PC自然会导致并发冲突和死锁增长，但是否能满足应用需求，需要定量的来分析。由于死锁的概率完全取决于冲突概率，以下只分析冲突概率。
对选择1，即每个节点用独立事务时，用户发起的每个事务都会被分成K个小事务，这时系统中的并发事务数是事务速率与事务持续时间之积，即：
CT_1=TpS×K×(RpT×TpR+TCommit)
当某事务要锁定并操作某条记录时，系统中被其它事务所锁定的记录数是(CT_1-1)×RpT≈CT_1×RpT。假设事务操作的记录是纯随机的，则该事务要锁定的记录与其它事务冲突的概率是(CT_1×RpT)/N。而这个事务总共要锁定RpT条记录，则该事务与其它事务冲突的概率是：
TWait_1=1-(1-(CT_1×RpT)/N )^RpT≈CT_1×RpT^2/N
对选择2，即使用2PC保证强一致性时，每个节点上需要强制写两次日志，在事务协调者上还要强制写一次PREPARE日志（事务协调者上的COMMIT日志不需要强制写，这一时间可以忽略）。系统中的并发事务数是：
CT_2=TpS×((RpT×TpR+2×TCommit)×K+TCommit)
但此时系统中被其它事务所锁定的记录数是选择1的K倍，且事务要锁定的记录数也是选择1的K倍，这时事务的冲突概率是：
TWait_2≈CT_2×RpT^2×K^2/N
这个公式比较复杂，我们先简化一下，假设TCommit和TPrepare时间相对于TExec来说可以忽略，则可以得到有：
TWait_2=TWait_1×K^2
也就是说事务冲突的概率将会随着分布式操作涉及的节点数K的平方数增长。平方数增长听起来比较厉害，但实际上在真实应用中K通常是很小的，绝大多数情况下等于2。如经典的转账问题，就只涉及两个节点，还有比如建立好友关系时也只涉及两个节点。在使用我们分布式数据库的大量应用中（总共包含约500张表，上千个索引，几千种SQL模式），绝大多数情况下K为2，很少有3，超过3的更是绝无仅有。因此，如果我们忽略2PC PREPARE和提交的时间，则使用2PC时会导致事务冲突概率4~9倍的增长。
换一种情况，如果执行很快但提交写日志很慢，即TExec相对于TCommit来说可以忽略，则可以得到：
TWait_2=TWait_1×(2×K+1)/K×K^2
这时的情况比只考虑执行时间时差一些，但还是随着分布式操作涉及的节点数K的平方数增长，只不过从4~9倍变成10~21倍。
真实的情况一般在这两者之间，作为估算，可以大致认为采用2PC保证强一致性时将导致事务冲突概率增加8倍左右。
性能方面还涉及到吞吐率和响应时间。类似的进行分析，可以发现如果TCommit相对于TExec可以忽略，则响应时间不受2PC影响，反之，则2PC会导致响应时间增加为原来的3倍，平均的估计可以取增加1倍。对大多数应用，日志提交的吞吐率完全足够，则事务吞吐率不受2PC影响，反之，事务吞吐率会下降一半。
对大多数WEB应用冲突概率非常低，分布式操作只涉及2~3个节点，日志提交的吞吐率完全足够，则使用2PC可能带来的影响是事务冲突与死锁增加8倍左右，响应时间延长1倍，吞吐率不受影响。这些性能影响应该说是完全可以接受的，此时2PC带来的强一致性优点可以说远远超过其对性能的影响。
当然，以上分析中忽略了很多因素，比如网络延时，比如客户端在发起事务的多个操作之间还可能休息一会。加入这些因素后的性能分析会更复杂，但这些因素，本质上是使事务的持续时间增加，跟是否使用2PC无关。使用2PC与不使用2PC之间的性能差异比例，与这些因素关系不大。
但有一个问题需要注意。如果让客户端直接充当分布式事务的协调者，由于客户端上通常不像数据库服务器那样配置带电池的写缓存，fsync的性能很差，2PC将导致简单分布式事务的响应时间增加一个数量级，冲突概率更是可能增加两个数量级，事务提交的吞吐率也可能受到影响。解决方法是部署专职的高性能分布式事务协调者集群，配置高性能的日志存储设备如SSD。
基于这一基本的性能分析，还有一些变种：
1、如果分布式操作在各节点上并行执行，可以计算出冲突概率将是不并行的1/K。这仍比不用2PC串行高K倍，但不再是K的平方倍。比如BigTable中对二级索引和主记录的修改，就可以并行。
2、如果分布式操作是否冲突只取决于其中一个节点，可以计算出2PC并不会导致冲突概率显著增加。符合这一特征的应用模式还是BigTable中对主记录及其所有二级索引的修改，冲不冲突，完全取决于是否更新同一条记录，跟索引无关。
根据这两点也可以看出，如果用并行的2PC来保证主记录及其二级索引之间的一致性，其所带来的性能影响弱于2PC对一般分布式事务的影响，是完全可以实用的方案。
对使用2PC分布式事务的另外一个比较大的担心是如果2PC在PREPARE之后事务协调者崩溃，则参与分布式事务的各个节点只能长时间的锁定资源，等待协调者复活后告诉它事务应该提交还是回滚。如果直接让客户端直接充当分布式事务的协调者，这一问题可能很严重，因为客户端多而杂，崩溃概率高。但如果部署了专职的高性能分布式事务协调者集群，则这一问题基本可以避免。
分布式事务
1、两阶段提交协议
分为两个阶段：一个准备阶段 ，一个提交阶段。基于两阶段协议，事务管理器能够最大限度地保证跨数据库操作的事务原子性，是分布式系统环境下最严格的事务实现方法。但是两阶段协议存在性能方面问题，难于进行水平伸缩，因为在提交事务过程中，事务管理器需要每个参与者进行准备和提交的操作协调，在准备阶段锁定资源，在提交阶段消费资源。由于参与者众多，锁定资源和消费资源之间的时间差被拉长，导致响应速度较慢，产生死锁或不确定结果的可能性较大。在互联网很少使用两阶段提交协议。
两阶段提交协议是阻塞协议，在极端情况下不能快速响应请求方，因此提出了三阶段提交协议，解决了两阶段提交协议的阻塞问题，但仍然需要事务管理器在参与者之间协调，才能完成一个分布式事务。
2、最大努力保证模式
这是一种非常通用的保证分布式一致性的模式，很多开发人员一直在使用，但是未认识到这是一种模式，最大努力保证模式适用于对一致性要求并不十分严格但是对性能要求较高的场景。
具体的实现方式是：在更新多个资源时，将多个资源的提交尽量延后到最后一刻处理，如果业务流程出现问题，则所有的资源更新都可以回滚，事务仍然保持一致。唯一可能出现问题的是在提交多个资源时发生了系统问题，比如网络问题等。但是这种情况是非常罕见的，一旦出现这种情况，就需要进行实时补偿，将已提交的事务进行回滚。 当然在使用这种模式时，我们要考虑每个资源的提交顺序。我们在生产实践中遇到的一种反模式，就是在数据库事务中嵌套远程调用，而且远程调用的是耗时任务，导致数据库事务被拉长，最后拖垮数据库。
3、事务补偿机制
在对性能要求很高的场景中，两阶段提交协议不是一种好方案，最大努力保证模式也会使多个分布式操作相互嵌套，有可能相互影响。这里我们给出事务补偿机制，其性能很高，并且能尽最大可能地保证事务的一致性。
在数据库分库分表后，如果涉及的多个更新操作在某一个数据库范围内完成，则可以使用数据库内的本地事务保证一致性。对于跨库的多个操作，可通过补偿和重试，使其在一定的时间窗口内完成操作，这样就可以实现事务的最终一致性，突破事务遇到问题就回滚的传统思路。 如果采用事务补偿机制，则在遇到问题时，需要记录遇到问题的环境、信息、步骤、状态等，后续通过重试机制使其达到最终一致性。
