上一篇：订单业务的一致性（CAP中的C【Consistency】）-01问题的提出

1.什么是分布式系统

分布式系统：是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。其目的是利用更多的机器，处理更多的数据。 通俗来讲： 1.各个小服务组成一个系统，不管服务多么复杂。 2.各个自治的进程中运行。 3.部署在不同的机器节点上，通过协议相互连通，完成同一件事。

于商城服务最直接的表现就是

这只是商城分布式架构中的冰山一角，但是很能说明问题，订单服务和库存服务和积分不误共同完成一件事情；各自线程自治；通过协议相连通，高内聚。至此应该对分布式事务由来一个感性的认识了。

2.分布式系统存在的问题

至此需要引入一个CAP原则： C:一致性（Consistency） A:可用性（Availability） P:分区容错性（Partition tolerance） 说到底都是落在数据层面上。

分布式事务经常出现异常：机器宕机、异常处理、消息丢失、等等。 概念总之冷冰冰的，我们结合订单业务来分析一下，可能出现的问题，看看问题会出现CAP的问题。

2.1一致性（Consistency）

一致性主要指，在分布式系统中所有的数据是否一致，包括 1.各服务对应数据是否协调一致（各数据是否有矛盾：如订单下成功了，但是库存没有扣减成功）。 2.数据备份是和否一致（统一适合是否具有同样的值）。

于本业务场景就是 1.1把订单保存在订单表中 1.2调用库存服务吧库存减去2 1.3调用用积分服务给张三添加800万积分 这三件事要么全部成功，要么全部失败 于数据库场景： 订单库n个节点内部数据是否一致； 库存库m个节点内部节点数据是否一致 积分库p个节点内部节点数据是否一致

2.2可用性（Availability）

值系统如果部分服务出现了问题 ，即出现了一致性的问题后该如何选择，是继续提供服务，或者继续提供部分服务，还是必须保证一致性，丧失可以行。可用性和一致性只能满足一个。即集群一部分出现故障后，是否还能相应客户端的一些请求。

于本业务场景就是 1.1把订单保存在订单表中 1.2调用库存服务吧库存减去2 1.3调用用积分服务给张三添加800万积分 这三件事如果有没有成功的，是否是阻塞式的，系统不可用，必须等待全部成功，或者全部失败的问题。 于数据库场景： 订单库n个节点内部数据为了保持一致性，是否丧失可用性，即阻塞一定要一致。 库存库m个节点内部数据为了保持一致性，是否丧失可用性，即阻塞一定要一致。 积分库p个节点内部数据为了保持一致性，是否丧失可用性，即阻塞一定要一致。

2.3分区容错性（Partition tolerance）

分布式系统可能部署是即分布在不同的子网络中，如一部分服务在中国，另一部分服务在欧洲，这就是两个区（partition），或者由于网络的原因把原本属于同一个网络的服务，割裂开来，形成了不同的区，这个时候分布式系统必须保证可用，即须有分区容错性。 总结：cap原则，分区容错性必须有，可用性和一致性根据业务不同可以选择不同的架构方式和技术选型。

于本业务场景就是 1.1把订单保存在订单表中 1.2调用库存服务吧库存减去2 1.3调用用积分服务给张三添加800万积分 这三件事如果由于网络原因无法通讯，系统可以和在线节点（能通讯节点持）持续工作的问题。 于数据库场景： 订单库n个节点内部数据为了保持一致性，是否丧失可用性，即阻塞一定要一致。 库存库m个节点内部数据为了保持一致性，是否丧失可用性，即阻塞一定要一致。 积分库p个节点内部数据为了保持一致性，是否丧失可用性，即阻塞一定要一致。 而此时我们主要讨论的是CAP中C:一致性（Consistency）

3.一致性解决方案：Raft算法初体验–自己玩去

Raft算法是从database server 的维度来保证主从多分的一致性的。特别注意此处仅为减少这个维度，而种另一个维度即不同库（订单、库存、积分）的解决方案是强一致性seata、弱一致性的其他解决方案

Raft算法分为三个部分： 1. leader选举 ：角色：leader、candidate（可同时又多个区竞选）、follower 2 .日志复制：在心跳的时候发送日志到followers，收到followers确认收到后保存 3.分区容错

