Updated on 2023-10-10 GMT+08:00

Recommendations for Client Usage

Applicability for Consumers

  • Ensure that the owner thread does not exit abnormally. Otherwise, the client may fail to initiate consumption requests and the consumption will be blocked.
  • Ensure that the commit operation is performed after messages are processed. This is to avoid the failure of processing service messages and the failure to retrieve the message that fails to be processed.
  • A consumer cannot frequently join or leave a group. Otherwise, the consumer will frequently perform rebalancing, which blocks consumption.
  • The number of consumers cannot be greater than the number of partitions in the topic. Otherwise, some consumers may fail to poll for messages.
  • Ensure that the consumer polls at regular intervals to keep sending heartbeats to the server. If the consumer stops sending heartbeats for long enough, the consumer session will time out and the consumer will be considered to have stopped. This will also block consumption.
  • Ensure that there is a limitation on the size of messages buffered locally to avoid an out-of-memory (OOM) situation.
  • The timeout interval of the consumer session is set to 30 seconds, and session.timeout.ms is set to 30000. This prevents the consumer from performing rebalance due to frequent timeout. Frequent timeout will block consumption.
  • ROMA Connect may consume repeated messages. The service side must ensure the idempotency of message processing.
  • Always close the consumer before exiting. Otherwise, consumers in the same group may block the session.timeout.ms time.

Applicability for Producers

  • Synchronous replication: Set acks to -1.
  • Retry message sending: Set retries to 3.
  • Message sending optimization: Set linger.ms to 0.
  • Ensure that the producer has sufficient JVM memory to avoid blockages.

Applicability of Topics

  • Recommended configuration: three copies
  • The recommended maximum number of partitions for a topic is 20.
  • Each topic can have 3 replicas (the number of replicas cannot be modified once configured).

Other Suggestions

  • Maximum number of connections: 3000
  • Maximum size of a message: 10 MB
  • Access ROMA Connect using SASL_SSL. Ensure that your DNS service is capable of resolving an IP address to a domain name. Alternatively, map all ROMA Connect broker IP addresses to host names in the hosts file. Prevent Kafka clients from performing reverse resolution. Otherwise, connections may fail to be established.
  • Apply for a disk space size that is more than twice the size of service data multiplied by the number of replicas. In other words, keep 50% of the disk space idle.
  • Avoid frequent full GC in JVM. Otherwise, message production and consumption will be blocked.
  • Configure log dump on the Kafka client, or logs may take up the disk space.
  • A maximum of 500 consumers in the same consumer group can connect to the same MQS. If the number of consumers exceeds 500, the connection fails. If a consumer group with over 500 consumers needs to connect to an MQS, put the consumers into multiple consumer groups.
  • If both SASL_SSL and intra-VPC plaintext access are enabled for MQS of the ROMA Connect instance, the SASL mode cannot be used for connecting to MQS topics in the VPC.
  • If the SASL mode is used for connecting to MQS topics, you are advised to configure the mapping between the host and IP address in the /etc/hosts file on the host where the client is located. Otherwise, network delay will occur.

    Set the IP address to the connection address of MQS and set the host to the name of each instance host. Ensure that the name of each host is unique. Example:

    10.10.10.11 host01

    10.10.10.12 host02

    10.10.10.13 host03