分布式事务

本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

成都创新互联服务项目包括昌乐网站建设、昌乐网站制作、昌乐网页制作以及昌乐网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，昌乐网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到昌乐省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！

1. 分布式理论
   1.1. CAP定律
   CAP指的是：一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。
   CAP定律说的是，在一个分布式系统中，最多只能满足C、A、P中的两个，不可能三个同时满足。
   在分布式系统中，网络无法 100% 可靠，分区其实是一个必然现象。如果我们选择了 CA 而放弃了 P，那么当发生分区现象时，为了保证一致性，这个时候必须拒绝请求，但是 A 又不允许，所以分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构。
   而且，显然，任何横向扩展策略都要依赖于数据分区。因此，设计人员必须在一致性与可用性之间做出选择。
   1.2. BASE理论
   往往在分布式系统中无法实现完全一致性，于是有了BASE理论，它是对CAP定律的进一步扩充
   BASE指的是：
   BASE理论是对CAP中的一致性和可用性进行一个权衡的结果
   BASE理论核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性
   BASE理论是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态
2. 分布式事务解决方案
   2.1. 基于XA协议的两阶段提交
   XA协议包含两部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现，目前主流的关系型数据库都实现了XA接口，而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。
   
   优点：尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不能100%保证强一致）
   缺点：XA协议遵循强一致性。在事务执行过程中，各个节点占用着数据库资源，只有当所有节点准备完毕，事务协调者才会通知提交，参与者提交后释放资源。这样的过程有着非常明显的性能问题。
   （PS：XA三阶段提交在两阶段提交的基础上增加了CanCommit阶段，并且引入了超时机制。这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。）
   两阶段提交方案锁定资源时间长，对性能影响很大，基本不适合解决微服务事务问题。
   2.2. TCC方案
   TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。
   其将整个业务逻辑的每个分支显式的分成了Try、Confirm、Cancel三个操作。Try部分完成业务的准备工作，confirm部分完成业务的提交，cancel部分完成事务的回滚。
   
   拿前面的下单的例子来说，服务A的try相当于查询是否有可用的积分，Confirm相当于扣减积分，Cancel相当于增加积分。
   优点：跟2PC比起来，实现以及流程相对简单了一些，但数据的一致性比2PC也要差一些
   缺点：TCC属于应用层的一种补偿方式，所以需要程序员在实现的时候多写很多补偿的代码，而且补偿的时候也有可能失败，在一些场景中，一些业务流程可能用TCC不太好定义及处理。
   2.3. 本地消息表
   其基本的设计思想是将远程分布式事务拆分成一系列的本地事务。
   消息生产方，需要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一个事务里提交，也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消费方。如果消息发送失败，会进行重试发送。
   消息消费方，需要处理这个消息，并完成自己的业务逻辑。此时如果本地事务处理成功，表明已经处理成功了，如果处理失败，那么就会重试执行。如果是业务上面的失败，可以给生产方发送一个业务补偿消息，通知生产方进行回滚等操作。
   生产方和消费方定时扫描本地消息表，把还没处理完成的消息或者失败的消息再发送一遍。如果有靠谱的自动对账补账逻辑，这种方案还是非常实用的。
   本地消息表是一个比较好的做法，这样可以有效防止重复消息处理
   以转账为例，这种方式的过程是这样的：
   有了消息表以后，可以防止重复、可以重试、保证消息不丢失、做幂等性校验
   优点：一种非常经典的实现，避免了分布式事务，实现了最终一致性。
   缺点：消息表会耦合到业务系统中，如果没有封装好的解决方案，会有很多杂活需要处理。
   2.4. MQ（非事务消息）
   如果不把本地数据库操作和消息投递放在同一个事务中，那么很难保证本地事务成功后消息一定发送成功
   如果把它们放在同一个事务中，那么考虑下面几种情况：
   以上三种情况都是正常的，不会有什么问题
   然而，考虑下面这种情况：
   本地数据库操作成功，消息投递成功，应用服务器挂了，事务回滚，于是不一致出现了，即本地数据库操作没成功，而消息却发成功了
   如果这是转账的话，对方会无缘无故多出一笔钱
   究其原因，是因为发消息不是数据库操作，它不受ACID的限制，也就是说数据库事务管不了发消息，因为他们不是同一个数据库的同一个事务，当然还有一个原因是发出去的消息是无法撤销的。（PS：在后面将要介绍的RocketMQ的事务消息可以撤销）
   而上面消息表的话，是同一个数据库的同一个事务，因此不会出现这种问题
   综上，这种方式有一定的风险，它无法保证本地数据库操作 与 消息投递的一致性，不建议使用
   2.5. MQ（事务消息）
   目前，仅阿里云的RocketMQ支持事务消息。帮助用户实现类似 X/Open XA 的分布事务功能，通过 MQ 事务消息能达到分布式事务的最终一致。
   
   说明：
   其中，事务消息发送对应步骤1、2、3、4，事务消息回查对应步骤5、6、7
   2.6. GTS
   全局事务服务（Global Transaction Service，简称 GTS）是一款高性能、高可靠、接入简单的分布式事务中间件，用于解决分布式环境下的数据一致性问题。GTS 可以保证分布式系统中的分布式事务的 ACID 特性。它是阿里云的一款产品。