可靠MQ设计

Question

各位，

我们团队在可靠MQ的设计上，出现了一些分歧性的意见，想拿出来和大家讨论讨论：

1，消息的可靠性设计，目前有2种模式：模式1是采用Notify的方式，先发送半消息，业务操作成功后最后提交完整消息，同时提供业务操作的检查接口，这种模式实现消息的最终一致性；模式2将业务数据和消息数据先都存在业务数据库里面，通过数据库的事务保证一致性，随后将消息转发给MQ。模式1的缺点是业务侵入性高，方案比较复杂，需要重新实现；模式2的缺点是消息数据可能会散落在各个地方，包括业务系统，而且可以集成现有MQ。

2，消息去重设计，也有2种模式：模式1是消费者根据自己的业务实现去重，模式2是在消费者端增加一个数据库表专门记录已经消费过的消息，不需要消费者根据业务去做去重。

不知道大家怎么看？

Answer 1

看Notify这个词我就知道又是蛋疼的淘系同学。
方案1、各种Check让人很蛋疼，但如果内部是需要垮库事务、分布式调用的场景的，我还真离不开他。让我可以在Check接口中回滚垮库、冲正其他系统的数据。

方案2、简单，非常适合事务都集中在一个库上的业务系统。后端挂上精卫拉binlog还是杠杠的，而且还和业务数据保持一个事务，清爽！

所以，两个我都要。done。