业务A和发送消息的事务问题

[vvsuperman]

微信里longer童鞋提出这样的问题:

1. 执行业务操作
2. 发送消息成功( 此时事务还未提交)
3. 遇到机器挂了的极端情况

此时业务操作事务还未提交，但消息已经发送了，于是出现不一致的情况

如果把提交放到前面 1 执行业务操作-> 2 提交-> 3 发送消息 但此时如果2提交后机器挂了，又会出现不一致的情况。因为发消息是一个异步的过程，是没法在一个事务中进行控制的，即使用事务的传播特性: 事务A: 事务B：执行业务操作 发送消息 B先提交，如果A失败B也会回滚。但即使这样，如果B后面一步出现断电等极端情况依然会产生不一致

考虑到断电的极端情况，必须要有第三方守护进程来进行一个判断，于是可以使用如下的逻辑：

1. db记录“我要做业务操作啦”
2. 执行业务操作
3. 发送消息
4. 如果消息成功，在消息确认时将db中“我要做业务操作啦”删除。

来看下可能的异常：如果业务成功，发送消息失败(断电等情况), 此时守护进程查到db中有一条“我要做业务操作啦”，同时业务方提供一个回查接口，并查到业务确实成功了，进行消息重发。RocketMQ就是这种解决方案，但还有一个问题：如果业务B方需要业务A的结果，但A的结果此时是无法得到的，貌似RocketMQ并未考虑该情况，所以需要在回查接口中返回这个结果，方便重发。

[LululuAlu]

三方进程来判断的话，是不是就等于实现本地消息表？