Restrictions
To mitigate various specific exceptions in the production environment resulting from ambiguous behavior definitions, AutoMQ for Kafka establishes strict constraints and standards on parameters, quotas, and behaviors within the product. Users must carefully adhere to these constraints and should immediately submit a support ticket if they encounter any unsatisfactory conditions.
Parameter Restrictions
The following parameters involve resource naming and note restrictions with fixed values that cannot be adjusted. It is crucial to strictly follow these standards to avoid system processing issues caused by special characters or exceeding length limits. Most parameter restrictions within the AutoMQ for Kafka product are derived from Apache Kafka, with some constraints further explained below.
Instance-Level Configuration
| Parameter | Restriction | Description |
|---|---|---|
| log.retention.ms Message Retention Duration |
| The message retention duration impacts storage space consumption and costs; businesses are advised to assess these factors reasonably. If requirements are not met, please Obtain Services▸ seek assistance. |
| message.max.bytes Maximum Message Size |
| If the current parameter restrictions do not meet your needs, please Obtain Services▸ seek assistance. |
| offsets.retention.minutes Consumer Progress Retention Duration |
| If the current parameter restrictions do not meet your needs, please Obtain Services▸ seek assistance. |
| fetch.max.bytes Maximum fetch data per request |
| If the current parameter limit does not meet your needs, please Obtaining Services▸ seek help. |
| Single partition write throughput limit |
| There are limitations on single partition read and write throughput, it is recommended that applications distribute the read and write load across different partitions using different message keys to avoid hot partitions. Please Obtaining Services▸ seek help. |
| Single partition read throughput limit |
| There are limitations on single partition read and write throughput, it is recommended that applications distribute the read and write load across different partitions using different message keys to avoid hot partitions. Please Obtaining Services▸ seek help. |
| auto.create.topics.enable Auto-create Topic switch |
| It is recommended to disable the auto-create topic switch and manage all topics through the control system and Admin API to prevent unmanageable topics. |
| num.partitions Default number of partitions for new topics |
| The default number of partitions is used when auto-creating topics; it is advisable to set a reasonable number at the cluster level to avoid consuming too many partition quotas through auto-created topics. |
Topic-level Configuration
| Parameter | Limit | Explanation |
|---|---|---|
| compression.type |
| Set the final compression type for Topics. This configuration supports ('gzip', 'snappy', 'lz4', 'zstd'); in addition to these, it also supports 'uncompressed', which is equivalent to no compression; 'producer' setting retains the compression type configured by the producer. |
| cleanup.policy Message Cleanup Policy |
| For most business scenarios, the delete policy is recommended, while the compact type is used only in scenarios requiring state data retention. |
| retention.ms |
| Sets the custom message retention duration for topics, effective only for topics with a delete cleanup policy. This configuration overrides the cluster's default settings. |
| max.message.bytes |
| Sets the maximum allowed record batch size for the current Topic. Messages exceeding this limit will be rejected. |
| message.timestamp.type |
| Defines whether the timestamp in the message is the time of message creation or the time of log appendage. The value should be either 'create time' or 'log append time'. |
| retention.bytes |
| Effective for topics with a delete type cleanup policy, it controls the maximum space retained per partition. By default, there is no size limit, only a time limit. This limit is at the partition level, so multiply by the number of partitions to calculate the retention space at the topic level. This configuration overrides the cluster's default settings. |
| delete.retention.ms |
| Sets the time to retain tombstone markers for Compact type Topics, effective only for Compact type Topics. This configuration stipulates that consumers must read the messages within this time to possibly obtain the last valid snapshot; otherwise, consumers may receive incomplete data. |
| Topic Naming |
| None. |
| Topic Annotations |
| None. |
Resource Quota Limitations
AutoMQ Cloud, leveraging extensive operational expertise in large-scale production settings, establishes initial limits on certain performance metrics and parameters within the product. Typically, these default limits adequately satisfy requirements. Should they fall short of your specific needs, we encourage you to submit a ticket for prompt assistance.
| Limitation Item | Limitation Value | Description |
|---|---|---|
| Single Instance (Cluster) Compute Specifications | 6vCPU ~ 20vCPU, providing the following capabilities:
| The instance compute specification represents the maximum message handling throughput capability of a single instance (cluster). For larger-scale cluster needs, please Obtaining Services▸ to apply for higher specification limits. |
| Single Instance Topic Count Limit | Determined by the compute specifications of the created instance, refer to the specification limits for details Billing Instructions for BYOC▸ . | For security and stability, it is recommended to split different business operations into separate instances to avoid concentrating all operations in a single instance. |
| Single Instance (Cluster) Partition Count Limit | Determined by the compute specifications of the created instance, refer to the specification limits for details Billing Instructions for BYOC▸ . | For security and stability, it is recommended to split different business operations into separate instances to avoid concentrating all operations in a single instance. |
| Single Instance (Cluster) Request QPS Limit | Determined by the compute specifications of the created instance, refer to the specification limits for details Billing Instructions for BYOC▸ . | For security and stability, it is recommended to split different business operations into separate instances to avoid concentrating all operations in a single instance. |
Product Behavior Restrictions
AutoMQ Kafka, leveraging over ten years of professional operational expertise, has implemented specific restrictions on high-risk operational practices and functionalities within open-source project products. If your usage scenario is not met, please promptly seek assistance through Obtaining Services▸.
| Restriction Item | Description |
|---|---|
| Apache Kafka Version Compatibility |
|
| Apache Kafka Ecosystem Components |
|