最近开发新需求，在测试环境测试和解决了两个很有意思的问题，特此记录一下。
- 在数据库事务中发送MQ消息（MQ消息消费和事务提交顺序不确定）
- 问题描述
如下图所示，业务流程是在数据库读提交隔离级别下，首先插入数据，然后发送MQ消息。MQ消息中包含数据id，消费者拿到消息后根据id查数据库。
简化业务流程代码
由于MQ消息是在数据库事务中发送的，所以可能会导致MQ发送成功，消费者开始消费MQ，但是此时生产者所在的事务还未提交，所以消费者根据id查不到数据，由此产生问题。
-
产生问题的原因
数据库事务中的代码顺序是插入数据->发送MQ->提交事务，但是因为MQ发送后，消费者消费是异步的，所以并不能保证MQ消费和提交事务的顺序，有可能提交事务在前，这种情况就没有问题，消费者可以看到事务提交后的数据，但如果是MQ消费在前，事务提交在后，那MQ消费者是看不到未提交的事务数据的。 -
解决方法
最简单的方案是什么也不用做，MQ消费者消费失败的话，重新消费或者人工接入解决，当然这种方案也有问题，就是MQ发送成功，但是事务回滚...
或者可以把MQ发送放在事务之外，确保发送MQ的时候事务已经提交，也是可以的，消费失败就重新消费呗。还是不建议把发送MQ的操作放在事务里，因为可能会加大事务执行时间，有造成大事务的风险。
还有一种终极解决方案就是使用事务消息，在数据库事务中发送半消息，然后事务提交后，发送消息确认半事务消息，并提供事务回查接口。
- 消息生产者和消费消费者产生了并发修改
- 问题描述
消息生产者连续两次修改数据，并两次发送数据改动消息到消息消费者，消息消费者收到消息后，从数据库查数据并写入缓存，最后更新数据的is_cache字段。
逻辑流程简单来说是这样的：修改data.time=t1->发送MQ通知消费者将数据写入缓存->修改data.time=t2->发送MQ通知消费者将数据写入缓存。原来的本意是将data.time=t2的最终结果更新到缓存。但是最后发现，执行完毕后，数据库中的时间总是t1而不是期望的t2。
- 产生问题的原因
最终发现是消息消费者更新is_cache字段用的sql有问题，他并不是单独更新指定id的is_cache字段，而是先查数据库数据，然后修改is_cache字段，然后用数据库数据对象更新全部字段。和问题1一样，MQ消息消费是异步的，所以修改t1,t2的顺序和消息消费的顺便是不确定的，可能会产生这样的顺序：修改data.time=t1->发送MQ->消费MQ，加载数据库数据data.time=t1，写入缓存->修改data.time=t2->前面的消费者继续执行，写入缓存后更新is_cahce字段，并将data.time=t1更新回去，覆盖了data.time=t2的预期结果
最主要的还是因为消费者修改了本不属于自己要更新的字段data.time，由此和生产者产生了数据修改竞争，相当于多线程修改共享数据，造成了问题。
- 解决方案
消费者只修改更新data.is_cache字段，避免和消费者竞争修改共享字段，避免竞争。
网友评论