非同步不是萬能的，實現非同步重要的手段，訊息佇列在使用中也是有很多注意事項的。
訊息佇列至少有三處容易出現瓶頸，我們一經典的發布/訂閱模式為例。分析一下都可能存在哪些瓶頸。
發布 ---> 佇列 ---> 訂閱
入隊瓶頸，發布訊息佇列，處理太慢，發布端堵塞應用程式。
佇列持久化瓶頸，佇列持久化是需要寫入磁碟的，大量的密集io操作
出隊瓶頸，（茶壺煮餃子，有嘴倒不出）出隊瓶頸還包括訂閱端的處理能力，
如果訂閱端的處理能力跟不上，也會出現瓶頸。
訊息大小，每個訊息包的大小也決定了效能
發布端問題表現在入隊速度影響了發布端應用程式的效能，例如
runtime
loop
這樣的情況是 發布數量 > 入隊的速度， 影響發布端的效能
訊息的持久化，既影響入隊速度，也影響出對速度，入隊是寫磁碟操作，出對是修改或者刪除操作。 在佇列同時進行入隊與出隊的操作是，還涉及到各種「鎖」，例如執行緒鎖與檔案鎖等等。 最終結果是訊息佇列效能驟降。
訂閱端的處理能力也影響到佇列的堆積程度。如果訂閱端處理速度過慢，我們就會發現訊息在佇列中堆積。
loop
}
threads[max_connet]
}
就訊息協議而言, 二進位制協議 < 文字協議。而文字協議中 json < xml 等等。
xml 成對出現的閉合標籤占用了大量的空間，二進位制的 msgpack 也好於文字的 json。 選擇使用那種協議還要看你的場景。
另外還需要注意的就是 序列化/反序列化的開銷。
我們要盡量做到發布，佇列與訂閱之間的平衡，才能發揮訊息佇列的優勢。
作者陳景峰，暱稱 netkiller, 英文名 neo 《netkiller 系列 手札》電子書的作者，個人**：
在NDK中編譯的注意事項。
因為專案需要，需要編譯乙個在應用中調的可執行檔案。在原始碼中編譯出來的可執行檔案，不能直接在應用中呼叫，會報乙個magic什麼的錯誤。需要在ndk環境中編譯。編譯中容易出現的錯誤 undefined reference to talloc free 這個困擾我最久，網上說法很多，但是最後我發現，其實...
迴圈佇列 使用原因與注意事項
問題描述 迴圈佇列是一般佇列的變種吧，就是將佇列首尾相連了，貌似這樣就不必考慮佇列滿而無法使用了，因為到了佇列尾又會迴圈回到佇列首。在嵌入式底層 實現中，一些串列埠資料特別是串列埠，用到迴圈佇列的情況還是蠻多的。當然，這只是一種資料結構，用在 都得看具體用途和是否能帶來好處。為了更深一步的對這一結構...
MQ 重試佇列注意事項
不要過度依賴訊息佇列的重試來保證最終消費成功 舉個例子，我們的消費訊息佇列的應用a依賴於應用b的某個介面，但是雙十一流量太大，應用b的介面qps不足，導致rpc超時返回 即本條訊息消費失敗 此條訊息會進入重試佇列。進入重試佇列不是萬能的 問題一 rocketmq重試16次還是不成功就會認為訊息消費不...