消息隊列在使用中的注意事項

消息隊列在使用中的注意事項

異步不是萬能的，實現異步重要的手段，消息隊列在使用中也是有不少注意事項的。

消息隊列的瓶頸

消息隊列至少有三處容易出現瓶頸，咱們一經典的發佈/訂閱模式爲例。分析一下均可能存在哪些瓶頸。

發佈 ---> 隊列 ---> 訂閱

1. 入隊瓶頸，發佈消息隊列，處理太慢，發佈端堵塞應用程序。
2. 隊列持久化瓶頸，隊列持久化是須要寫入磁盤的，大量的密集IO操做
3. 出隊瓶頸，（茶壺煮餃子，有嘴倒不出）出隊瓶頸還包括訂閱端的處理能力，
4. 若是訂閱端的處理能力跟不上，也會出現瓶頸。
5. 消息大小，每一個消息包的大小也決定了性能

發佈端常見問題

發佈端問題表如今入隊速度影響了發佈端應用程序的性能，例如

runtime {
    task1();
    task2();
    publish();
    task3();
    task4();
}



loop {
    task1();
    task2();
    publish();
    task3();
    task4();
}

上面僞代碼 publish()將阻塞 task3()與task4(),必須等待publish()執行完成才能繼續運行。

這樣的狀況是 發佈數量 > 入隊的速度， 影響發佈端的性能

隊列持久化

消息的持久化，既影響入隊速度，也影響出對速度，入隊是寫磁盤操做，出對是修改或者刪除操做。 在隊列同時進行入隊與出隊的操做是，還涉及到各類「鎖」，例如線程鎖與文件鎖等等。 最終結果是消息隊列性能驟降。

訂閱端性能

訂閱端的處理能力也影響到隊列的堆積程度。若是訂閱端處理速度過慢，咱們就會發現消息在隊列中堆積。

loop {
    function sub_callback(){
        task1();
        task2();
        task3();
        task4();
    }
}

訂閱端改進，將隊列交給線程處理

threads[max_connet] {
    function sub_callback(){
        task1();
        task2();
        task3();
        task4();
    }
}

消息的大小

咱們應該儘可能減少消息的體積，例如選擇輕量的協議，超過必定體積作壓縮處理。

就消息協議而言, 二進制協議 < 文本協議。而文本協議中 json < xml 等等。

xml 成對出現的閉合標籤佔用了大量的空間，二進制的 msgpack 也好於文本的 json。 選擇使用那種協議還要看你的場景。

另外還須要注意的就是 序列化/反序列化的開銷。

總結

咱們要儘可能作到發佈，隊列與訂閱之間的平衡，才能發揮消息隊列的優點。

做者

陳景峯，暱稱 Netkiller, 英文名 Neo 《Netkiller 系列 手札》電子書的做者，讀者QQ羣：128659835，我的網站：http://netkiller.github.io/

轉載請註明出處與做者聲明