分布式事务有了解过嘛？（讲讲分布式事务）（得物，shopee）page 1

分布式事务是跨多台机器、多个数据库或服务的事务，要求“All or nothing”。

二阶段提交。1.阶段一：投票，协调者（Transaction Manager）向各参与者（Resource Manager）发送 CanCommit 请求。参与者执行本地操作，写日志但不提交，返回“Yes/No”。2.阶段二：提交。若所有参与者都返回“Yes”，协调者发送 DoCommit；否则发送 DoAbort。参与者据此提交或回滚，并回复 HaveCommitted。存在同步阻塞问题。

三阶段提交。CanCommit（询问能否执行），PreCommit（预提交，记录 Undo/Redo），DoCommit / Abort。它的改进是在协调者和参与者均引入超时，减少长时间阻塞。

基于消息的最终一致性。用消息队列（Kafka、RabbitMQ、RocketMQ 等）异步保证“最终一致性”。1.业务服务在本地事务中写入“待发”消息。2.消息队列持久化、投递给下游服务。3.下游服务消费后处理业务，并返回 ACK，以完成本地事务或重试。

常见的分布式事务（美的考过）

分布式事务分为柔性事务和刚性事务。

刚性事务包括2阶段提交，3阶段提交。2阶段提交就是阶段一提交事务请求，阶段二执行事务提交。3阶段提交就是首先阶段1cancommit，每个参与者返回yes或no，然后阶段2precommit，如果上面每个人都说yes那么发送预提交事务，如果有no则发送中断请求，最后阶段3docommit，如果上面都说yes，那么提交事务，如果有no则发送中断请求。

柔性事务包括通知型和补偿型。通知型又包括异步确保型事务，尽最大努力通知型。补偿型包括tcc模式和saga模式。异步确保型包括mq事务消息方案以及本地消息表方案。本地消息表比mq的好处是MySQL写入在mq之前，能保证mq不影响业务正常流程。最大努力通知型也有mq方案和本地消息表方案。

事务的四个特征？

Atomic原子性，Consistency一致性，Isolation隔离性，Durability持久性。

RocketMQ处理流程说一下

1. 事务发起⽅⾸先发送半消息到MQ；

2. MQ通知发送⽅消息发送成功；

3. 在发送半消息成功后执⾏本地事务；

4. 根据本地事务执⾏结果返回commit或者是rollback；

5. 如果消息是rollback, MQ将丢弃该消息不投递；如果是commit，MQ将会消息发送给消息订阅⽅；

6. 订阅⽅根据消息执⾏本地事务；

7. 订阅⽅执⾏本地事务成功后再从MQ中将该消息标记为已消费。

TCC的处理流程说一下

初步操作 Try：完成所有业务检查，预留必须的业务资源。

确认操作 Confirm：真正执⾏的业务逻辑，不作任何业务检查，只使⽤ Try

阶段预留的业务资源。因此，只要 Try 操作成功，Confirm 必须能成功。另

外，Confirm 操作需满⾜幂等性，保证⼀笔分布式事务有且只能成功⼀

次。

取消操作 Cancel：释放 Try 阶段预留的业务资源。同样的，Cancel 操作也

需要满⾜幂等性。

saga模式的处理流程说一下

saga模式把分布式事务拆成本地事务链，每个本地事务Ti有补偿Ci。saga的执行顺序有两种，T1，T2，T3，，，，，Tn，这是成功，以及T1，T2，，，Tj，Cj，，，C2，C1，这是有向后恢复的。

分布式事务与分布式锁的区别？

分布式锁解决的是分布式资源抢占的问题；分布式事务是解决流程化提交问题。

解释一下脏读，不可重复读，幻读

脏读，事务读取了另一个事务修改但未提交的数据；不可重复读，书屋读取数据后，再次读取数据，已经被另一个事务修改或删除，关注已存在的数据行的更新；幻读，事务范围查询时，另一个事务插入新的数据，数据满足事务的查询条件，关注新插入的行。

解释一下事务的隔离级别

未提交读，提交读，可重复读，可串行化。

什么是分布式事务？

分布式事务是确保在分布式系统中，跨多个不同节点的操作要么全部成功，要么全部失败的一种机制。这些节点可能包括不同的服务和资源，分布于不同的物理或虚拟环境中。如，在一个电商网站中，用户下单的同时必须在订单系统中创建订单并在库存系统中相应减少库存，这两个操作必须同时成功或同时失败，以防止数据不一致。

什么是数据一致性？

数据一致性是分布式系统中确保所有节点在任何给定时间点都能看到相同数据的特性。它要求在数据被更新并通知客户端操作完成后，所有节点的数据必须完全一致，不允许有中间状态的存在。数据一致性可分为三种类型：强一致性、弱一致性和最终一致性。强一致性保证所有客户端在任何时刻都看到相同的数据；最终一致性允许数据存在暂时的不一致，但要求在一定时间后达到一致；弱一致性则允许数据在不同节点上出现一定程度的不同步。

为什么分布式系统中⽆法同时保证⼀致性和可⽤性？

在分布式系统中，由于基本要求是分区容错性（P），通常需要在一致性（C）和可用性（A）之间做出选择。这种权衡的根源在于当一个节点在进行数据写操作时，为了保持数据的一致性，其他节点可能需要暂停操作直到数据同步完成。这种同步过程会降低系统的可用性，因为它可能导致请求超时或失败。反之，如果优先保障系统的可用性，允许节点在数据同步期间继续响应读写请求，则可能违反数据一致性的需求。

3PC相对于2PC⽽⾔到底优化了什么地⽅呢?

超时机制的优化。2PC中，只有协调者（Coordinator）设置了超时机制，如果在某个阶段等待参与者（Participant）响应超时，协调者可以做出决定（如中止事务）以避免事务一直处于未决状态。3PC在此基础上进一步增强，不仅协调者有超时机制，参与者也设置了超时时间。3PC预提交阶段允许系统在最终提交之前确保所有参与节点的状态一致。

分布式事务了解吗？你们是如何解决分布式事务问题的？

强一致性场景，Seata AT（Auto Transaction）模式，保证数据绝对正确，如电商交易处理，Seata AT模式通过自动记录数据变化来实现。弱一致性场景：Seata TCC模式，如订单支付服务，在Try阶段尝试执行所有操作，如果所有操作都成功，再在Confirm阶段提交事务。最终一致性场景：基于消息的异步事务。如积分增加，利用消息队列（MQ）保证消息的可靠传递。

怎么设计一个分布式任务调度系统？

中心化调度和去中心化调度。选择中心化调度，业务通过SDK接入，作为一个Client，通过Gprc通信，基于kess注册发现。模块划分，前端控制台，客户端，服务端，服务端包括调度模块，协调模块，信息收集模块。