php 分布式事务 中间件,消息中间件实现分布式事务

理论基础

什么是分布式事务

传统的事务是基于单数据库的本地事务，简单的来说，分布式事务就是实现跨数据库的事务支持

CAP理论

CAP理论表面在分布式系统中，最多只能满足C，A，P中的两个

C：一致性

A：可用性

P：分区容错性：一个服务失效，可以有其他服务来代替他的工作

既然最多只能选择两个，那选择哪两个比较合适呢？对于一个分布式系统来说，可用性和分区容错性是必须要满足的。对于可用性，如果一个系统可用性都打不到，那么这个系统是没有意义的；分布式系统设计的目的就是提供多个子系统防止单个系统出现故障的情况，所以分区容错性是分布式系统的跟本，如果分区容错性都不满足，那么分布式系统将失去意义

BASE理论

在CAP理论中我们牺牲了一致性来换取可用性和分区容错性；但是牺牲一致性不是指完全放弃数据一致性，而是使用弱一致替换强一致；下面介绍一下BASE理论：

BA：基本可用，只要体现在下面两个方面：1. 响应时间可以适当延长 2. 给部分用户返回一个降级页面从而缓解服务器压力

S：柔性状态：同一数据的不同副本状态，可以不需要实时一致

E：最终一致性：同一数据的不同副本状态，可以不需要实时一致，但是经过一定的时间后一定是一致的

酸碱平衡

在单数据库事务中，我们使用ACID来保证数据的强一致性，在分布式系统中只要遵循BASE理论即可；但是在不同的场景下对一致性的要求是不一样的，例如交易场景就要求强一致性，遵循ACID理论；对于注册成功后发送短信验证码这样的业务场景不需要强一致性，遵循BASE理论即可。所以我们要根据不同的业务场景在ACID和BASE之间寻求平衡

使用消息中间件的解决方案

在我的项目中order模块用来处理订单，下完订单后，在product模块中执行相应的扣库存的操作；为了方便描述，我们把order模块称为系统A，下订单操作为任务A；product模块为系统B，扣库存操作为任务B

系统设计

在系统A处理任务A前，首先向消息中间件发送一条消息

消息中间件收到后将该条消息持久化，但并不投递。此时下游系统B仍然不知道该条消息的存在

消息中间件持久化成功后，便向系统A返回一个确认应答

系统A收到确认应答后，则可以开始处理任务A

任务A处理完成后，向消息中间件发送Commit请求。该请求发送完成后，对系统A而言，该事务的处理过程就结束了，此时它可以处理别的任务了

消息中间件收到Commit指令后，便向系统B投递该消息，从而触发任务B的执行

当任务B执行完成后，系统B向消息中间件返回一个确认应答，此时，这个分布式事务完成

如果任务A处理失败

如果任务A处理失败，那么需要进入回滚流程

若系统A在处理任务A时失败，那么就会向消息中间件发送Rollback请求。系统A发完之后便可以认为回滚已经完成，它便可以去做其他的事情

消息中间件收到回滚请求后，直接将该消息丢弃不投递给系统B

新的问题

上面所介绍的Commit和Rollback都属于理想情况，但在实际系统中，Commit和Rollback指令都有可能在传输途中丢失。那么当出现这种情况的时候，消息中间件是如何保证数据一致性呢？——答案就是超时询问机制。

系统A除了实现正常的业务流程外，还需提供一个事务询问的接口，供消息中间件调用。当消息中间件收到一条事务型消息后便开始计时，如果到了超时时间也没收到系统A发来的Commit或Rollback指令的话，就会主动调用系统A提供的事务询问接口询问该系统目前的状态。该接口会返回三种结果：

提交：若获得的状态是“提交”，则将该消息投递给系统B

回滚：若获得的状态是“回滚”，则直接将条消息丢弃

处理中：若获得的状态是“处理中”，则继续等待

投递过程的可靠性保证

我们知道当上游系统A发出commit请求之后认为事务已经完成，便可以处理其他的任务了；那么消息中间件是怎么保证消息一定会被下游系统B成功消费呢？这是使用消息中间件投递过程的可靠性来保证的

消息中间件向系统B投递完消息后便进入阻塞等待状态，如果消息在传递过程中丢失或者消息的确认应答在返回途中丢失，那么消息中间件在等待超时后会重新投递直到消息被系统B成功消费为止

为什么是重新投递而不是回滚

这就涉及到整套分布式事务系统的实现成本问题。如果回滚的话，系统A就要提供回滚接口，这增加了开发成本，业务系统的复杂度也会随之提高

异步与同步

上游系统A向消息中间件提交完消息后便可以去做别的事情。然而消息中间件将消息投递给下游系统B后，它会阻塞等待直到下游系统返回B确认应答。为什么要这么设计呢？

首先，上游系统和消息中间件之间采用异步通信是为了提高系统并发度。业务系统直接和用户打交道，用户体验尤为重要，因此这种异步通信方式能够极大程度地降低用户等待时间；

下游系统与消息中间件采用同步虽然降低系统并发度，但实现成本较低。在对并发度要求不是很高或者服务器资源较为充裕的情况下，我们可以选择使用同步来降低系统的复杂度