Restrictions
To avoid various special exceptions caused by undefined behaviors in the production environment, AutoMQ for Kafka imposes certain constraints and specifications on parameters, quotas, and behaviors within the product scope. Users need to be mindful of not breaking these constraints during use. If any factual situation does not meet these constraints, please promptly submit a support ticket for assistance.
Parameter Restrictions
The following parameters, including naming and remarks for each resource, have restriction values that cannot be adjusted. Please set them strictly according to the specifications to avoid system processing anomalies caused by special characters or exceeding length limits. Most of the parameter limitations defined within the AutoMQ for Kafka product are derived from Apache Kafka. The constraints on some parameters specific to AutoMQ Cloud are detailed below.
Instance-Level Configuration
| Parameter | Limit Values | Explanation |
|---|---|---|
| log.retention.ms Message retention duration |
| The duration for which messages are retained affects storage space consumption and costs. It is recommended to perform a reasonable business evaluation. If requirements are unmet, please Obtain Services▸ for assistance. |
| message.max.bytes Maximum message size |
| If the current parameter limits do not meet requirements, please Obtain Services▸ for assistance. |
| offsets.retention.minutes Offset retention period |
| |
| fetch.max.bytes Maximum data per fetch |
| |
| Single Partition Write Throughput Limit |
| There are throughput limitations for read/write operations in a single partition. It is recommended to distribute read/write pressure across different partitions by using different message keys to avoid partition hotspots. Please Obtain Services▸ for assistance. |
| Single Partition Read Throughput Limit |
| |
| auto.create.topics.enable Auto-create Topic Switch |
| It is recommended to disable the automatic creation of topics. Manage all topics through the control system and Admin API to avoid unmanageable topics. |
| num.partitions Default number of partitions for created topics |
| The default number of partitions for created topics is used when automatically creating topics. It is recommended to set this at a reasonable cluster level to avoid excessive consumption of partition quotas due to automatic topic creation. |
Topic-Level Configuration
| Parameter | Limit Values | Explanation |
|---|---|---|
| compression.type |
| Sets the final compression type for the Topic. This configuration supports ('gzip', 'snappy', 'lz4', 'zstd'). In addition to these options, 'uncompressed' is also supported, which means no compression. The 'producer' configuration value retains the producer's compression type. |
| cleanup.policy Message Cleanup Policy |
| It is recommended to use the delete type for most business scenarios. The compact type should only be used in scenarios that require state retention. |
| retention.ms |
| Sets the custom message retention period for the topic. This configuration is only effective for topics with the delete cleanup policy and will override the default cluster configuration. |
| max.message.bytes |
| Sets the maximum allowable record batch size for the current Topic. Messages that exceed this limit will be rejected. |
| message.timestamp.type |
| Defines whether the timestamp in the message is the message creation time or the log append time. The value should be 'create time' or 'log append time'. |
| retention.bytes |
| Effective for topics with the delete cleanup policy, this controls the maximum retention space per partition. By default, there is no size limit, only a time limit. This limit is on a per-partition basis, so multiply it by the number of partitions to calculate the Topic-level retention space. This configuration overrides the cluster default configuration. |
| delete.retention.ms |
| Sets the retention time for delete tombstones for Compact-type Topics. This configuration only applies to Compact-type Topics. It dictates that consumers must read the messages within this time to potentially obtain the last valid snapshot; otherwise, they may read incomplete data. |
| Topic naming |
| None. |
| Topic Remarks |
|
Resource Quota Limits
Based on extensive production environment operation and maintenance experience, AutoMQ Cloud has implemented initial constraints on certain performance metrics and parameters within the product. In most cases, these default constraints will meet your needs. If you encounter special circumstances where they do not, please submit a support ticket for assistance.
| Limitations | Limit Values | Explanation |
|---|---|---|
| Single Instance (Cluster) Computing Specifications | 3AKU ~ 500AKU, offering the following capabilities:
| The instance compute specification represents the maximum throughput capacity for a single instance (cluster) to handle message processing. For larger scale cluster requests, please apply for higher specifications▸. |
| Maximum Number of Topics per Instance | Determined by the compute specification used to create the instance; refer to the specific specification limits at Billing Instructions for BYOC▸. | For security and stability, it is recommended to split different business processes across different instances to avoid concentrating all operations in a single instance. |
| Maximum Number of Partitions per Instance (Cluster) | ||
| Single Instance (Cluster) Request QPS Limit |
Product Behavior Restrictions
AutoMQ Kafka, based on over a decade of professional operations experience, has imposed appropriate restrictions on some high-risk operations and functionalities in the open-source project. This is mainly reflected in the following aspects. If you encounter unsatisfactory usage scenarios, please promptly seek assistance through apply for services▸.
| Restricted Item | Restriction Description |
|---|---|
| Apache Kafka Version Compatibility |
|
| Apache Kafka Ecosystem Components |
|