我們公司有乙個專案，用到了訊息佇列，經常會遇到很多坑，難以排查，下面我詳細描述一下心路歷程。
首先介紹一下這個專案，簡單的講，有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。
signed unsigned 引發的血案
bug描述 問題產生於區域網傳輸一幅。服務端負責傳送，是由另乙個同事用c 寫的，我用c 寫接收客戶端。我們約定在傳輸一幅前，先傳固定4個位元組的size資訊，然後傳資料。結果發現有些總是末尾壞掉一截或是乾脆就傳不過來。bug原因 在我接收到size 4 後，我採用了size size 3 256 2...
merge all引發的血案
在訓練深度神經網路的時候，我們經常會使用dropout，然而在test的時候，需要把dropout撤掉.為了應對這種問題，我們通常要建立兩個模型，讓他們共享變數。詳情.為了使用tensorboard來視覺化我們的資料，我們會經常使用summary，最終都會用乙個簡單的merge all函式來管理我們...
parseInt引發的血案
今天做了個專題活動,頁面頭上有個倒計時 專題做完後上線了,沒發現有什麼問題,結果,運營mm突然和我說 技術哥哥出問題了,360瀏覽器在秒數從10到09的時候直接變成 00 了 一看我去真的,該死的360 還有ie7 這個倒計時的原理是先獲取系統時間.分鐘,秒,毫秒賦值在span上面 span id ...