面试题： 分布式事务

正文

• 1.什么是分布式?

随着微服务架构的普及，一个大型业务系统往往由若干个子系统构成，这些子系统又拥有各自独立的数据库。往往一个业务流程需要由多个子系统共同完成，而且这些操作可能需要在一个事务中完成。在微服务系统中，这些业务场景是普遍存在的。此时，我们就需要在数据库之上通过某种手段，实现支持跨数据库的事务支持，这也就是大家常说的“分布式事务”。

• 2、CAP理论:

CAP理论说的是：在一个分布式系统中，最多只能满足C、A、P中的两个需求。

2.1、CAP的含义

C：Consistency 一致性

同一数据的多个副本是否实时相同。

A：Availability 可用性

可用性：一定时间内 & 系统返回一个明确的结果 则称为该系统可用。

P：Partition tolerance 分区容错性

将同一服务分布在多个系统中，从而保证某一个系统宕机，仍然有其他系统提供相同的服务。

3、分布式事务协议

3.1 2PC

2PC：叫两阶段提交协议。分布式系统的一个难点是如何保证架构下多个节点在进行事务性操作的时候保持一致性。为实现这个目的，二阶段提交算法的成立基于以下假设：

• 该分布式系统中，存在一个节点作为协调者(Coordinator)，其他节点作为参与者(Cohorts)。且节点之间可以进行网络通信。
• 所有节点都采用预写式日志，且日志被写入后即被保持在可靠的存储设备上，即使节点损坏不会导致日志数据的消失。
• 所有节点不会永久性损坏，即使损坏后仍然可以恢复。

1）第一阶段（投票阶段）

• 协调者节点向所有参与者节点询问是否可以执行提交操作(vote)，并开始等待各参与者节点的响应。
• 参与者节点执行询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志。（注意：若成功这里其实每个参与者已经执行了事务操作）
• 各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功，则它返回一个”同意”消息；如果参与者节点的事务操作实际执行失败，则它返回一个”中止”消息。

2）第二阶段（提交执行阶段）

当协调者节点从所有参与者节点获得的相应消息都为”同意”：

• 协调者节点向所有参与者节点发出”正式提交(commit)”的请求。
• 参与者节点正式完成操作，并释放在整个事务期间内占用的资源。
• 参与者节点向协调者节点发送”完成”消息。
• 协调者节点受到所有参与者节点反馈的”完成”消息后，完成事务。

如果任一参与者节点在第一阶段返回的响应消息为”中止”：

• 协调者节点向所有参与者节点发出”回滚操作(rollback)”的请求。
• 参与者节点利用之前写入的Undo信息执行回滚，并释放在整个事务期间内占用的资源。
• 参与者节点向协调者节点发送”回滚完成”消息。
• 协调者节点受到所有参与者节点反馈的”回滚完成”消息后，取消事务。

3.2 3PC

三阶段提交协议

三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。

3.3 TCC

Try Confirm Cancel

• Try：尝试待执行的业务

这个过程并未执行业务，只是完成所有业务的一致性检查，并预留好执行所需的全部资源

• Confirm：执行业务

这个过程真正开始执行业务，由于Try阶段已经完成了一致性检查，因此本过程直接执行，而不做任何检查。并且在执行的过程中，会使用到Try阶段预留的业务资源。

• Cancel：取消执行的业务

若业务执行失败，则进入Cancel阶段，它会释放所有占用的业务资源，并回滚Confirm阶段执行的操作。

TCC的案例：

代码： https://github.com/yu199195/hmily
视频： https://www.iqiyi.com/w_19rwkrfu69.html

4、解决方案：

• 全局事务：

Jta： java Transaction api

• 基于可靠的消息队列分布式事务

消息队列： 延迟、重复消费