分布式事务

大纲

1.本地事物
 - ACID
 - 本地事务模型
2.分布式事物
 - 分布式事务概念
 - 跨库事务
 - 服务化事务
3.LCN框架及演示
4.分布式事物原理分析

1 本地事务

1.1ACID

原子性(Atomicity)
  即是数据库一个事务内的sql语句,要么全部成功,要么全部失败。例如老李给胖子转账100元,需求上应该是老李减去100元,胖子加上100元,流水记录是100元,如果老李减去了100元后,事务提交失败,则全部回滚,老李恢复100元(回滚操作在mysql中是通过日志来完成的(undo log))只有当整个事务全成功了,转账才会完成。

一致性（Consistency)
  数据库事务的一致性是指:在事务执行前和执行后,数据库的数据完整性不被破坏.这个完整性是个抽象的说法,举个例子在老李给胖子转账的事务中,老李-100,胖子+100,数据库中的金钱总数保持了完整性。

例如在银行的转账事务中,老李+100,胖子+100,满足了原子性(事务的操作完整),但是违背了一致性(银行转账的一致性要保证金钱总数不变)。

隔离性（Isolation）
数据库事务有隔离性,让并发的事务一个一个的执行,达到串行的效果.但是这在并发中会很大的影响数据库的性能,所以需要在安全与并发的效率之间寻求一个平衡。

持久性（Durability）
事务提交完成将永久性的改变数据库,即使数据库出错了,也不会丢失数据。

反过来可以理解为如果出了严重错误,事务是无法提交完成的,但只要他提交完成就被持久化了。

1.2 本地事务模型

本地事务是基于锁对并发的事务进行一个一个执行，以达到了串行执行效果。

2 分布式事务

2.1 分布式事务概念

一个大的操作由两个或者更多的小的操作共同完成。而这些小的操作又分布在不同的网络主机上。这些操作，要么全部成功执行，要么全部不执行。

2.2 分布式事务场景一：跨库事务

同时操作多少个数据源，这就是跨库事务

image.png

难点：
一个数据源对应一个事务，事务和事务之间是互相不可见，因此无法做到同时失败，同时成功。
解决方案：
使用分布式事务解决分布式事务。
####### 2.3 服务化事务

image.png
特点：
面向服务架构，微服务架构中，把项目拆分一个个子项目，每一个项目都存在本地事务，本地事务和其他服务器中的事务中相互隔离的关系。
存在问题：
无法保证多个项目中，一个操作要么都成功，要么都失败。
解决方案：
使用分布式事务，2PC可解决。

3 分布式事物事务模型

3.1 X/open

X/open组织制定分布式事务接口规范及事务模型

• DTP(distributed transaction processing):事务模型
• DTP XA 接口规范

3.2 DTP模型组件

• 应用程序：定义事务的边界（事务的开始、结束）
• 资源管理器：任何用来存储数据的服务。
• 事务管理器：监控事务进度，负责事务提交，回滚。
• 通信资源管理器
• 通信协议：负责事务模型之间的通信协议。

3.3 事务模型图

image.png

全局事务树模型：

image.png

3.4 XA规范

定义了事务管理器与资源管理器交互接口的规范。（事务注册，事务开始，回滚，提交......)

3.5 2PC

数据库2PC（Two Phase Commit，两阶段提交）又叫XA Transaction,遵循强一致性，性能不高。两阶段提交是指将提交过程分为两个阶段，即准备阶段（投票阶段）和提交阶段（执行阶段）。两阶段提交流程：

image.png

应用场景：

• 强一致性
• 分布式事务

4 CAP理论

4.1、Partition tolerance

先看 Partition tolerance，中文叫做"分区容错"。

大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信。

image

上图中，G1 和 G2 是两台跨区的服务器。G1 向 G2 发送一条消息，G2 可能无法收到。系统设计的时候，必须考虑到这种情况。

一般来说，分区容错无法避免，因此可以认为 CAP 的 P 总是成立。CAP 定理告诉我们，剩下的 C 和 A 无法同时做到。

4.2、Consistency

Consistency 中文叫做"一致性"。意思是，写操作之后的读操作，必须返回该值。举例来说，某条记录是 v0，用户向 G1 发起一个写操作，将其改为 v1。

image

接下来，用户的读操作就会得到 v1。这就叫一致性。

image

问题是，用户有可能向 G2 发起读操作，由于 G2 的值没有发生变化，因此返回的是 v0。G1 和 G2 读操作的结果不一致，这就不满足一致性了。

image

为了让 G2 也能变为 v1，就要在 G1 写操作的时候，让 G1 向 G2 发送一条消息，要求 G2 也改成 v1。

image

这样的话，用户向 G2 发起读操作，也能得到 v1。

image

4.3、Availability

Availability 中文叫做"可用性"，意思是只要收到用户的请求，服务器就必须给出回应。

用户可以选择向 G1 或 G2 发起读操作。不管是哪台服务器，只要收到请求，就必须告诉用户，到底是 v0 还是 v1，否则就不满足可用性。

4.4、Consistency 和 Availability 的矛盾

一致性和可用性，为什么不可能同时成立？答案很简单，因为可能通信失败（即出现分区容错）。

如果保证 G2 的一致性，那么 G1 必须在写操作时，锁定 G2 的读操作和写操作。只有数据同步后，才能重新开放读写。锁定期间，G2 不能读写，没有可用性不。

如果保证 G2 的可用性，那么势必不能锁定 G2，所以一致性不成立。

综上所述，G2 无法同时做到一致性和可用性。系统设计时只能选择一个目标。如果追求一致性，那么无法保证所有节点的可用性；如果追求所有节点的可用性，那就没法做到一致性。

5 BASE理论

5.1 BASE理论概述

BASE：全称：Basically Available(基本可用)，Soft state（软状态）,和 Eventually consistent（最终一致性）三个短语的缩写，来自 ebay 的架构师提出。

Base 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结，是基于 CAP 定理逐步演化而来的。其核心思想是：既是无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

5.2特性

1 Basically Available(基本可用)

什么是基本可用呢？假设系统，出现了不可预知的故障，但还是能用，相比较正常的系统而言：
响应时间上的损失：正常情况下的搜索引擎 0.5 秒即返回给用户结果，而基本可用的搜索引擎可以在 1 秒作用返回结果。
功能上的损失：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单，但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。
2. Soft state（软状态)
什么是软状态呢？相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种 “硬状态”。

软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
3. Eventually consistent（最终一致性）
上面说软状态，然后不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性。从而达到数据的最终一致性。这个时间期限取决于网络延时，系统负载，数据复制方案设计等等因素。