529
熱門問題：MNS隊列消息計數實現難點淺析
MNS提供GetQueueAttributes接口，用於獲取隊列的基本屬性信息以及隊列的消息數狀態（可見消息，不可見消息，延遲消息），並不是精確值，而是隻能反映隊列中消息數狀態的近似值。很多用戶可能都會對消息計數不準確而耿耿於懷，小編1. 分布式環境下，強一致性難達到
MNS是基於阿裏雲飛天分布式平台上的消息服務，具有高並發、高可擴展等優點，別看大家平常隻是向一個URL地址收發消息，但台Message Server為大家提供服務；各個Message Server會將用戶發送的消息數據持久化，同時在內存中維護了實時
在MNS中，隊列中消息是有過期時間的，如果長時間消息未消費，則消息將變為過期消息，將會被MNS係統回收掉。為了保證消息消費的效率，MNS並不會立刻對過期消息進行回收，隻是在保證過期消息不會被用戶消費到的前提下，MessageServer後台會有專門的GC模塊負責定期回收各個隊列的過期消息並修改消息計數（如圖2）。這就造成了如果存在過期消息，在消息未被回收之前，過期消息還是會體現在消息計數中。
（圖2）
以上兩點就是MNS目前遇到消息計數不精確的主要問題；同時國外的雲計算A公司在其隊列服務中提供的也是近似值（如:ApproximateNumberOfMessages）。應用程序如果強依賴於隊列消息計數，並不是分布式高並發環境下最佳選擇，用戶隻需要通過長輪詢ReceiveMessage接口獲取數據即可，如果隊列為空，則ReceiveMessage請求將會在MNS端掛起一段時間，期間有任何消息進入隊列，掛起的請求都將立刻返回最新的消息；而MNS在隊列屬性中提供消息計數的初衷主要是提供一個能夠大致反映隊列堆積情況的，特別當隊列計數接入了雲監控之後，用戶可以輕鬆通過設置雲監控報警來實現隊列堆積情況預警；同時在針對消息積壓情況進行收費時，我們也是充分考慮到了消息計數可能造成的偏差，目前在MNS的收費用戶當中，由於消息積壓情況導致收費的並不多，而且也確確實實是堆積了大量消息。但是鑒於計數問題是MNS用戶反映最多的問題，所以MNS後續將會推出隊列計數最終一致性保障機製。
大家如果對本文有任何疑問，都可以在帖子中提出，小編會第一時間回複，感謝大家對MNS的支持！我們會不斷提升MNS的用戶體驗，推出更多符合用戶使用場景的功能！
最後更新：2017-04-01 13:38:50