通常会有这样的场景，一个mysql的写操作，加上一个mq的消息发送，那么这两个执行的先后顺序就是关键，以rocketmq为例。

1.先写数据库，再发消息，乍一看很好，插入数据库失败就不发消息，发消息失败数据库跟着回滚，能保证一致性。但有一种情况，数据库写入成功了，但是发消息时网络不稳定，半天没回应，此时数据库事务也没commit，导致数据库连接资源占用了比较长的时间，如果又在高并发的情况下，可能会引起雪崩。

2.先发消息，再写数据库，这种虽然不存在长时间占用数据库连接资源，但明显就不靠谱，要是消息发送成功了，但数据库写入异常回滚，那数据就不一致了，还得想办法补偿回滚消息，那样业务就更复杂了，这种方案pass。

3.结合两种方案，使用rocketmq的事务消息，第一步先发送一个half消息，这就具备了第二种方案的优点，不会提前占用了数据库连接资源，第二步在rocketmq的回调中执行数据库业务写入操作，成功后commit，并且告知mq，将half消息置位可见，消费者便可消费了；若数据库操作异常，那么同样通过返回值告知mq失败，mq会删除掉那条half消息，保证了数据一致性。还有一种情况，在此次回调中，客户端和mq服务器那边通信出现问题，那么mq服务端会请求客服端，在另一个回调中针对这种情况进行处理，此时代码可以通过消息中携带的key来查询数据库，看看对应数据是否已经成功写入，然后返回mq服务端，让他知道是该让half消息可见，还是删除它， 并且rocketmq服务端的这次回查，会隔一段时间做一次（还是half消息的话），也具备一定的可靠性。