生產環境的充電樁項目一直運行平穩，用戶在H5頁面上操作，掃描充電樁，而后可以支付，進入對應的界面可以控制該充電樁的放電、停電。
具體的控制流程為，用戶在頁面通過HTTPS協議與服務器進行交互，服務器接收到請求后，組裝參數，發送消息到mqtt服務器（RabbitMQ），而后充電樁的Mqtt客戶端即可收到該條消息。充電樁對頁面的消息反饋剛好是一個相反的過程。
該項目上線后，消息的發送到硬件響應平均時間基本在2s左右（視當地的4G網絡信號）。但一天下午，小區的客戶反饋，整個過程變得特別慢，下單后放電成功，但頁面遲遲不會跳轉到放電展示的界面，而且點擊頁面停電按鈕，也不會生效。
首先，查看服務器上的H5模塊的日志，發現但凡是傳入該模塊Mqtt消息的，服務器上都已經成功處理，沒有延遲的情況。所以懷疑是當地充電樁硬件的信號問題（此前不久曾發生某小區大規模4G無信號、弱信號的情況）。為了保險，在辦公室里調試並安裝了一套硬件設備，模擬線上的情況，發現下發，響應很及時，沒有出現延遲的情況。所以當即讓現場人員檢查，但現場人員經過十幾分鍾測試，反應4G信號沒有問題。
沒辦法，只能再次多次的在辦公室進行問題復現，現場也有人員進行配合測試。結果確實發現有消息漏傳到服務器的情況。即，上傳成功的消息，服務器都處理成功，沒有上傳成功的，服務器沒有處理，頁面只能處於等待狀態並進入后續的等待處理流程。此時，為了驗證充電樁是否真的漏傳消息，還是因為什么別的原因服務器沒有處理該條消息，開啟了一個Mqtt客戶端，並設置好環境，連上生產環境的服務器后，調到對應的topic並開啟消費端，結果發現，充電樁的所有消息上傳是正常的，但服務器這邊確實沒有接收到。此時，想到會不會是有多個程序，設置了相同的clientid，同時在消費生產環境的消息。經過各個服務器（允許連入生產環境IP）的排查，發現確實有一個消費端，與生產環境的MQTT消息消費模塊分享了所有消息。將該消費端的進程kill掉，生產環境立即恢復正常。
其實，這個問題之前已多次發生，但每次都會以不盡相同的場景出現，而且由於相同終端ID消費消息策略的不同，還可能出現有些時候測試響應及時，有些響應卻很慢的情況，對排查問題造成了干擾。比如起初調試硬件mqtt消息時，由於硬件工程師對該協議細節不甚清楚，結果將所有的硬件燒錄了完全相同的代碼，即clientid也相同。這樣，當兩個以上硬件同時在線時，就相當於兩個clientId相同的消費端同時開啟，這樣原本發送給某一個消費端的消息就可能會被另一個接收，目標消費端不會有反應，而服務器在發現目標消費端沒有反應后，會啟動重發機制，最終目標消費端接收到消息后，會給人造成一種通信延遲的假象。一開始只有一個硬件調試時，一切正常，但當硬件開啟了幾個之后，就表現出網絡不暢的現象，一度懷疑是辦公區域的網絡問題。其實是幾個終端共同消費了同一通道的所有消息，導致漏收。雖然有重發機制保障整個流程能夠完整執行，但是整個過程會顯得特別卡頓，整個執行周期相當漫長。之前在使用kafka的過程中，同樣也遇到過類似的問題。
不過在大數據量處理過程中，該特性卻是一個可以用來分散流量的解決方案。比如海量終端生產數據上傳到消息隊列中，開一個消費端，可能根本無法承受這么大的數據流量，無法及時的處理，所以此時必須在不同服務器，開啟多個終端，使用相同的終端ID，才能分享並及時處理該批消息。
記錄一下，涉及消息隊列的問題排查中，這個問題點值得關注。