最近在搞物聯網平臺，海量級別的消息Push導致MQ處理速度下降，對MQ進行單隊列性能壓測，結果很不如意啊！下游設備是通過NB模塊和ESP進行雙鏈路數據採集，由於場景就是抄表，但是下游設備太多，老闆也沒給多少銀子買雲服務，所以只能自己研究一波兒了~
抄表也就意味着單Topic，進行測試的時候單個Topic消費端TPS到1.7w/s，大量的消息處於unconfirmed未確認狀態，達到了TPS上限，然後通過新增消費端仍然是無法解決，那麼就將性能瓶頸的視角轉向了MQ服務。
對於瞬間大量併發的數據平臺來說，1.7w感覺有點少，之前的處理對策是分批匯報，但是這次數據量太大，導致分批匯報也會出現這種問題。
由於之前的項目對AMQP協議有進行壓測，很明顯MQTT比AMQP低很多。研究了一下rabbitmq_mqtt插件，發現是將MQTT轉化爲AMQP放入消息隊列。那麼是轉換過程中出現了性能瓶頸嗎？
研究發現：和QOS有關，delivery_mode在源碼中是2，這表示每一條消息都要走磁盤I/O。那麼爲啥這個插件要這麼設計呢？QOS=1表示消息最少到達一次，也就是失敗後可以重發一次，消息持久化機制在Server掛掉的情況下也會保證消息不丟失，確保了QOS1的特性。但是抄表數據時累加的，而且考慮到某些數據的彙報實時性，因此放棄QOS=1方案：
// 修改src/rabbit_mqtt_processor.erl
delivery_mode(?QOS_1) -> 1;然後進行測試，結果可達4w/s的TPS，同樣硬件客戶端代碼也進行了修改，使得QOS等於0，那麼表示這個消息處理平臺只支持QOS=0了，這樣雖然有可能損失部分數據，但是解決了消息堆積問題。