使用消息队列后引发的血案

我们公司有一个项目，用到了消息队列，经常会遇到很多坑，难以排查，下面我详细描述一下心路历程。

首先介绍一下这个项目，简单的讲，有A,B两个工程组成,A工程轮训监听数据库，一旦有改动就推消息给B，然后B工程会接受到这条消息后处理自己的逻辑，最后写入数据库。

然后出现的问题有好几个。
首先第一个是我们的测试环境有好几套，然后有另外的几套也在用这个consumerId，导致消息老是被其他环境消费掉，它们的代码又不是最新的，导致数据库的数据有问题。

于是乎我们后来每个环境都用了自己的队列，然后问题还是没有解决。因为A工程统一发消息到队列后，尽管各个环境的consumerId不同，但是消息会群发到所有订阅这个topic的consumer，所以在我的环境处理更新完数据后又会被别的环境覆盖掉，哭。

最后为了测试，临时解决方案就是先把别的机子先停掉。终极解决方案肯定要各个数据库也分离，这样数据就不会被覆盖了。

有小伙伴可能对消息队列不够熟悉，我这里简单贴一下

• 生产者

Producer将消息发布到它指定的topic中,并负责决定发布到哪个分区。通常简单的由负载均衡机制随机选择分区，但也可以通过特定的分区函数选择分区。使用的更多的是第二种。

• 消费者

发布消息通常有两种模式：队列模式（queuing）和发布-订阅模式(publish-subscribe)。队列模式中，consumers可以同时从服务端读取消息，每个消息只被其中一个consumer读到；发布-订阅模式中消息被广播到所有的consumer中。Consumers可以加入一个consumer 组，共同竞争一个topic，topic中的消息将被分发到组中的一个成员中。同一组中的consumer可以在不同的程序中，也可以在不同的机器上。如果所有的consumer都在一个组中，这就成为了传统的队列模式，在各consumer中实现负载均衡。如果所有的consumer都不在不同的组中，这就成为了发布-订阅模式，所有的消息都被分发到所有的consumer中。更常见的是，每个topic都有若干数量的consumer组，每个组都是一个逻辑上的“订阅者”，为了容错和更好的稳定性，每个组由若干consumer组成。这其实就是一个发布-订阅模式，只不过订阅者是个组而不是单个consumer。