正文
随着微服务架构的普及,一个大型业务系统往往由若干个子系统构成,这些子系统又拥有各自独立的数据库。往往一个业务流程需要由多个子系统共同完成,而且这些操作可能需要在一个事务中完成。在微服务系统中,这些业务场景是普遍存在的。此时,我们就需要在数据库之上通过某种手段,实现支持跨数据库的事务支持,这也就是大家常说的“分布式事务”。
CAP理论说的是:在一个分布式系统中,最多只能满足C、A、P中的两个需求。
2.1、CAP的含义
C:Consistency 一致性
同一数据的多个副本是否实时相同。
A:Availability 可用性
可用性:一定时间内 & 系统返回一个明确的结果 则称为该系统可用。
P:Partition tolerance 分区容错性
将同一服务分布在多个系统中,从而保证某一个系统宕机,仍然有其他系统提供相同的服务。
2PC:叫两阶段提交协议。分布式系统的一个难点是如何保证架构下多个节点在进行事务性操作的时候保持一致性。为实现这个目的,二阶段提交算法的成立基于以下假设:
当协调者节点从所有参与者节点获得的相应消息都为”同意”:
如果任一参与者节点在第一阶段返回的响应消息为”中止”:
三阶段提交协议
三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。
Try Confirm Cancel
这个过程并未执行业务,只是完成所有业务的一致性检查,并预留好执行所需的全部资源
这个过程真正开始执行业务,由于Try阶段已经完成了一致性检查,因此本过程直接执行,而不做任何检查。并且在执行的过程中,会使用到Try阶段预留的业务资源。
若业务执行失败,则进入Cancel阶段,它会释放所有占用的业务资源,并回滚Confirm阶段执行的操作。
TCC的案例:
代码: https://github.com/yu199195/hmily
视频: https://www.iqiyi.com/w_19rwkrfu69.html
Jta: java Transaction api
消息队列: 延迟、重复消费