事务型消息及分布式事务理论
异步化事务型消息模型
事务型消息
分布式事务消息适用于所有对数据最终一致性有强需求的场景。
- 半事务消息：暂不能投递的消息，发送方已经成功地将消息发送到了消息队列RocketMQ版服务端，但是服务端未收到生产者对该消息的二次确认，此时该消息被标记成“暂不能投递”状态，处于该种状态下的消息即半事务消息。
- 消息回查：由于网络闪断、生产者应用重启等原因，导致某条事务消息的二次确认丢失，消息队列RocketMQ版服务端通过扫描发现某条消息长期处于“半事务消息”时，需要主动向消息生产者询问该消息的最终状态（Commit或是Rollback），该询问过程即消息回查。
事务型消息交互流程
- 发送方将半事务消息发送至消息队列RocketMQ版服务端。
- 消息队列RocketMQ版服务端将消息持久化成功之后，向发送方返回Ack确认消息已经发送成功，此时消息为半事务消息。
- 发送方开始执行本地事务逻辑。
- 发送方根据本地事务执行结果向服务端提交二次确认（Commit或是Rollback），服务端收到Commit状态则将半事务消息标记为可投递，订阅方最终将收到该消息；服务端收到Rollback状态则删除半事务消息，订阅方将不会接受该消息。
事务消息回查步骤如下：
- 在断网或者是应用重启的特殊情况下，上述步骤4提交的二次确认最终未到达服务端，经过固定时间后服务端将对该消息发起消息回查。
- 发送方收到消息回查后，需要检查对应消息的本地事务执行的最终结果。
- 发送方根据检查得到的本地事务的最终状态再次提交二次确认，服务端仍按照步骤4对半事务消息进行操作。
RocketMQ消息的最终状态
分布式事务
BASE 理论
- Basically Available(基本可用)
- Soft state(软状态)
- Eventually consistent(最终一致性)
基本可用 是指不追求强可用性，而且强调系统基本能够一直运行对外提供服务。当分布式系统遇到不可预估的故障时，允许一定程度上的不可用，比如：对请求进行限流排队，对非核心服务进行降级。
软状态 是指允许系统中的数据存在中间状态，而不是事务的原子性：要么全部成功，要不全部不成功。
最终一致性 是指数据不可能一直都是软状态，必须在一个时间期限之后达到各个节点的一致性，在此之后，所有的节点的数据都是一致的，系统达到最终一致性。
BASE 理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。