This topic describes the instance editions of ApsaraMQ for Kafka to help you select a suitable instance edition.
Editions
The following table describes the instance editions of ApsaraMQ for Kafka.
Item | Standard Edition (High Write) | Professional Edition (High Write) | Professional Edition (High Read) | Serverless Standard Edition |
Storage costs | Storage space is purchased in reserved mode. The storage costs are almost the same as the storage costs of self-managed Apache Kafka clusters. If you purchase a disk of 300 GB, the actual storage space that you can use to store your business data is 100 GB. The remaining 200 GB is used to store backups. | Storage space is purchased in reserved mode. The storage costs are 66% less than the storage costs of self-managed Apache Kafka clusters. If you purchase a disk of 300 GB, the actual storage space that you can use to store your business data is 300 GB. Alibaba Cloud provides an additional 600 GB of storage space free of charge to allow you to store backups. | The pay-as-you-go billing method is used. You are charged based on the actual storage space and duration. The storage costs are at least 70% less than the storage costs of self-managed Apache Kafka clusters. | |
Computing costs | Computing power is purchased in reserved mode. | Computing power is purchased in reserved mode. | The pay-as-you-go billing method is used. | |
Service interruption | When a cluster is scaled out, the system can quickly handle unexpected traffic spikes without data replication. | When a cluster is scaled out, the system can quickly handle unexpected traffic spikes without data replication. | After a cluster is scaled out, the system cannot handle unexpected traffic spikes because a large amount of bandwidth is required for data replication. | When a cluster is scaled out, the system can quickly handle unexpected traffic spikes without data replication. |
Scalability | After a scale-out is triggered, scalability in seconds is supported for the reads and writes of new messages. The reads of existing messages remain unchanged. | The storage-compute separation architecture helps implement the scalability of message reads and writes and the migration of partitions in seconds. | ||
Ratio of maximum read traffic to maximum write traffic | 1:1 | 1:1 | 5:1 | n:1 |
Instance type | Virtual instances whose specific resources are shared. | Dedicated instances. | Virtual instances whose specific resources are shared. | |
Topic TTL | Not supported. | Supported only by topics that use local storage. | Supported. | |
Message retention period | Up to seven days. | Custom configuration is supported. | No limit is imposed on the storage duration of messages. By default, messages are stored on ApsaraMQ for Kafka brokers for one year. If you want to store messages for a longer period of time, submit a ticket. | |
Disaster recovery | Single-zone deployment. | Multi-zone deployment. | All compute and storage nodes are used as primary and secondary nodes at the same time to implement disaster recovery. Cross-zone disaster recovery is not supported. | |
Performance optimization | Not supported. | Custom configuration is supported. | Custom configuration is supported. | |
Access control list (ACL) | Not supported. | Supported. | Supported. | |
SSL-based data encryption in virtual private clouds (VPCs) | Not supported. | Supported. | Supported. | |
Cross-zone deployment | Not supported. | Supported. | Not supported. | |
Resource isolation | Specific resources, such as disks, are shared. Resource sharing may cause jitters, which are indicated by high latency. For example, unexpected traffic spikes may cause high loads on disks and thus increased request latency and timeout errors. Clients support retries to prevent message loss. The retry feature does not affect messages that have been written. | Exclusive clusters. | Exclusive clusters. | |
Compatibility with client versions | Client versions 0.11 to 3.x are supported. | Client versions 0.11 to 3.x are supported. | Client versions 0.11 to 3.6 are supported. | |