ApsaraMQ for MQTT：基礎版/鉑金版執行個體計費

計費概述

雲Message QueueTT 版的執行個體類型有基礎版、鉑金版，各類型執行個體的差異，請參見執行個體類型。

其中基礎版和鉑金版執行個體的計費方式和計費項目均相同，具體計費項目如下：

執行個體的計費公式如下：

執行個體費用=（串連數上限單價+訊息TPS上限單價+訂閱關係數上限單價）×購買時間長度（月）

串連數上限

計費項目說明

串連數指任一時刻，在指定執行個體上存在的用戶端TCP串連的數量。串連數是瞬態值，更新周期為1分鐘。

請確保您購買的串連數上限的規格大於業務實際線上的最大串連數，避免超過規格上限值觸發限流，導致部分用戶端無法串連。

樣本

instance_a在10:00的同時線上串連數是1000個，10:01的同時線上串連數是2000個，則您需要購買的串連數上限規格需要超過2000個（例如5000個），才能保證服務正常運行。

計費單價

訊息TPS上限

計費項目說明

訊息TPS為指定執行個體下每秒鐘生產訊息量和消費訊息量之和。更新周期為1分鐘。

請確保您購買的訊息TPS上限的規格大於業務實際的訊息收發TPS峰值，避免超過規格上限值觸發限流，導致部分訊息收發失敗。

計算規則

• 訊息TPS僅涉及通過雲Message QueueTT 版收發的訊息，不涉及雲訊息佇列 RocketMQ 版收發的訊息。

• 對於QoS=1且cleanSession=false的訊息，服務端如果沒有推送成功，則儲存為離線訊息等待重試，並計算為一次訂閱訊息。

• 訊息TPS計算時，需要根據傳輸品質乘以對應倍率。具體倍率，請參見計價倍率。

  例如，若用戶端設定為QoS=2且cleanSession=true，即計價倍率為5，則用戶端生產10條訊息，生產訊息量計算為10×5=50條。

樣本

假設有5個Topic，生產者向每個Topic都發送20條訊息，每個Topic都有100個客訂閱，所有用戶端傳輸品質層級相同，計價倍率都為2。

則訊息收發量為：（Topic個數×訊息數＋Topic數×訊息數×客訂閱數）×計價倍率=（5×20＋5×20×100）×2=20200條

計費單價

訂閱關係數上限

計費項目說明

訂閱關係數為使用者在指定執行個體下註冊且保留的訂閱關係的數量。

請確保您購買的訂閱關係數上限的規格大於業務實際所需的訂閱關係數，避免超過規格上限值觸發限流，導致部分訊息收發失敗。

若您的某些用戶端不再使用且訂閱關係不需要保留，請及時清除訂閱關係，節約系統資源。具體操作，請參見訂閱關係清理。

計算規則

• 訂閱關係數的統計周期為1分鐘，每秒鐘採樣一次，取這60次採樣的最大值。

  例如，1分鐘內，第1秒訂閱關係為30，第2秒為20，第3秒為30.....第60秒為50，則當前這一分鐘的訂閱關係數為50。

• 訂閱關係數的計算維度為每個用戶端（Client ID）對每個雲Message QueueTT 版Topic的訂閱，和訊息發送情境無關。

• 同一個用戶端對於父級Topic及其子級Topic的訂閱需要分別計算訂閱關係數。

  例如，用戶端Client_1訂閱TopicA、TopicA/sub_1和TopicA/sub_2，則訂閱關係數為3。

• 根據MQTT協議，當用戶端設定cleanSession=true時，用戶端離線後服務端會清理掉該用戶端所有訂閱的Topic；如果cleanSession=false，服務端會一直保留客訂閱的Topic，並計算訂閱關係。

樣本

• 執行個體Instance_A中建立了3個Topic，TopicA、TopicB和TopicC，一共有10個用戶端接入服務端；

• 這10個用戶端每個都向TopicA、TopicB和TopicC中生產訊息；每個用戶端只訂閱TopicA和TopicB消費訊息；

則該情境下，訊息訂閱關係數為10×2=20個。

計費單價