3.1 Raft动画体验1 Raft动画体验http://thesecretlivesofdata.com/raft/ 3.2Raft动画体验2 Raft动画2：https://raft.github.io/ 这个更自主可以根据自己情况演示各种问题下的一致性。

4.强一致性解决方案：Seata分布式事务解决方案

cap中的一致性是强一致性。

上面介绍的Raft主要针对的是同一个数据库的多份复制的情况下的一致性问题，那么另外一个维度呢？我们所要讨论的基于订单业务的这种不同数据库之间的一致性怎么处理呢？我们需要一个框架去做这件事情，而Seata就是这个问题的解决方案之一。 而接下来的讨论中心：就是分布式事务的解决方案，这也是本文的中心任务。 而这个维度正事对CAP原则的一个延伸。 – 我称之为 A-B-C一致性问题。 而同一数据库不同复制节点我称之为：A1-A2_A3一致性问题。从名字应该不难看出他们的相同和不同之处了吧。

即 A1-A2_A3一致性问题是原始问题：由Raft算法或者Paxos算法解决 A-B-C一致性问题是上问题的延伸：由Seata等其他的解决方案。

5.Base理论-最终一致性理论

对于CAP原则的延伸，思想是即使无法做到强一致性，但是彩玉适当的做一致性也是可行之策，即最终一致性。 BASE介绍 BA:Basically Avalibale 基本可用 S:Soft State 软状态 -允许有中间状态，如正在更新中… … E:Eventual Consistency 最终一致性 ，所有副本（A1-A2_A3）,或者不同服务（A-B-C）经过一段时间后，最终能达到状态一致。

弱一致性和强一致性正好相反。 最终一致性是弱一致性的特殊情况。

6 分布式事务的其他解决方案

6.1 2PC模式（XA Transactions）

mysql 数据库原生支持。分为连个阶段

事务协调器要求每个设计到事务的数据库预提交（precommit）此操作，并反映是否可以提交。

事务协调器要求每个数据库提交数据 其中任何一个数据库否决次次提交，那么素有的数据库均瑶球他们在此事务中的那个部分回滚。 图，如下：

特点： 1.XA协议简单，而且商业化数据库支持，使用成本低 2.XA性能不理想，单链路，无法实现高并发场景 3.许多nosql不支持XA 4.也有3PC引入了超时机制，若超时做相应的处理。

6.2 柔性事务-TCC事务补偿方案

需要程序员自己实现。

刚性事务：遵循ACID原则，强一致性 柔性事务：遵循BASE原则，最终一致性 ，允许在一定时间内，不同节点数据不一致。 TCC：Try、Confirm和Cancel

6.3 柔性事务-最大努力通知

按照规律进行通知，不保真数据一定能通知成功，，但是会提供可查询的操作接口进行核对，这种方案主要在与第三方通讯时，比如：比如用微信或者支付宝的接口，微信或者支付宝会在付款成功后通知系统，支付成功，这种方案也是结合Mq实现，例如通过MQ发送http请求，设置最大通知次数，到底通知次数后即不在通知。1,2,4,8…等时刻通知… … 金融行业用的多。

6.4 柔性事务-可靠消息+最终一致性

这种方案是电商业务所采取的方案。后面会详细说到。

7总结

谈了这么多。回归主题了。 要解决的问题是订单-库存-积分的一致性问题，即分布式事务在A-B-C模式下的解决方案。而我们的备选中的是两种方式（虽然上面也介绍了其他方式，但是仅考虑这两种作为对比）：Seata的强一致性事务和柔性事务-可靠消息+最终一致性这两种方案。 下一篇：订单业务的一致性（CAP中的C【Consistency】）-03使用Seata做强一致性分布式事务

前路无畏 认证博客专家 专家认证 自律的艰辛总甜过懊悔的苦果！专注于java后端技术及解决方案，善于总结，分享！自律的艰辛总甜过懊悔的苦果！专注于java后端技术及解决方案，善于总结，分享！自律的艰辛总甜过懊悔的苦果！专注于java后端技术及解决方案，善于总结，分享！