分布式事务解决方案（八股）

1. CAP理论

• 一致性【Consistency】：所有节点访问最新的数据
• 可用性【Availability】：非故障节点响应正常
• 分区容错性【Partition Tolerance】：分布式系统出现网络分区，仍能对外提供服务

附：网络分区：分布式系统中，由于出现网络故障或其他原因【物理断开，人为配置更改，安全攻击等】，导致原本联通的网络被分割成多个独立的子网，子网之间节点无法通信。解决的方式通常是分布式的超时和重试策略，服务发现的动态识别连接，采用Raft等一致性协议

CAP理论不是3选2，而是在出现P网络分区【必须处理的问题】的时候，只能保证数据的强一致性或者节点可用性。
举例说明就是，当网络出现分区，某个节点1在进行写操作，如果要保证数据一致性C，那就要别的节点234.都要禁止写操作，那这就是违法了A可用性。总得来说就是满足所有非故障节点都正常运行的话那么数据一致性是无法保证的。但是如果没有发生分区的话，那就要保证如何实现CA。

2. BASE理论–基于CA的平衡，对于AP的补充

• 基本可用【Basically Available】：允许损失部分性能/功能上的可用性
• 软状态【Soft-state】：允许不同节点数据之间同步存在延时
• 最终一致性【Eventually Consistent】：经过上面的性能损失、非核心功能不可用后，数据慢同步后，最终能够达到数据强一致性的状态。

附：分布式一致性的三种级别，强一致性【写什么读什么】、弱一致性【某个时刻一致就行】、最终一致性【最后一致就行】。
那实现最终一致性的方式是什么呢？
思想就是在数据方面解决，比如增加一个版本号，数据更新时增加。读时修复【读取数据时，不同节点数据不一致更新数据状态】。写时修复【写数据时修复-更推荐】。异步修复【定时检测数据一致性修复】。

ACID是数据库实例内部的数据-事务完整性理论，CAP是分布式系统-设计理论。

3. 分布式系统中如何保证一致性

事务一致性：操作的正确性，所有节点最终状态是一致的。如追踪电商平台的“优惠券”状态，订单和优惠券之间是强关联的。

副本一致性：数据多个副本之间是一致性的，保证数据更新时的分区同步。如下面的基于图书馆的Raft算法理解。

3.1 事务一致性

在分布式中影响事务一致性的原因通常是因为各个微服务之间解耦【每个服务都有独立数据存储】，产生了跨数据库事务。MySQL如何根据Redo和Undo log来实现事务一致性

总结补充：Redo Log【正向修改-向前补偿】记录对数据库的增删改正向操作，也就是数据变更的SQL语句用于重做恢复，而Undo Log【逆向恢复-向后补偿】记录的是数据变更前足够的恢复原始数据的信息即之前的状态，事务提交后会被清理。

常见的解决方案：

1. 技术角度：数据版本控制【参考MySQL】、事务协议（2PC、3PC、XA协议）、TCC补偿模式等

   • 2PC：两阶段提交-准备阶段和提交阶段，经典分布式事务协议，由协调者发出请求，所有参与者做出应答，任何一者回复“拒绝”，所有事务撤销。

   2PC的问题点

   同步阻塞问题：这也是事务的常见问题了，意思就是prepare阶段锁定的资源，别的事务也要就必须阻塞等待事务完成。

   单点故障问题：这也是3PC加了preCommit来解决的问题，意思就是一阶段prepare成功，但是二阶段commit宕机，导致资源处于锁定状态，事务无限期等待【故障】。

   数据不一致问题：同二，二阶段commit失败，数据也会因此不一致。

   • 3PC：三阶段提交-可以提交阶段、预提交阶段、最终提交阶段，表面上增加了预提交显得更可靠，用来确认所有的参与事务都已经准备好提交，但实际增加了通信开销的同时并不能解决极端情况无法提交回滚的问题。

   3PC的问题点

   字面意思“更可靠”，preCommit的存在是给最终提交上了个保险，检测事务参与者都准备好了那就commit，但很显然【存在极端情况】rollback请求没收到的话，数据也会不一致。

   • XA：传统的XA模式也是三阶段【seata XA二阶段不作详解】【1. 开始事务-生成全局事务XID 2. prepare阶段-确定是否可以提交 3. commit/rollback阶段-最终阶段，释放资源】，与2PC/3PC作区分的话，大概就是TM会首先开启一个全局事务并生成唯一标识XID，各个AP通过本地RM向TM上注册，TM首先会发送prepare请求，确定是否commit，这期间也是通过XID来管理的，当所有的分支事务都说ready了，那就最终执行commit，否则rollback，最后TM完成收尾，释放资源。

   补充：AP【应用服务】，TM【事务管理器-Transaction Manager】，RM【资源管理器-Resource Manager】

   XID的作用：每个分支事务都要带XID注册到TM，同时XID可以隔离和区分识别是哪个全局事务，同时在日志中记录XID和相关事务可以便于系统后期查询和恢复。

   • TCC：try-confirm-cancel 分布式解决方案（略）

