<b><font color="#b71c1c">2PC模式<br>基于数据库实现<br>1.XA方案<br>2.Seata方案-阿里</font></b>
思想
一阶段：准备阶段（Prepare phase）<br>需要<b><font color="#b71c1c">Undo和Redo</font></b>日记记录
子主题
二阶段：提交阶段（commit phase）
子主题
总结
使用分布式事务成本低，适用于数据库层面
性能不理想，XA无法满足高并发场景
在MySQL中不太理想
XA应用场景不理想
<b><font color="#b71c1c">同步阻塞（都被锁了）</font></b>，2PC两个阶段中，协调者和参与者的通信都是同步的，导致整个事务的的长时间阻塞<br>回滚阶段，事务管理器挂了，导致AP一直被锁
<b><font color="#b71c1c">3PC模式</font></b>
思想
一阶段：<u><font color="#b71c1c"><b>准备阶段（CanCommit）</b></font></u>
<font color="#b71c1c"><b>1.事务询问</b></font><br>协调者向所有的参与者发送一个包含事务内容的 canCommit 请求，询问是否可以执行事务提交操作，并开始等待各参与者的响应<br>
<b><font color="#b71c1c">2.各参与者向协调者反馈事务询问的响应：</font></b><br>参与者接收来自协调者的 canCommit 请求，如果参与者认为自己可以顺利执行事务，就返回 Yes，否则反馈 No 响应。
二阶段：<b><font color="#b71c1c">预提交阶段（PreCommit</font></b>）<br>一和二阶段就是之前2pc中的阶段1拆分的
根据CanCommit的结果,可能有两种结果
1.执行事务预提交
2.中断事务
<b><font color="#b71c1c">三阶段：提交阶段（DoCommit）</font></b>
针对PreCommit的两种结果,<br>阶段三也是两种结果
执行提交
中断事务
阶段三可能出现的问题
1.协调者出现问题
2.协调者和参与者之间的网络故障
优缺点
柔性事务（<b><font color="#b71c1c">TCC</font></b>补偿性方案）<br><font color="#b71c1c"><b>代码控制，代码侵入性非常强<br>方案：1.Hmily框架</b></font>
思想
Try：prepare行为，调用自定义的prepare逻辑
子主题
Confirm：commit行为（<font color="#b71c1c">Try阶段都ok</font>）
子主题
Cancel：rollback行为（<font color="#b71c1c">Try阶段有失败</font>）
易出现问题
1.空回滚
比如，服务一因为宕机或者网络异常，没有try，然后整个事务失败，进行cancel，形成空回滚。<br>处理办法：增加一个<font color="#b71c1c">分支事务记录表</font>，记录下来，有记录才进行cancel
2.幂等
3.悬挂
原因：由于网络原因，某个微服务可能try超时，cancel先执行，try随后才到
总结
优势在于可以自定义数据操作的粒度
不足之处是对于应用的<font color="#b71c1c"><b>侵入性非常强</b></font>
业务逻辑分支都需要try、confirm、cancel三步操作
<b><font color="#b71c1c">ACID</font></b> 特性
<b><font color="#b71c1c">原子性 -- Atomic</font></b>
强调事务不可分割
<b><font color="#b71c1c">一致性 --Consistency</font></b>
事务执行前后数据的完整性保持一致
<b><font color="#b71c1c">隔离性--Isolation</font></b>
一个事务执行中，不能影响其他事务
<b><font color="#b71c1c">持久性--Durability</font></b>
事务一旦结束，数据就持久到数据库
<b><font color="#b71c1c">产生原因</font></b>
1.微服务-- 不同数据库
2.跨库操作
3.多服务访问同一个数据库
<b style="color: rgb(211, 47, 47);">CAP理论 </b><br><font color="#000000">C和A是矛盾的</font>
<b><font color="#b71c1c">强一致性 --Consistency</font></b>
主从数据库的同步问题
<b><font color="#b71c1c">可用性--Avaliablity</font></b>
有请求，就要有相应
<b><font color="#b71c1c">分区容忍性--Partition-tolerance</font></b>
系统出现脑裂后，仍然提供服务（<b><font color="#b71c1c">最基本的能力</font></b>）
<b><font color="#b71c1c">BASE理论</font></b><br>依据A-P理论发展（<font color="#b71c1c"><b>最终一致性</b></font>）
基本可用--<b><font color="#b71c1c">B</font></b>aseically <b><font color="#b71c1c">A</font></b>valiable
软状态--<b><font color="#b71c1c">S</font></b>oft state,不要求强一致性
最终一致性--<b><font color="#b71c1c">E</font></b>ventually consistent
<b><font color="#000000">一致性</font><font color="#b71c1c">算法 Paxos<br></font></b>解决2PC，3PC各种硬伤,<font color="#b71c1c"><b>少数服从多数+位高权重</b></font><br><b><font color="#b71c1c">应用:</font></b>OceanBase(阿里)<br>
1.他解决了什么?
<b><font color="#b71c1c">一致性算法--Raft 算法<br>(</font></b>领导选举，日志复制<b><font color="#b71c1c">)<br></font></b>因为Paxos太难啦,所以Raft就出现了😔<br>
<b><font color="#b71c1c">一致性协议之 --ZAB<br>(使用最多)<br></font></b>Zookeeper Atomic Broadcast（Zookeeper 原子广播协议）。<b><font color="#b71c1c"><br></font></b>
