微服务分布式事务解决方案实战（理论基础篇）

分布式事务产生背景

    传统单体项目单库大部分情况下，不会产生分布式事务。但随着系统数据量增大，单个数据库承受越来越大压力，系统开始变慢，单库出现性能瓶颈。用户开始抱怨，慢慢当前系统结构开始无法适应业务发展。

    技术服务于业务，系统跟着业务发展进行架构演进，原有的架构已无法满足业务现状，同时也带来新的挑战，公司对系统提出重构和优化，把原来单体系统切换成主流微服务架构，、分布式系统架构。根据不同的业务将拆分成不同的微服务，比如会员服务、订单服务、商品服务。同时每个微服务对应独立的数据，业务数据被分散到各个业务系统数据库中，用户在系统的一个操作行为数据被分散到各个独立的子系统，由单库操作变成跨库操作，这就产生了跨库操作的分布式事务问题。

场景1：系统微服务化，业务拆分成一个个独立的微服务，每个微服务都对应者一个独立的业务数据库，用户在系统的一个操作行为数据被分散到各个独立的子系统，形成垮库操作。

场景二：为了解决数据库上的瓶颈，分库是很常见的解决方案，不同用户就可能落在不同的数据库里，原来一个库里的事务操作，现在变成了跨数据库的事务操作

单体应用事务如何管理？

• 原子性（Atomicity） 事务是一个或者多个SQL语句组成的整体,要么全部执行成功,要么全都执行失败 ,事务执行之后,不允许停留在中间某个状态。

  

• 一致性（Consistency） 一致性要求，事务在开始前和结束后，数据库的完整性约束没有被破坏。

• 隔离性（Isolation） 事务的执行是相互独立的，它们不会相互干扰，一个事务不会看到另一个正在运行过程中的事务的数据。

• 持久性（Durability）一旦事务提交成功，事务中所有的数据操作都必须被持久化保存到数据库中，即使提交事务后，数据库崩溃，在数据库重启时，也必须能保证通过某种机制恢复数据。

事务隔离级别

事务管理方式

JDBC事务设置为手动提交模式

基于Spring事务管理器"注解事务"

分布式事务相关理论

CAP理论

分布式系统中：Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼，所以不要有妄想。

• 一致性：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致，所以，一致性，说的就是数据一致性。

• 可用性：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）,CAP中的A指的是可用性（Availability），而ACID中的A指的是原子性（Atomicity)

• 分区容错性：即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。简单点说，就是在网络中断，消息丢失的情况下，系统如果还能正常工作，就是有比较好的分区容错性。

CAP取舍的策略(3选2)

CAP取舍的策略 3选2

在设计或开发分布式系统的时候，不可避免的要在CAP中做权衡。需要根据自己的系统的实际情况，选择最适合自己的方案，对于一个分布式系统来说。P是一个基本要求，CAP三者中，只能在CA两者之间做权衡，并且要想尽办法提升P，而非分布式系统有限考虑可用性和一致性

• CA without P

分布式系统中几乎是不存在的。首先在分布式环境下，网络分区是一个自然的事实。因为分区是必然的，所以如果舍弃P，意味着要舍弃分布式系统。那也就没有必要再讨论CAP理论了。这也是为什么在前面的CAP证明中，我们以系统满足P为前提论述了无法同时满足C和A。

    比如我们熟知的关系型数据库，如My Sql和Oracle就是保证了可用性和数据一致性，但是他并不是个分布式系统。一旦关系型数据库要考虑主备同步、集群部署等就必须要把P也考虑进来

• CP without A

如果一个分布式系统不要求强的可用性，即容许系统停机或者长时间无响应的话，就可以在CAP三者中保障CP而舍弃A。

一个保证了CP而一个舍弃了A的分布式系统，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。

设计成CP的系统其实也不少，其中最典型的就是很多分布式数据库，他们都是设计成CP的。在发生极端情况时，优先保证数据的强一致性，代价就是舍弃系统的可用性。

    如Redis、HBase等，还有分布式系统中常用的Zookeeper也是在CAP三者之中选择优先保证CP的。

无论是像Redis、HBase这种分布式存储系统，还是像Zookeeper这种分布式协调组件。数据的一致性是他们最最基本的要求。一个连数据一致性都保证不了的分布式存储要他有何用

• AP wihtout C

要高可用并允许分区，则需放弃一致性。一旦网络问题发生，节点之间可能会失去联系。为了保证高可用，需要在用户访问时可以马上得到返回，则每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。

   对于多数大型互联网应用的场景，主机众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到N个9，即保证P和A，舍弃C。12306买票当你购买的时候提示你是有票的（但是可能实际已经没票了）你也正常的去输入验证码，下单了。但是过了一会系统提示你下单失败，余票不足。这其实就是先在可用性方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，会影响一些用户体验，但是也不至于造成用户流程的严重阻塞。(舍弃的只是强一致性，退而求其次保证最终一致性)

小结

    适合的才是最好的，对于涉及到钱财这样不能有一丝让步的场景，C必须保证。网络发生故障宁可停止服务，这是保证CP，舍弃A。比如前几年支付宝光缆被挖断的事件，在网络出现故障的时候，支付宝就在可用性和数据一致性之间选择了数据一致性，用户感受到的是支付宝系统长时间宕机，但是其实背后是无数的工程师在恢复数据，保证数据的一致性。

对于其他场景，比较普遍的做法是选择可用性和分区容错性，舍弃强一致性，退而求其次使用最终一致性来保证数据的安全

BASE理论

基本可用，最终一致

BASE理论是对CAP中的一致性和可用性进行一个权衡的结果。理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

Basically Available（基本可用）：

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性

Soft state（软状态）：

弱状态也称为软状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据监听过程存在延时。

Eventually consistent（最终一致性）：

系统允许数据暂时不一致，只要程序保证最终一致性即可。例如银行系统的跨行转账业务

小结

    BASE理论面向的是大型高可用可扩展的分布式系统，和传统事务的ACID特性相反的，它完全不同于ACID的强一致性模型，而是提出通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。但同时，在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID特性与BASE理论往往又会结合在一起使用。观看下一篇  

下一篇我们准备针对分布式事务问题，给出  分布式事务解决方案 。识别图中的二维码，我们在这里一起成长。 微服务分布式事务解决方案实战（解决方案篇）