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 of message retention impacts storage space consumption and costs. It is recommended to evaluate this reasonably. If not satisfied, please seek help at Obtaining Services▸. |
| message.max.bytes Maximum message size |
| If the current parameter limits do not meet your needs, please seek help at Obtaining Services▸. |
| offsets.retention.minutes Offset retention period |
| |
| fetch.max.bytes Maximum data per fetch |
| |
| Single Partition Write Throughput Limit |
| There are limitations on single-partition read/write throughput. It is recommended to distribute the read/write load across different partitions using different message keys to avoid partition hotspots. Please seek help at Obtaining Services▸. |
| 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 | 6vCPU ~ 20vCPU, providing the following capabilities:
| Instance compute specifications represent the upper limit of message processing throughput for a single instance (cluster). If you have a demand for larger-scale clusters, please apply for high specification limits at Obtaining Services▸. |
| Maximum Number of Topics per Instance | Determined by the compute specifications of the created instance. For detailed specifications, please refer to 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 features of the open-source project. If you encounter unmet scenarios, please seek help promptly via Obtaining Services▸.
| Restricted Item | Restriction Description |
|---|---|
| Apache Kafka Version Compatibility |
|
| Apache Kafka Ecosystem Components |
|