什么是事务
事务将应用程序的多个读、写操作捆绑成为一个逻辑操作单元。即事务中的读写是一个执行整体，这个事务要么成功（提交），要么失败（中止或者回滚）。是人为创建的简化应用层的编程模型。
分布式事务
分布式场景下的事务处理，事务的参与者、支持事务操作的服务器、存储等资源分别位于分布式系统的不同节点。
数据库事务
数据库事务特性包括ACID，分别是
- 原子性（Atomicity）
- 一致性（Consistency）
- 隔离性（Isolation）
- 持久性（Durabilily）
数据库的异常现象
- 脏读：指一个事务中访问到另一个事务未提交的数据
- 不可重复读：指事务读取同一条记录2次获得不一样的结果
- 幻读：事务读取2次，得到的记录条数不同
这3者的包含关系是，具有一定的包含关系
脏读 > 不可重复读 > 幻读
不同的隔离级别
下面的隔离级别从低到高，隔离级别越低性能越高，隔离级别越高数据库性能越差
- 读未提交（Read uncommitted）：事务A对数据进行修改，不允许事务B对数据进行修改，但允许事务C对数据读取
- 读已提交（Read committed）：未提交的写事务不允许访问，但读取数据的事务允许其他事务访问该行数据
- 可重复读（Repeatable read）：同事务内的查询读取时刻一致，但不限制insert操作
- 串行化（Serializable）：所有事务必须串行之行
分布式事务产生的原因
伴随系统拆分出现，为了解决海量数据服务对扩张行的要求。
- 存储层拆分：典型的分库分表，跨表更新需要保证数据的一致性
- 服务层拆分：业务的服务话，从集中式到分布式，业务功能之间越来越解耦合
分布式事务的解决方案
- 2PC两阶段提交（Two-phase Commit Protocol）
- 3PC三阶段提交（Three-phase Commit Protocol）
- TCC分段提交（Try-Commit-Cancel）
- 基于消息补偿的最终一致性：通过异步消息保证最终一致性
- 不要求最终一致性的柔性事务：什么都不保证
分布式事务的开源组件
- Seata（将分布式事务拆分成一个包含了若干分支事务的全局事务，并负责将进行分支事务的协调）
2PC和3PC
协调者统一调度
通过一个Leader进程进行统一协调所有分布式节点的执行，通过通知和表决的方式，决定Commit还是Rollback操作
两阶段提交协议（2PC）
2PC基于一下的假设
- 节点之间可以互相通信，存在一个节点为协调节点（Coordinator），其他节点作为参与者（Participants）
- 所有节点采用预写日志，即使节点损坏也不会导致日志数据的丢失
- 所以节点不会永久性损坏，损坏后也可以恢复
两个阶段为
- 提交请求阶段：协调者通知事务参与者准备提交事务，然后进入表决过程。参与的节点没有进行Commit操作。
2. 提交阶段：基于第一个阶段的投票进行表决：提交&取消这个事务。仅当所有参与者同意提交，协调者才会通知各个参与者提交事务，否则取消事务。参与者收到消息后再进行Commit&Rollback操作。
两阶段提交存在的问题
- 资源被同步阻塞：所有参与节点都是事务独占状态，单参与者占有公共资源就会阻塞
- 协调者出现单点故障，导致参与者被阻塞
- Commit阶段数据不一致，如果此时部分网络问题，部分参与者一直阻塞，导致该时间段数据不一致。
三阶段提交协议（3PC）
解决2PC的同步阻塞问题，引入超时机制，并将2PC的第一阶段拆分，先询问再锁资源，最后提交。（CanCommit、PreCommit、DoCommit）
1.Cancommit（第一阶段）
协调者询问参与者是否可以Commit，可以提交返回Yes，否则No
2.PreCommit（第二阶段）
协调者根据参与者的回复继续操作，有A/B两种情况
A.CanCommit阶段全部返回Yes
- 发送预提交请求：协调者发送PreCommit请求，并进入Prepared阶段
- 事务预提交：参与者接到PreCommit后执行事务
- 响应反馈：参与者成功执行后返回ACK，并等待最终指令
B.有参与者发送No响应/等待超时无响应
- 协调者发送中断请求，abort
- 中断事务。参与者中断事务
3.DoCommit（第三阶段）
DoCommit阶段有一下3种情况：
A.执行提交
- 协调者收到ACK后发送DoCommit提交请求
- 参与者收到DoCommit请求后，提交事务并释放资源
- 响应反馈，事务提交后发送ACK响应
- 收到事务提交后的ACK，完成事务
B.中断提交
协调者没有收到参与者发送的ACK响应，执行中断事务
C.超时提交
超时未收到ACK响应，执行Commit操作
扫一扫
468
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
