RabbitMQ MQTT插件源碼級性能優化

最近在搞物聯網平臺，海量級別的消息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了，這樣雖然有可能損失部分數據，可是解決了消息堆積問題。