使用雲訊息佇列 Kafka 版時有哪些限制條件 - ApsaraMQ for Kafka

雲訊息佇列 Kafka 版對某些具體指標進行了約束和規範，您在使用雲訊息佇列 Kafka 版時注意不要超過相應的限制值，以免程式出現異常。

重要

若由於您的執行個體配置超出下列限制導致的任何不穩定情況，不在SLA承諾和賠償範圍內。

使用限制

雲訊息佇列 Kafka 版的限制項和限制值，請參見下表。

限制項	限制值	說明
限制Topic總數（分區總數）	支援	雲訊息佇列 Kafka 版的儲存和協調機制是以分區為粒度的，Topic總數（分區總數）太多，會導致儲存片段化，叢集效能和穩定性下降。
Topic分區數最小值	訂用帳戶、隨用隨付： Topic為雲端儲存，最小值為2。 Topic為local 儲存，最小值為1。 serverless版： Topic為雲原生儲存，最小值為1。	如果流量過大，單分區可能導致資料扭曲熱點問題。建議合理設定分區數量。
Topic減少對應分區	不支援	這是Apache Kafka自身設計所限制的。
暴露ZooKeeper	不支援	在使用設計層面，Apache Kafka自0.9.0之後已經屏蔽掉ZooKeeper，即用戶端使用無需訪問ZooKeeper。雲訊息佇列 Kafka 版的ZooKeeper是部分共用的，出於安全考慮，不予暴露。您也無需感知到ZooKeeper。
登入部署雲訊息佇列 Kafka 版的機器	不支援	無。
版本	支援2.2.x版本~3.3.x版本	非Serverless執行個體支援2.2.x~2.6.x版本。 Serverless執行個體支援3.3.x版本。如需升級版本，請參見升級執行個體版本。
分區數量和Topic數量的對應關係	1∶1	可使用的Topic數量與總分區數強相關。例如，您購買了分區數為50、流量規格為alikafka.hw.2xlarge、規格內贈送分區數為1000的執行個體，那麼該執行個體總分區數=購買分區數+規格內贈送分區數=50+1000=1050，可用Topic數量為1050。說明僅非Serverless執行個體適用。
變更執行個體的地區	不支援	執行個體購買部署之後，其地區與實體資源緊密結合，無法變更。如需變更執行個體的地區，請釋放執行個體，並重新購買。
變更執行個體網路屬性	支援	網路屬性可以根據需要變更。具體操作，請參見升級執行個體配置。
訊息大小	10 MB	訊息大小不得超過10 MB，否則訊息會發送失敗。
監控警示	支援	資料延時1分鐘。
存取點	購買規格	非Serverless執行個體：標準版：支援預設存取點、SSL存取點。專業版：支援預設存取點、SSL存取點、SASL存取點。 Serverless執行個體：支援預設存取點、SSL存取點、SASL存取點。
雲端儲存單分區	宕機和升級時可能導致不可用	建議建立的分區數大於1，如果強依賴單分區，可以使用Local儲存。說明僅非Serverless執行個體存在此限制，Serverless執行個體的雲端儲存單分區具有高可用性。僅專業版執行個體支援在建立Topic時將儲存引擎類型選擇為Local儲存，標準版暫不支援。
單Batch最大訊息條數限制	32767	如果單條訊息過小時，建議`batch.size`設定不要超過16384。說明僅非Serverless執行個體存在此限制。

說明

雲訊息佇列 Kafka 版非Serverless執行個體不再支援按照Topic規格購買執行個體，若您的已有執行個體是按照Topic規格購買的，那麼Topic數量與分區數量的對應關係為1∶16，專業版執行個體Topic數量=購買Topic數量×2。

配額限制

下表列舉了雲訊息佇列 Kafka 版使用限制項，超出下列使用限制可能會產生穩定性問題。其他限制中列舉了部分可能對服務端造成不良影響的使用情境，需要謹慎使用避免造成服務端過載引發穩定性問題。

