訊息佇列在使用中的注意事項

非同步不是萬能的，實現非同步重要的手段，訊息佇列在使用中也是有很多注意事項的。

訊息佇列的瓶頸

訊息佇列至少有三處容易出現瓶頸，我們一經典的釋出/訂閱模式為例。分析一下都可能存在哪些瓶頸。

釋出 ---> 佇列 ---> 訂閱

1. 入隊瓶頸，釋出訊息佇列，處理太慢，釋出端堵塞應用程式。
2. 佇列持久化瓶頸，佇列持久化是需要寫入磁碟的，大量的密集IO操作
3. 出隊瓶頸，（茶壺煮餃子，有嘴倒不出）出隊瓶頸還包括訂閱端的處理能力，
4. 如果訂閱端的處理能力跟不上，也會出現瓶頸。

釋出端常見問題

釋出端問題表現在入隊速度影響了釋出端應用程式的效能，例如

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();
    }
}

總結

我們要儘量做到釋出，佇列與訂閱之間的平衡，才能發揮訊息佇列的優勢。