If we want to achieve high performance/availability, here're some rules of thumb.
Use a consumer group for these KafkaConsumers, thus they will work together -- each one deals with different partitions.
Besides subscribe
(topics), users could also choose to explicitly assign
certain partitions to a KafkaConsumer
.
Try with a larger QUEUED_MIN_MESSAGES
, especially for small messages.
Use multiple KafkaConsumers to distribute the payload.
A KafkaManualCommitConsumer
could help to commit the offsets more frequently (e.g, always do commit after finishing processing a message).
Don't use quite a large MAX_POLL_RECORDS
for a KafkaAutoCommitConsumer
, -- you might fail to commit all these messages before crash, thus more duplications with the next poll
.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。