我們公司有一個項目，用到了消息隊列，經常會遇到很多坑，難以排查，下面我詳細描述一下心路歷程。
首先介紹一下這個項目，簡單的講，有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。
