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 | Description |
|---|---|---|
| log.retention.ms Message retention duration |
| The retention period for messages impacts storage space consumption and cost. It's recommended to assess business needs rationally. If the default setting does not meet your requirements, please Obtain Services▸ for assistance. |
| message.max.bytes Maximum message size |
| If the current parameter limit does not meet your needs, please Obtain Services▸ for assistance. |
| offsets.retention.minutes Offset retention period |
| |
| fetch.max.bytes Maximum data per fetch |
| |
| Single Partition Write Throughput Limit |
| Single partition read/write throughput is limited. It is recommended that applications distribute the read/write load across different partitions using different message keys to avoid partition hotspots. Please Obtaining 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 | Description |
|---|---|---|
| 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 computing specifications represent the maximum throughput capacity for message processing by a single instance (cluster). For larger-scale cluster requirements, please Obtaining Services▸ to apply for higher specifications. |
| Maximum Number of Topics per Instance | Determined by the computing specifications of the created instance. For details, refer to the specification limits 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
With over a decade of professional operation and maintenance experience, AutoMQ Kafka imposes appropriate restrictions on certain high-risk operations and features of the open-source product. These restrictions are mainly reflected in the following aspects. If your usage scenario is not satisfied, please promptly seek help through Obtaining Services▸.
| Restricted Item | Restriction Description |
|---|---|
| Apache Kafka Version Compatibility |
|
| Apache Kafka Ecosystem Components |
|