AutoMQ provides full Apache Kafka protocol compatibility for scalable, cloud-native messaging. This guide covers recommended client SDKs for various languages to ensure optimal performance and stability.
AutoMQ is fully compatible with the Apache Kafka protocol, allowing you to connect and exchange messages using standard Kafka client SDKs. This guide outlines the recommended clients for various programming languages and highlights important considerations for their use with AutoMQ.
AutoMQ is compatible with the Apache Kafka protocol, supporting clients from Kafka versions 0.10 to 3.9. This compatibility ensures that any standard Kafka client for these versions can connect to AutoMQ without modification.
We strongly recommend using the latest stable version of your chosen client SDK to leverage recent performance enhancements, features, and critical bug fixes.
The Apache Kafka community maintains a list of client SDKs for various programming languages, which you can find in the official documentation. Based on extensive testing and production use, we recommend the following clients for optimal performance and stability with AutoMQ. To help you get started, we provide code samples for each recommended client in our AutoMQ Labs repository.
If the SDK you are using is not among the recommended ones listed above, as long as it is compatible with the Apache Kafka protocol, you can continue to access AutoMQ. We suggest reviewing the known issues list below and adjusting parameters accordingly.
When using the SDK to send and receive messages, in addition to selecting the recommended SDK version, you need to tune the key parameters of the Producer to achieve optimal performance. Below are the recommended Producer configurations for each SDK and Kafka Output.
# https://kafka.apache.org/documentation/#producerconfigs# Batch size, up to 1MiB of data can be accumulated at a time.batch.size=1048576# Batch linger time. If the batch limit is not reached within this time, sending is triggered anyway. This represents the maximum send delay.linger.ms=1000
# https://kafka.apache.org/21/documentation.html#producerconfigs# Maximum retry countretries=2147483647# Initial backoff delay timeretry.backoff.ms=100# Maximum backoff delay timeretry.backoff.max.ms=1000# RPC timeout for each send requestrequest.timeout.ms=30000# Total timeout for the entire send call. No further retries after this time; an exception is returned to the caller.delivery.timeout.ms=120000# Batch size, up to 1MiB of data can be accumulated at a time.batch.size=1048576# Batch linger time. If the batch limit is not reached within this time, sending is triggered anyway. This represents the maximum send delay.linger.ms=1000
// https://pkg.go.dev/github.com/segmentio/kafka-go#Writer// Configure kafka.Writer fields; values align with Apache Kafka Java producer defaults.writer := &kafka.Writer{ // Maximum number of attempts to deliver a message. // Aligned with the Apache Kafka Java Client retries parameter (Integer.MAX_VALUE). MaxAttempts: 2147483647, // Maximum number of messages to trigger a flush. BatchSize: 4096, // Number of acknowledges from partition replicas required before responding. RequiredAcks: kafka.RequireAll,}
# https://www.elastic.co/docs/reference/logstash/plugins/plugins-outputs-kafkaoutput { kafka { # other connection configs ... # Batch size in bytes, up to 1MiB of data can be accumulated at a time. batch_size => 1048576 # Batch linger time in ms. If the batch limit is not reached within this time, sending is triggered anyway. linger_ms => 1000 # The number of acknowledgments the producer requires the leader to have received. acks => "all" # Compression type for all data generated by the producer. compression_type => "lz4" # The amount of time to wait before attempting to retry a failed produce request. retry_backoff_ms => 1000 }}
# https://www.elastic.co/docs/reference/beats/filebeat/kafka-output# Retry backoff wait time during leader elections.retry.backoff: 3s# Wait time before sending bulk Kafka requests.bulk_flush_frequency: 1s
# https://vector.dev/docs/reference/configuration/sinks/kafka/[sinks.my_kafka]type = "kafka"inputs = ["my-source-or-transform-id"]# other connection configs ...# Compression type for all data generated by the producer.compression = "lz4"# Batch linger time is controlled via librdkafka options.[sinks.my_kafka.librdkafka_options]"queue.buffering.max.ms" = "1000"
Phenomenon: When using async_producer to send messages and the corresponding Topic undergoes partition reassignment, the Producer’s memory usage can increase abnormally, potentially leading to OOM.
Cause: When async_producer receives server-side retryable errors (like NOT_LEADER_OR_FOLLOWER due to partition reassignment), it temporarily stores the messages in memory and retries according to the policy. However, this retry cache has no size limit, and if substantial and continuous retries occur, memory usage may unexpectedly increase.
Consumers Unable to Identify Group Coordinator Changes
Defect Version: V0.4.47
Issue: After partition reassignment of the __consumer_offsets topic, some groups experience consumption interruptions, with errors logged.
Cause: When the __consumer_offsets partitions are reassigned, the coordinator for some groups changes. Kafka-go does not correctly handle this situation, as it continues to send requests to the old coordinator following a change, resulting in NOT_COORDINATOR errors.
Temporarily restart the Consumer to recover.
Switch SDKs, and it is recommended to use the Franz-Go SDK as per the recommended versions in this document.
Issue: When the Consumer’s configured heartbeatInterval is too close to sessionTimeout, the Consumer may periodically Leave & Rejoin the Group (though it generally does not affect consumption), logging errors.
Cause: In kafkajs, the configuration of heartbeatInterval only guarantees the “minimum interval between two heartbeats.” This means that in certain scenarios (e.g., the Consumer reaches the end of the topic with no new messages to consume), the interval between the Consumer sending heartbeats to the Coordinator may exceed the heartbeatInterval; if set too large, it may exceed sessionTimeout, causing the Coordinator to evict the Consumer.
Lower the heartbeatInterval or increase the sessionTimeout (it is advised that heartbeat.interval.ms should not exceed 1/3 of session.timeout.ms).