分布式事务

一、事务ACID说明

• A（Atomic）：原子性，构成事务的所有操作，要么都执行完成，要么全部不执行，不可能出现部分成功部分失 败的情况。

• C（Consistency）：一致性，在事务执行前后，数据库的一致性约束没有被破坏。比如：张三向李四转100元， 转账前和转账后的数据是正确状态这叫一致性，如果出现张三转出100元，李四账户没有增加100元这就出现了数 据错误，就没有达到一致性。

• I（Isolation）：隔离性，数据库中的事务一般都是并发的，隔离性是指并发的两个事务的执行互不干扰，一个事 务不能看到其他事务运行过程的中间状态。通过配置事务隔离级别可以避脏读、重复读等问题。

• D（Durability）：持久性，事务完成之后，该事务对数据的更改会被持久化到数据库，且不会被回滚

二、事务的分类

事务分为本地事务和分布式事务

2.1.本地事务

本地事务：同一数据库和服务器，称为本地事务 在计算机系统中，更多的是通过关系型数据库来控制事务，这是利用数据库本身的事务特性来实现的，因此叫数据库事务，由于应用主要靠关系数据库来控制事务，而数据库通常和应用在同一个服务器，所以基于关系型数据库的事务又被称为本地事务。

商品服务只操作了一个MySQL的数据库，一般情况下，只操作一个数据库，并有多条SQL组成同一个事务，就称为本地事务。

2.2.分布式事务

分布式事务： 分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上，且属于不同的应用，分布式事务需要保证这些操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

上面在电商系统中就是一个分布式事务。完成的操作步骤如下：

• 第一步：支付服务，修改支付订单状态。
• 第二步：修改订单状态。
• 第三步：修改库存数
• 第四步：执行积分服务，为用户加积分。

以上四个步骤在分布式系统中都是一个整体，也就是一个分布式事务。该事务必须保证2点：保证ACID的特性、保证性能问题
通过以上的图中我们可以看出，其实只要涉及到操作多个数据源，就可能会产生事务问题，当然在实际开发中我们要尽量避免这种问题的出现，当然如果避免不了，我们就需要进行解决，在我们的微服务系统架构中，目前比较好，比较常用的解决方案就是Seata。

三、分布式事务理论

目前微服务已经成为了项目开发的主要架构，本地事务已经无法满足分布式的要求，由此分布式事务问题诞生。 目前分布式事务存在两大理论依据：CAP定律 和 BASE理论。

3.1.CAP定律

CAP理论是分布式架构中重要理论, 它包含:

• 一致性(Consistency)：所有节点在同一时间具有相同的数据
• 可用性(Availability) ：保证每个请求不管成功或者失败都有响应(某个系统的某个节点挂了，但是并不影响系统的接受或者发出请求)
• 分区容错性(Partition tolerance) 系统中任意信息的丢失或失败不会影响系统的继续运作 (在整个系统中某个部分，挂掉了，或者宕机了，并不影响整个系统的运作或者说使用)
• AP ：当网络分区出现后，为了保证可用性，系统B可以返回旧值，保证系统的可用性。结论：违背了一致性C的要求，只满足可用性和分区容错，即AP，代表性的就是eureka
• CP：当网络分区出现后，为了保证一致性，就必须拒绝请求，否则无法保证一致性。结论：违背了可用性A的要求，只满足一致性和分区容错，即CP，代表性的是consul和zookeeper

CAP不可能都满足，原因如下:

• 如果C是第一需求的话，那么会影响A的性能。因为要数据同步，不然请求结果会有差异，但是数据同步会消耗时间，可用性就会降低。
• 如果A是第一需求，那么只要有一个服务在，就能正常接受请求。但是对于返回结果便不能保证，原因是，在分布式部署的时候，数据一致的过程不可能像切线路那么快。
• 如果同时满足一致性和可用性，那么分区容错就很难保证了。但是CAP理论提出就是针对分布式数据库环境的，所以P这个属性是必须具备的。P就是在分布式环境中，由于网络的问题可能导致某个节点和其它节点失去联系，这时候就形成了P(partition)。

3.2.BASE理论

BASE 全称是 Basically Available(基本可用)、Soft State(软状态)和 Eventually Consistent(最终一致性)三个短语的缩写，来自 ebay 的架构师提出。Base 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结，是基于 CAP 定理逐步演化而来的。其核心思想是：既然无法做到强一致性，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

Basically Available(基本可用)

基本可用就是假设系统某个模块出现了不可预知的故障，但其他模块依旧可用，例如：京东商城双十一活动时，商品评论模块如果出现故障，但不会影响商品交易、商品展示、购物车等核心模块的流程使用。

Soft State(软状态)

软状态指的是允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。用户在商城下单时，因网络超时等因素，订单处于“支付中”的状态，待数据最终一致后状态将变更为“关闭”或“成功”状态。

Eventually Consistent(最终一致性)

上面讲到的软状态不可能一直是软状态，必须有时间期限。在期限过后，应当保证所有副本保持数据一致性，从而达到数据的最终一致性，因此所有客户端对系统的数据访问最终都能够获取到最新的值，而这个时间期限取决于网络延时，系统负载，数据复制方案等因素。

在 CAP 中的一致性要求在任何时间查询每个节点数据都必须一致，它强调的是强一致性，而最终一致性是允许在一段时间内每个节点的数据不一致，但是经过一段时间每个节点的数据必须一致，它强调的是最终数据的一致性。在实际情景中，最终一致性分为 5 种：

• 因果一致性(Causal consistency)：如果节点 A 在更新完某个数据后通知了节点 B，那么节点 B 之后对该数据的访问和修改都是基于 A 更新后的值，但对和节点 A 无因果关系的节点 C 的数据访问则没这限制。
• 读己之所写(Read your writes)：节点 A 更新一个数据后，它自身总是能访问到自身更新过的最新值，而不会看到旧值。
• 会话一致性(Session consistency)：会话一致性将对系统数据的访问过程限定在一个会话当中：系统能保证在同一个有效的会话中实现 “读己之所写” 的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。
• 单调读一致性( Read consistency)：单调读一致性指如果一个节点从系统中读取出一个数据项的某个值后，那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。
• 单调写一致性(Write consistency)：指一个系统要能够保证来自同一个节点的写操作被顺序的执行。

对于上面的 5 种最终一致性，在实际系统中往往会结合使用，以构建一个具有最终一致性的分布式系统。