事务与柔性事务

如何保证事务一致性的问题，目前并没有完美的解决方案：

• 传统数据库的事务非常好的保证了业务的一致性，无论是单数据库的事务机制，还是分布式事务的两阶段提交机制，都在互联网场景下就暴露出数据库性能和处理能力上的瓶颈，效率不够搞。
• 采用CAP、BASE理论的柔性事务，在保证可用性、一致性的前提下，达成“最终一致性”。

CAP理论

• 一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。
• 一致性：所有节点在同一时间的数据完全一致。
• 可用性：用户在访问数据时可以得到及时的响应。
• 分区容错性：指分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。
• 强一致性的锁机制带来了数据层的性能瓶颈，可用性会严重影响用户体验，分区容错性影响系统的横向扩展能力。
• 实际上分区容错性是分布式系统的固有属性，所以基本上我们在设计分布式系统的时候只能二选一：要数据一致性（C）还是系统可用性（A）？
• 当集群中的节点数量持续增加时，一致性的成本非常高，所以很多时候只能选择可用性而放弃强一致性（当然提高可用性也意味着商业上少损失money）。Zookeeper、Hadoop之所以选择强一致性，是因为这些系统的节点相对来说还是少量。

BASE理论

• eBay架构师Dan Pritchett对于大规模分布式系统的实践总结：B（Basically Available）、S（Soft state）、E（Eventual Consistency）。
• 基本可用：指分布式系统在出现故障的时候，允许损失部分可用性，保证核心可用。
• 柔性状态：指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。比如，允许不同节点间副本同步的延时就是柔性状态的体现。
• 最终一致性：指系统中的所有副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。
• 互联网应用的最核心需求是高可用性，高可用性=分布式系统=高性能。

传统分布式事务机制：

• 两阶段提交：第一阶段是准备阶段，第二阶段是提交阶段，如果有任意一个参与者在第一阶段响应“未准备好”，则整个事务回滚；如果所有参与者在第一阶段都回答“就绪”，那这些资源就在第二阶段提交。
• X/Open组织为基于两阶段协议的分布式事务处理系统提出了标准的系统参考模型（X/Open事务模型）以及不同组件间与事务协调相关的接口，使不同厂商的产品能够互操作。

柔性事务如何解决分布式事务问题：

• 引入日志和补偿机制：通过日志来保证柔性事务的原子性，事务日志记录事务的开始、结束状态，可能还包括事务参与者信息，参与者节点也需要根据重做或回滚需求记录REDO/UNDO日志，当事务重试、回滚时，可以根据这些日志最终将数据恢复到一致状态。在互联网业界采用日志方式实现柔性事务的比例非常大，但因为这部分技术的实现并没有如XA这样的技术标准和规范，很多应用对这部分的实现非常的粗糙。
• 可靠消息传递：由于“网络通信危险期”的存在，消息投递只有两种模式：1）消息仅投递一次，但是可能会没有收到；2）消息至少收到一次，但可能会投递多次。在业务一致性的要求下，只能选择第二种投递方式，由于可能重复投递这就要求消息处理程序必须实现幂等（即同一操作反复执行多次结果不变），这一要求跟传统应用开发相比是非常具有互联网特征的一种模式。幂等的实现方法--也是eBay给的一个简单思路，根据msg_id在目标端是否存在来判断是已经处理过。
• 实现无锁：1）避免事务进入回滚，由于事务不会回滚也不会导致脏读；2）辅助业务变化明细表，比如对资金或库存进行增减处理时，可采用记录这些变化的明细表的方式，避免所有事务均对同一数据表进行更新操作，造成数据访问热点，同时使得不同事务中处理的数据互不干扰，实现对资金或库存信息处理的隔离；3）乐观锁，比如通过在资金表中增加版本号，在事务开始前获取版本号，在事务开始后对资金进行数据更新时可通过在执行最后的修改update语句时进行之前获取版本号的比对，如果版本号一致则更新否则放弃当前事务。