分布式系统一致性保障方案1.docx

PAGE 13 分布式系统一致性保障方案 引言 在互联网系统中，理想的情况下，肯定是希望系统能够同时满足“一致性”、“可用性”和“分区容忍性”。 但是基于熟悉的CAP定律也好，还是BASE理论， 我们知道，在实际情况中是不可能实现的。而在金融领域，一致性是最为关注的特性，任何情况下都必须满足一致性。关于CAP定律和BASE理论，本文不再介绍，有兴趣的同学可以自行百度一下。本文重点来阐述下关于一致性的方案，包括强一致性和最终一致性。 而在互联网领域， 很多情况下都是牺牲强一致性，来达到高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。  数据库本地事务  数据库事务肯定是强一致性的方案，而且是一致性最简单的方案，因为一致性是数据库的事务来保证的，业务层不需要关心细节。比较典型的应用是在返现场景下，针对带有返现的交易的退款，需要一次性退两笔交易单，采用的就是通过数据库本地事务来完成的。具体如下： 用户A花了100元购买商户B的商品，购买结束后返现给用户A 2元。 这是两笔交易，原始交易是100元，返现交易是2元。 那么发生退款时，需要保证两笔交易同时都退款。这个就是直接采用数据库本地事务实现的，即一次退款请求，两笔交易同时退款。  总结：?数据库事务的优点是简单，业务层关心的很少。但是对于一个可用性很高的系统来说，所有的业务都揉在数据库事务执行，会让事务非常的复杂，不利于系统的扩展和维护。 两阶段提交  除了数据库能够保证本地的一致性，对于互联网系统来说，更多是分布式系统。提到分布式系统，必然提到分布式事务。而分布式事务中，就不得不介绍两阶段提交协议(2pc)。 而在核心系统，两阶段提交的方案主要应用在分布式数据库NesioDB和交易账务分离的柔性事务中。  分布式数据库NesioDB是由百度DBA和百度钱包联合开发的，支持分布式事务的数据库，目前已经应用在百度钱包的核心交易业务上，并稳定运行两年。该数据库的设计要求是让使用者能够像使用单机数据库一样的使用分布式数据库，因此实现的分布式事务，满足单机事务的ACID原则。关于分布式事务的一致性，采用的就是两阶段提交的方式来实现的，并且满足分布式事务模型。如下图所示。  第一阶段是准备阶段。   DTM 通知所有参与事务的各个 RM，给每个 RM 发送 prepare 消息。RM 接收到消息后进入准备阶段后，要么直接返回失败，要么创建并执行本地事务，写本地事务日志（redo 和 undo 日志），但是 不提交（此处只保留最后一步耗时最少的提交操作给第二阶段执行）。  第二阶段是提交/回滚阶段。   DTM 收到 RM 准备阶段的失败消息或者获取 RM 返回消息超时，则直接给 RM 发送回滚（rollback）消息，否则发送提交（commit）消息。RM 根据 TM 的指令执行提交或者回滚，执行完成后释放所有事务处理过程中使用的锁（最后阶段释放锁）。  数据库层面的两阶段提交，可以用来保证分布式事务的一致性，使得使用者使用分布式事务和单机事务一样方便。而两阶段提交的另外一种实现，即TCC(Try-Confirm-Cancel)， 也就是业务层面的柔性事务。 交易和账务分离的一致性实现，就是采用这种柔性事务来完成的。首先来说说柔性事务，它涉及 3 个模块，主业务、从业务 和 活动管理器（协作者）。  下面这张图是有关柔性事务一张经典的图。 第一阶段：主业务服务分别调用所有从业务服务的 try 操作，并在活动管理器中记录所有从业务服务。当所有从业务服务 try 成功或者某个从业务服务 try 失败时，进入第二阶段。  第二阶段：活动管理器根据第一阶段从业务服务的 try 结果来执行 confirm 或 cancel 操作。如果第一阶段所有从业务服务都 try 成功，则协作者调用所有从业务服务的 confirm 操作，否则，调用所有从业务服务的 cancel 操作。  在第二阶段中，confirm 和 cancel 同样存在失败情况，所以需要对这两种情况做 异常处理以保证数据一致性。  1. Confirm 失败：则回滚所有 confirm 操作并执行 cancel 操作。 2. Cancel 失败：从业务服务需要提供自动 cancel 机制，以保证 cancel 成功。  如果对应到交易和账务分离的项目中，流程如下：  第一阶段：主业务服务调用交易和账务执行try的操作，交易开启事务，做业务上的判断和写入，但是不提交事务。账务层面做资源的锁定。  第二阶段：账务资源锁定成功，交易提交事务成功，然后发送confirm 给账务。 ?如果交易提交失败，则发送cancel对资源进行释放。如果在confirm或者c