doc-exports/docs/dms/umn/Kafka-client-best-practice.html

<a name="Kafka-client-best-practice"></a><a name="Kafka-client-best-practice"></a>

<h1 class="topictitle1">Suggestions on Using the Kafka Client</h1>
<div id="body0000001926355989"><div class="section" id="Kafka-client-best-practice__section85502807"><h4 class="sectiontitle">Consumers</h4><ol id="Kafka-client-best-practice__ol1577776118"><li id="Kafka-client-best-practice__li127707717">Ensure that the owner thread does not exit abnormally. Otherwise, the client may fail to initiate consumption requests and the consumption will be blocked.</li><li id="Kafka-client-best-practice__li13748161123917">Commit messages only after they have been processed. Otherwise, the messages may fail to be processed and cannot be polled again.</li><li id="Kafka-client-best-practice__li10779714118">Generally, do not commit every message. Otherwise, there will be many <strong id="Kafka-client-best-practice__b151141522115515">OFFSET_COMMIT</strong> requests, causing high CPU usage. For example, if a consumption request pulls 1000 messages and commits every one of them, TPS of the commit requests is 1000 times that of consumption. The smaller the message size, the larger the ratio. You can commit a specific number of messages in batches or enable <strong id="Kafka-client-best-practice__b1795161612581">enable.auto.commit</strong>. However, if the client is faulty, some cached consumption offset may be lost, resulting in repeated consumption. Therefore, you are advised to commit messages in batches based on service requirements.</li><li id="Kafka-client-best-practice__li57712713115">A consumer cannot frequently join or leave a group. Otherwise, the consumer will frequently perform rebalancing, which blocks consumption.</li><li id="Kafka-client-best-practice__li3771677119">The number of consumers cannot be greater than the number of partitions in the topic. Otherwise, some consumers may fail to poll for messages.</li><li id="Kafka-client-best-practice__li0771471212">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.</li><li id="Kafka-client-best-practice__li1777171315">Ensure that there is a limitation on the size of messages buffered locally to avoid an out-of-memory (OOM) situation.</li><li id="Kafka-client-best-practice__li277677113">Set the timeout for the consumer session to 30 seconds: session.timeout.ms=30000.</li><li id="Kafka-client-best-practice__li477671112">Kafka supports exactly-once delivery. Therefore, ensure the idempotency of processing messages for services.</li><li id="Kafka-client-best-practice__li14781778111">Always close the consumer before exiting. Otherwise, consumers in the same group may be blocked within the timeout set by <strong id="Kafka-client-best-practice__b205502155918">session.timeout.ms</strong>.</li><li id="Kafka-client-best-practice__li689610431457">Do not start a consumer group name with a special character, such as a number sign (#). Otherwise, monitoring data of the consumer group cannot be displayed.</li></ol>
</div>
<div class="section" id="Kafka-client-best-practice__section65310184020"><h4 class="sectiontitle">Producers</h4><ol id="Kafka-client-best-practice__ol53887211062"><li id="Kafka-client-best-practice__li9388102113614">Synchronous replication: Set <strong id="Kafka-client-best-practice__b105761128192612">acks</strong> to <strong id="Kafka-client-best-practice__b1576122812612">all</strong>.</li><li id="Kafka-client-best-practice__li43881121866">Retry message sending: Set <strong id="Kafka-client-best-practice__b84721347102619">retries</strong> to <strong id="Kafka-client-best-practice__b24731747142611">3</strong>.</li><li id="Kafka-client-best-practice__li33888211962">Optimize message sending: For latency-sensitive messages, set <strong id="Kafka-client-best-practice__b1575215511269">linger.ms</strong> to <strong id="Kafka-client-best-practice__b175225117261">0</strong>. For latency-insensitive messages, set <strong id="Kafka-client-best-practice__b11162568262">linger.ms</strong> to a value ranging from <strong id="Kafka-client-best-practice__b1716125642616">100</strong> to <strong id="Kafka-client-best-practice__b16171156112618">1000</strong>.</li><li id="Kafka-client-best-practice__li133881421268">Ensure that the producer has sufficient JVM memory to avoid blockages.</li><li id="Kafka-client-best-practice__li18921123181613">Set the timestamp to the local time. Messages will fail to age if the timestamp is a future time.</li></ol>
</div>
<div class="section" id="Kafka-client-best-practice__section785814360014"><h4 class="sectiontitle">Topics</h4><p id="Kafka-client-best-practice__p178951621165816">Recommended topic configurations: Use 3 replicas, enable synchronous replication, and set the minimum number of in-sync replicas to 2. The number of in-sync replicas cannot be the same as the number of replicas of the topic. Otherwise, if one replica is unavailable, messages cannot be produced.</p>
<p id="Kafka-client-best-practice__p07361810728">You can enable or disable automatic topic creation. If automatic topic creation is enabled, the system automatically creates a topic when a message is produced in or consumed from a topic that does not exist. This topic has the following default settings: 3 partitions, 3 replicas, aging time 72 hours, synchronous replication and flushing disabled, <strong id="Kafka-client-best-practice__b167644278297">CreateTime</strong> message timestamp, and maximum 10,485,760 bytes message size.</p>
</div>
<div class="section" id="Kafka-client-best-practice__section194821855405"><h4 class="sectiontitle">Others</h4><p id="Kafka-client-best-practice__p13895172119589">Maximum number of connections: 3000</p>
<p id="Kafka-client-best-practice__p9895521195815">Maximum size of a message: 10 MB</p>
<p id="Kafka-client-best-practice__p138951121155817">Access Kafka using SASL_SSL. Ensure that your DNS service is capable of resolving an IP address to a domain name. Alternatively, map all Kafka broker IP addresses to host names in the <strong id="Kafka-client-best-practice__b1159916444308">hosts</strong> file. Prevent Kafka clients from performing reverse resolution. Otherwise, connections may fail to be established.</p>
<p id="Kafka-client-best-practice__p08951121145817">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.</p>
<p id="Kafka-client-best-practice__p18895521115811">Avoid frequent full GC in JVM. Otherwise, message production and consumption will be blocked.</p>
</div>
</div>
<div>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="kafka-ug-0062.html">Configuring the Kafka Client</a></div>
</div>
</div>