2. 业务角度：事务分类-关键事务、可补偿性事务、可重试性事务

   • 关键事务：核心功能，一旦提交失败，立马回滚。如核心下单操作，用户信息保存失败，事务立马回滚，避免优惠券和库存的一致性。
   • 可补偿性事务：正向操作提交失败，反向代偿。如优惠券和库存，正向扣券减库存不行，反向释放优惠券加库存代偿。
   • 可重试性事务：业务操作中由于网络波动等原因导致失败，可以通过重新多次执行来达到最终目的。如发送验证码登陆场景。

   可重试性事务可以支持@Retry自定义注解配置，或者MQ的Retry+幂等保障可重复性

3. 场景落地实现：大致可分为-查询模型、任务检测模型、对账模型

   • 查询：查询接口是否完成，确定业务是否重新调用还是执行后续流程。
   • 自检：系统周期性跟踪对未执行任务检测并更新状态。
   • 对账：把不同业务的数据都拿来，一点点对，不一致就进行报警，需人工介入。

3.2 副本一致性

基于Paxos的Raft算法

分布式系统中由于网络分区或者节点故障等问题，不同节点对系统值有不同的认知，共识算法就是为了确保多个节点对某个值或一系列值达成一致性意见。

基本共识问题的核心是在分布式系统中，如果一个正确节点提出了某个值，在异步系统的其他正确节点最终会同意这个值，或者所有正确节点都同意不选择任何值。拜占庭共识算法是要考虑到系统中可能存在恶意节点，这些节点可能会发送错误信息或执行非预期行为。Raft的Leader选举算法用于协调其他节点的操作。2PC和3PC通常用于确保分布式数据库系统中事务的原子性和一致性。Paxos和Raft适用于需要强一致性和高可用性的场景。

Paxos的核心思想就是Baisc Paxos【多节点value共识】和Multi-Paxos【执行多次Baisc Paxos对一系列值达成共识】。

基础知识点：

Raft算法是一种分布式一致性算法，角色有三个：【Leader-领导者，Candidate-候选者，Follower-跟随者】核心思想是选举出一个Leader，由这个领导者负责管理数据复制和一致性。节点之间的通信用的是RPC【RequestVote RPC-候选人选举发起，AppendEntries RPC-心跳机制复制日志，InstallSnapshot RPC-发送快照给落后者】

raft算法首先会将时间划分为任意长度的term（任期），term号用连续数字表示，每一个任期的开始都是leader选举。当然多个Candidate竞选一个Leader，term期结束没有再继续下一个任期竞选，通信交换term号来判断小的更新成大的，过期的自动变成follower。

日志entry携带term，index，cmd。log是由entry组成的数组，标识是index，最新的最先添加到Leader的log数组中。

leader选举的过程是：1、增加term号；2、给自己投票；3、重置选举超时计时器；4、发送请求投票的RPC给其它节点。

算法理解：背景就是目前有一个图书馆，图书馆里面有很多分馆，每个分馆都有一个分馆主和一本借书记录【全一致】，如何用Raft思想保证每个借书记录在某个时间点读取的借书信息都是相同的？

在领导者选举【Leader Election】阶段，原馆长辞职后，图书馆会自动启动一个选举过程来选出新馆长。新馆长上任后，首要任务是确保所有分馆的借书记录是一致的。新馆长会将新的借书记录首先更新到自己的日志中，然后同步到其他分馆，确保所有分馆的日志都是最新的，并且记录是有效的，这体现了安全性。如果发现有分馆的记录不一致，新馆长会强制这些分馆更新到自己的记录，保证一致性。在分馆出现故障时，新馆长能够从其他分馆获取最新的记录信息，并更新故障分馆，确保系统的高可用性。新馆长定期发送心跳消息与分馆建立联系，如果分馆在一定时间内没有收到心跳，它们会认为新馆长可能已经不在了，然后可能会开始新的领导者选举过程。

面试常见问题：

1. Raft分为哪几部分？leader选举、任期管理、日志复制、日志压缩、心跳机制、租约管理等
2. Raft选举发起的时机？刚启动/leader挂掉/每个任期开始，计时器最先归0的先发起，成员变更。
3. Raft如何决定把票投出去？大概意思就是candidate通过投票RPC携带term_id和index的log日志与接收到的follower进行比较，如果本地follower的log比candidate的更新则拒绝投票，term_id最小更新，相同term_id的话日志哪个多就说了算。
4. Raft网络分区数据一致性如何解决？分区的话就先在一个区内存在的follower进行选举，选举出leader后来处理客户端的请求和日志，如果故障修复，则老leader退出变成follower且此时的任何更新都要以新的leader为准。通过日志恢复来保持数据的一致性
5. Raft和Paxos的区别？Raft拥有最新日志的节点才能成为leader，multi-paxos没有限制。Raft的leader有任期。
6. Raft的lease租约机制？每个term任期内只有持有租约lease的节点才能成为leader，到期后必须重发租约。