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 message retention period impacts storage space consumption and costs. It is recommended that businesses assess it reasonably. If unsatisfied, please Obtain Services▸ for assistance. |
| message.max.bytes Maximum message size |
| If the current parameter limits do 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 to distribute the read/write load across different partitions 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 | 6vCPU ~ 20vCPU, providing the following capabilities:
| Instance specifications determine the upper limit of message processing throughput for a single instance (cluster). If you require a larger scale cluster, please Request High-Spec Limits▸ for higher specifications. |
| Maximum Number of Topics per Instance | Determined by the instance specifications at creation, please refer to the 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, leveraging over ten years of professional operational experience, has implemented appropriate restrictions on certain high-risk operational activities and functions in the open-source project. The following areas are notably affected. If your use case is not addressed by these adjustments, please seek assistance through Obtaining Services▸.
| Restricted Item | Restriction Description |
|---|---|
| Apache Kafka Version Compatibility |
|
| Apache Kafka Ecosystem Components |
|