Seata
seata
分布式事务简介
分布式事务产生的根本原因
组成业务逻辑的一组操作使用的数据库连接不是同一个
CAP理论(布鲁尔定理)
分布式系统中无法同时满足CAP
Consistency 一致性
一致性指all nodes see the same data at the same time，即所有节点在同一时间的数据完全一致。
一致性是因为多个数据拷贝下并发读写才有的问题，因此理解时一定要注意结合考虑多个数据拷贝下并发读写的场景。
对于一致性，可以分为从客户端和服务端两个不同的视角。
客户端
从客户端来看，一致性主要指的是多并发访问时更新过的数据如何获取的问题。
服务端
从服务端来看，则是更新如何分布到整个系统，以保证数据最终一致。
对于一致性，可以分为强/弱/最终一致性三类
从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。
强一致性
对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。
弱一致性
如果能容忍后续的部分或者全部访问不到，则是弱一致性。
最终一致性
如果经过一段时间后要求能访问到更新后的数据，则是最终一致性
Availability 可用性
可用性指“Reads and writes always succeed”，即服务在正常响应时间内一直可用。
好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。通常情况下可用性和分布式数据冗余，负载均衡等有着很大的关联。
Partition Tolerance分区容错性
分区容错性指“the system continues to operate despite arbitrary message loss or failure of part of the system”，即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务。
分布式系统一般选择CP或AP，CA无法同时满足
BASE理论
- 基本可用（Basically Available）
- 软状态（Soft State）
- 最终一致性（Eventually Consistent）
下面展开讨论：
基本可用
什么是基本可用呢？假设系统，出现了不可预知的故障，但还是能用，相比较正常的系统而言：
- 响应时间上的损失：正常情况下的搜索引擎0.5秒即返回给用户结果，而基本可用的搜索引擎可以在2秒作用返回结果。
- 功能上的损失：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单。但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。
软状态
什么是软状态呢？相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种“硬状态”。
软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
最终一致性
上面说软状态，然后不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性，从而达到数据的最终一致性。这个时间期限取决于网络延时、系统负载、数据复制方案设计等等因素。
而在实际工程实践中，最终一致性分为5种：
因果一致性（Causal consistency）
因果一致性指的是：如果节点A在更新完某个数据后通知了节点B，那么节点B之后对该数据的访问和修改都是基于A更新后的值。于此同时，和节点A无因果关系的节点C的数据访问则没有这样的限制。
读己之所写（Read your writes）
读己之所写指的是：节点A更新一个数据后，它自身总是能访问到自身更新过的最新值，而不会看到旧值。其实也算一种因果一致性。
会话一致性（Session consistency）
会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效的会话中实现 “读己之所写” 的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。
单调读一致性（Monotonic read consistency）
单调读一致性指的是：如果一个节点从系统中读取出一个数据项的某个值后，那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。
单调写一致性（Monotonic write consistency）
单调写一致性指的是：一个系统要能够保证来自同一个节点的写操作被顺序的执行。
在实际的实践中，这5种系统往往会结合使用，以构建一个具有最终一致性的分布式系统。
实际上，不只是分布式系统使用最终一致性，关系型数据库在某个功能上，也是使用最终一致性的。比如备份，数据库的复制过程是需要时间的，这个复制过程中，业务读取到的值就是旧的。当然，最终还是达成了数据一致性。这也算是一个最终一致性的经典案例
分布式事务解决方案
遵循CP：强一致性
XA协议：数据库级别
遵循AP：弱一致性
TCC
AT
SAGA
可靠消息最终一致性
分布式事务模型
DTP(Distributed Transaction Process)模型：
AP(Application) 应用程序
TM(Transaction Manager) 事务管理器
RM(Resource Manager) 资源管理器
两阶段提交模型(基于DTP模型):
prepare阶段
commit/rollback阶段
XA协议
XA协议执行流程：
XA {START|BEGIN} xid [JOIN|RESUME]
XA END xid [SUSPEND [FOR MIGRATE]]
XA PREPARE xid
XA COMMIT xid [ONE PHASE]
XA ROLLBACK xid
XA BEGIN 和 XA END的作用是确定分布式事务的范围，XA事务可以和本地事务共存
数据库通过支持XA协议实现了两阶段提交中RM职责，TM职责由使用者处理，一般由框架进行管理
seata组成
TC (Transaction Coordinator) - 事务协调者
维护全局和分支事务的状态，驱动全局事务提交或回滚。
TM (Transaction Manager) - 事务管理器
定义全局事务的范围：开始全局事务、提交或回滚全局事务。
RM (Resource Manager) - 资源管理器
管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚
XA模式
AT模式
核心思想：模拟mysql本地事务实现方式，将mysql锁转移到分布式全局锁，降低mysql锁持有时间提升性能
全局锁：由参与全局事务的表名和操作记录的主键按照一定规律组成，默认保存在TC服务器端，在RM提交本地事务前生成并注册到TC
两阶段提交协议的演变：
- 一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
- 二阶段：
- 提交异步化，非常快速地完成。
- 回滚通过一阶段的回滚日志进行反向补偿。
写隔离：
- 一阶段本地事务提交前，需要确保先拿到 全局锁 。
- 拿不到 全局锁 ，不能提交本地事务。
- 拿 全局锁 的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁。
读隔离
在数据库本地事务隔离级别 读已提交（Read Committed） 或以上的基础上，Seata（AT 模式）的默认全局隔离级别是 读未提交（Read Uncommitted）
如果应用在特定场景下，必需要求全局的 读已提交 ，目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的代理。
TCC模式
SAGA模式
分布式事务失效常见原因
- 微服务链路未传递全局事务id：需框架支持或手动处理
- 全局异常处理：RM去除全局异常处理或RM全局异常处理时在全局事务中时手动回滚事务
- 熔断降级：熔断降级时手动回滚事务
参考资料：