除非另有說明，限制都是針對每個叢集的。如需更大的配額，請提交工單諮詢。

表格中出現的“//”表示整數除法，即向下取整。

限制項	限制條件				說明
限制項	訂用帳戶/按小時後付費執行個體	Serverless（基礎版）	Serverless（標準版/專業版）	是否強限制	說明
串連數（單節點）	起始串連數為1000。業務實際發送流量每增加100 MB/s，串連數增加1000。上限為10000。計算公式： `C = min(10000, 1000 + (F // 100) * 1000)`	起始串連數為2000。發送能力預留每增加300 MB/s，串連數增加1000。上限為10000。計算公式： `C = min(10000, 2000 + (F // 300) * 1000)`		是	單台Broker的TCP串連數。如需更大串連數上限，請提交工單申請。超過串連數上限後，新串連會緩慢建連，老串連會被LRU kill。
SSL串連數（單節點）	起始串連數為200。業務實際發送流量每增加100 MB/s，串連數增加100。上限為1000。計算公式： `C = min(1000, 200 + (F // 100) * 100)`	起始串連數為200。發送能力預留每增加300 MB/s，串連數增加100。上限為1000。計算公式： `C = min(1000, 200 + (F // 300) * 100)`		是	單台Broker的SSL TCP串連數。超過串連數上限後，新串連會緩慢建連，老串連會被LRU kill。
建立串連頻率（單節點）	50次/秒	150次/秒	150次/秒	是	每秒用戶端與服務端嘗試建立串連次數（包含因鑒權失敗等原因導致的失敗串連）。超過串連數上限後，新串連會緩慢建連。
SSL建立串連頻率（單節點）	10次/秒			是	每秒用戶端與服務端嘗試建立 SSL 串連次數（包含因鑒權失敗等原因導致的失敗串連）。超過串連數上限後，新串連會緩慢建連。
batch size	batch size TP50=4 KB以下定義為片段化發送			否	發送用戶端攢批後PRODUCE請求中攜帶的訊息batch大小。可能導致服務端 CPU 負載上升，影響叢集穩定性。推薦使用2.4以上的用戶端版本，提升batch攢批能力，請參見提升發送效能（減少片段化發送請求）。
發送請求頻率（叢集）	起始為每秒10000個請求。業務實際發送流量每增加20 MB/s，每秒請求數量增加2000個。計算公式： `R = 10000 + (F // 20) * 2000`	起始為每秒10000個請求。發送能力預留每增加300 MB/s，每秒請求數量增加5000個。計算公式： `R = 10000 + (F // 300) * 5000`	起始為每秒10000個請求。發送能力預留每增加60 MB/s，每秒請求數量增加2000個。計算公式： `R = 10000 + (F // 60) * 2000`	否	用戶端每秒發送PRODUCE的請求數量。可能導致服務端 CPU 負載上升，影響叢集穩定性。如需更大請求數上限，請提交工單申請。
消費請求頻率（叢集）	起始為每秒5000個請求。業務實際消費流量每增加20 MB/s，每秒請求數量增加1000個。計算公式： `R = 5000 + (F // 20) * 1000`	起始為每秒5000個請求。訂閱能力預留每增加100 MB/s，每秒請求數量增加2500個。計算公式： `R = 5000 + (F // 100) * 2500`	起始為每秒5000個請求。訂閱能力預留每增加20 MB/s，每秒請求數量增加1000個。計算公式： `R = 5000 + (F // 20) * 1000`	否	用戶端每秒消費FETCH的請求數量。可能導致服務端 CPU 負載上升，影響叢集穩定性。如需更大請求數上限，請提交工單申請。
提交消費位點頻率（單節點）	起始為每秒100個請求。業務實際發送流量每增加100 MB/s，每秒請求數量增加100個。上限每秒1000個請求。計算公式： `R = min(1000, 100 + (F // 100) * 100)`	起始為每秒100個請求。發送能力預留每增加100 MB/s，每秒請求數量增加100個。上限每秒1000個請求。計算公式： `R = min(1000, 100 + (F // 100) * 100)`		否	用戶端每秒發送 OFFSET_COMMIT 的請求數量。可能導致服務端 CPU 負載上升，影響叢集穩定性。如需更大請求數，請提交工單申請。
中繼資料request頻率（叢集）	起始為每秒100個請求。業務實際發送流量每增加100 MB/s，每秒請求數量增加100個。上限每秒1000個請求。計算公式： `R = min(1000, 100 + (F // 100) * 100)`	起始為每秒100個請求。發送能力預留每增加100 MB/s，每秒請求數量增加100個。上限每秒1000個請求。計算公式： `R = min(1000, 100 + (F // 100) * 100)`		否	服務端收到的用戶端中繼資料request，例如`METADATA，INIT_PRODUCER_ID，CREATE_ACL，JOIN_GROUP` 等。警告如果請求過於頻繁，會影響叢集穩定性。
最大分區數	各規格執行個體的最大分區數請參見執行個體分區數。			是	分區數包括使用者建立的不同類型Topic的分區。超過上限無法建立 Topic，無法擴容分區。如需更大分區上限數，請提交工單申請。
建立/刪除分區頻率（叢集）	900分區（每10秒）			否	包含控制台，OpenAPI、Kafka Admin等所有分區操作。
consumer group數量（叢集）	2000/叢集 Topic和Group的訂閱比建議 1：1，不超過 3：1。			否	使用者使用的Group數量。如需更大Group上限數，請提交工單申請。警告過多的消費者組可能導致服務端協調負載增加、中繼資料管理複雜性提高，從而影響效能和故障恢復。
訊息格式版本	發送訊息和消費訊息格式版本需大於V1			是	推薦使用2.4以上的用戶端版本。警告使用較低版本的Kafka訊息格式可能導致無法發送或消費訊息，服務端CPU上升、吞吐效能下降及相容性和安全性等問題。
無效訊息體時間戳記攔截	當`message.timestamp.type= CreateTime`時，Broker收到訊息時的時間戳記與訊息中指定的時間戳記之間的最大差值超過配置的參數值`message.timestamp.difference.max.ms`，會拒絕寫入這條訊息。此配置用於防止時間戳記的誤設定，如果時間戳記設定太小，LogSegment會立刻被刪除，如果設定太大，LogSegment將無法被刪除。			是	用戶端有明確報錯：INVALID_TIMESTAMP(32, "The timestamp of the message is out of acceptable range.", InvalidTimestampException::new)
Compact Topic 大小限制	預設不開放 CompactTopic			是	為了防止 Compact Topic 異常寫入，導致叢集儲存寫滿而宕機。預設不開放 CompactTopic 如有特殊需要，請提交工單申請。
其他限制	開啟GZIP等壓縮演算法會消耗更多的服務端資源，從而影響業務延遲和吞吐。大量高頻率初始化事務`Producer Id`可能造成記憶體溢出導致服務端過載，影響穩定性。因此我們將核心參數`transactional.id.expiration.ms`調整為 60 min，如有特殊需求，請提交工單諮詢。如果執行個體CPU使用率超過85%，則可能對執行個體叢集的穩定性產生影響，如宕機、發送消費長尾延遲抖動等異常問題。 Kafka的效能由叢集提供支援，如果使用者的發送行為或者分區分配存在傾斜等問題，則難以充分發揮叢集的最大能力。開源事務訊息存在大量已知且尚未修複的問題，建議謹慎使用，例如KAFKA-12671。更多問題，請參見KAFKA ISSUES。 Kafka在許多情境中可能會出現訊息重複消費的現象，例如在Rebalance情境中。為了避免因訊息重複消費對業務產生影響，建議在消費邏輯中實現等冪性校正。			否	無