本文為您介紹雲訊息佇列 RocketMQ 版中訊息的儲存機制，包括訊息的儲存粒度、判斷依據及後續處理策略等。
背景資訊
參考雲訊息佇列 RocketMQ 版中隊列的定義，訊息按照達到伺服器的先後順序被儲存到隊列中，理論上每個隊列都支援無限儲存。
但是在實際部署情境中，服務端節點的實體儲存體空間有限，訊息無法做到永久儲存。因此，在實際使用中需要考慮以下問題，訊息在服務端中的儲存以什麼維度為判定條件？訊息儲存以什麼粒度進行管理？訊息儲存超過限制後如何處理？這些問題都是由訊息儲存和到期清理機制來定義的。
- 提供訊息儲存時間SLA，為業務提供安全冗餘空間：訊息儲存時間的承諾本質上代表業務側可以自由擷取訊息的時間範圍。對於消費時間長、訊息堆積、故障恢複等情境非常關鍵。
- 評估和控制儲存成本：雲訊息佇列 RocketMQ 版訊息一般儲存於磁碟介質上，您可以通過儲存機制評估訊息儲存空間，提前預留儲存資源。
訊息儲存機制
原理機制
雲訊息佇列 RocketMQ 版使用儲存時間長度作為訊息儲存的依據，即每個節點對外承諾訊息的儲存時間長度。在儲存時間長度範圍內的訊息都會被保留，無論訊息是否被消費；超過時間長度限制的訊息則會被清理掉。
訊息儲存機制主要定義以下關鍵問題：
- 訊息儲存管理粒度：雲訊息佇列 RocketMQ 版按儲存節點管理訊息的儲存時間長度，並不是按照主題或隊列粒度來管理。
- 訊息儲存判斷依據：訊息儲存按照儲存時間作為判斷依據，相對於訊息數量、訊息大小等條件，使用儲存時間作為判斷依據，更利於業務方對訊息資料的價值進行評估。
- 訊息儲存和是否消費狀態有關：雲訊息佇列 RocketMQ 版的訊息儲存是按照訊息的生產時間計算，和訊息是否被消費無關。按照統一的計算策略可以有效地簡化儲存機制。
訊息儲存管理粒度說明
- 訊息儲存優勢權衡：雲訊息佇列 RocketMQ 版基於統一的物理日誌隊列和輕量化邏輯隊列的二級組織方式，管理物理資料。這種機制可以帶來順序讀寫、高吞吐、高效能等優勢，但缺點是不支援按主題和隊列單獨管理。
- 安全生產和容量保障風險要求：即使雲訊息佇列 RocketMQ 版按照主題或者隊列獨立產生隱藏檔，但儲存層本質還是共用儲存介質。單獨根據主題或隊列控制儲存時間長度，這種方式看似更靈活，但實際上整個叢集仍然存在容量風險，可能會導致儲存時間長度SLA被打破。從安全生產角度考慮，最合理的方式是將不同儲存時間長度的訊息通過不同叢集進行分離治理。
訊息儲存和消費狀態關係說明
雲訊息佇列 RocketMQ 版統一管理訊息的儲存時間長度，無論訊息是否被消費。
當消費者不線上或訊息消費異常時，會造成隊列中大量訊息堆積，且該現象暫時無法有效控制。若此時按照消費狀態考慮將未消費的訊息全部保留，則很容易導致儲存空間不足，進而影響到新訊息的讀寫速度。
根據統一地儲存時間長度管理訊息，可以協助消費者業務清晰地判斷每條訊息的生命週期。只要訊息在有效期間內可以隨時被消費，或通過重設消費位點功能使訊息可被消費多次。
訊息到期清理機制
開源的Apache RocketMQ中，訊息儲存時間長度並不能完整控制訊息的實際儲存時間，因為訊息儲存仍然使用本地磁碟，本地磁碟空間不足時，為保證服務穩定性訊息仍然會被強制清理，導致訊息的實際儲存時間長度小於設定的儲存時間長度。
而雲訊息佇列 RocketMQ 版基於阿里雲雲原生自研的儲存系統，支援所有執行個體按需按量使用儲存空間，儲存容量無上限約束。因此所有訊息將嚴格按照約定的儲存時間進行儲存，無需擔心因為儲存空間不足訊息被刪除的情況出現。
使用建議
訊息儲存時間長度建議適當增加
雲訊息佇列 RocketMQ 版按儲存時間長度統一控制訊息是否保留。建議在儲存成本可控的前提下，儘可能延長訊息儲存時間長度。延長訊息儲存時間長度，可以為緊急故障恢複、應急問題排查和訊息回溯帶來更多的可操作空間。