本文介紹云消息隊列 RocketMQ 版中隊列（MessageQueue）的定義、模型關系、內部屬性、版本兼容性及使用建議。
定義
隊列是云消息隊列 RocketMQ 版中消息存儲和傳輸的實際容器，也是云消息隊列 RocketMQ 版消息的最小存儲單元。
云消息隊列 RocketMQ 版的所有主題都是由多個隊列組成，以此實現隊列數量的水平拆分和隊列內部的流式存儲。
隊列的主要作用如下：
存儲順序性
隊列天然具備順序性，即消息按照進入隊列的順序寫入存儲，同一隊列間的消息天然存在順序關系，隊列頭部為最早寫入的消息，隊列尾部為最新寫入的消息。消息在隊列中的位置和消息之間的順序通過位點（Offset）進行標記管理。
流式操作語義
云消息隊列 RocketMQ 版基于隊列的存儲模型可確保消息從任意位點讀取任意數量的消息，以此實現類似聚合讀取、回溯讀取等特性，這些特性是RabbitMQ、ActiveMQ等非隊列存儲模型不具備的。
模型關系
在整個云消息隊列 RocketMQ 版的領域模型中，隊列所處的流程和位置如下：
云消息隊列 RocketMQ 版默認提供消息可靠存儲機制，所有發送成功的消息都被持久化存儲到隊列中，配合生產者和消費者客戶端的調用可實現至少投遞一次的可靠性語義。
云消息隊列 RocketMQ 版隊列模型和Kafka的分區（Partition）模型類似。在云消息隊列 RocketMQ 版消息收發模型中，隊列屬于主題的一部分，雖然所有的消息資源以主題粒度管理，但實際的操作實現是面向隊列。例如，生產者指定某個主題，向主題內發送消息，但實際消息發送到該主題下的某個隊列中。
云消息隊列 RocketMQ 版中通過修改隊列數量，以此實現橫向的水平擴容和縮容。
內部屬性
定義：當前隊列是否可以讀寫數據。
取值：由服務端定義，枚舉值如下
6：讀寫狀態，當前隊列同時允許寫入消息和讀取消息操作。
4：只讀狀態，當前隊列只允許讀取歷史消息，不允許向隊列寫入新的消息。
2：只寫狀態，當前隊列只允許寫入新消息，不允許讀取消息。
0：不可讀寫狀態，當前隊列不允許任何讀寫操作。
約束：隊列的讀寫權限屬于運維側操作，不建議頻繁修改。
行為約束
每個主題下會由一到多個隊列來存儲消息，每個主題對應的隊列數與消息類型以及實例所處地域（Region）相關，隊列數暫不支持修改。
版本兼容性
隊列的名稱屬性在云消息隊列 RocketMQ 版服務端的不同版本中有如下差異：
服務端3.x/4.x版本：隊列名稱由{主題名稱}+{BrokerID}+{QueueID}三元組組成，和物理節點綁定。
服務端5.x版本：隊列名稱為一個集群分配的全局唯一的字符串組成，和物理節點解耦。
因此，在開發過程中，建議不要對隊列名稱做任何假設和綁定。如果您在代碼中自定義拼接隊列名稱并和其他操作進行綁定，一旦服務端版本升級，可能會出現隊列名稱無法解析的兼容性問題。
使用建議
按照實際業務消耗設置隊列數
云消息隊列 RocketMQ 版的隊列應遵循少用夠用原則，避免隨意增加隊列數量。
主題內隊列數過多可能導致如下問題：
集群元數據膨脹
云消息隊列 RocketMQ 版會以隊列粒度采集指標和監控數據，隊列過多容易造成管控元數據膨脹。
客戶端壓力過大
云消息隊列 RocketMQ 版的消息讀寫都是針對隊列進行操作，隊列過多容易產生空輪詢請求，增加系統負荷。
常見隊列增加場景
需要增加隊列實現物理節點負載均衡
云消息隊列 RocketMQ 版每個主題的多個隊列可以分布在不同的服務節點上，在集群水平擴容增加節點后，為了保證集群流量的負載均衡，建議在新的服務節點上新增隊列，或將舊的隊列遷移到新的服務節點上。
需要增加隊列實現順序消息性能擴展
在云消息隊列 RocketMQ 版服務端4.x版本中，順序消息的順序性在隊列內生效的，因此順序消息的并發度會在一定程度上受隊列數量的影響，因此建議僅在系統性能瓶頸時再增加隊列。
非順序消息消費的負載均衡與隊列數無關
云消息隊列 RocketMQ 版服務端5.x系列實例的消費者負載均衡已升級為消息粒度負載均衡，同一隊列內的消息可以被所有消費者均勻消費。因此，您無需擔心隊列數對消費并發度的影響。負載均衡詳細信息，請參見消費者負載均衡。