Kafka Broker抵消/日志保留和使用者抵消最早的重置方式

Question

問題描述：

我們的Kafka用戶（在Spring Boot 2.x中開發）正在執行幾天。 當我們重新啟動這些使用者時，將再次使用該主題的所有消息，但僅限於特定條件下。

條件：

我們假設代理/主題配置（ log.retention。* ， offsets.retention。 * ）和使用者配置（ auto.offset.reset = 最早 ）的組合導致了此行為。
顯然，我們不能將使用者設置為“最新” ，因為如果使用者停止並且新消息到達，則當使用者再次啟動時，這些消息將不會被使用。

題：

避免這種情況的正確設置是什么？
在最新的Kafka Broker版本（2.x）中，log.retention。*和offsets.retention。*的默認值是相同的（ https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A +增加+偏移量+保留時間+默認+至+7+天 ）

這種新的配置設置可以解決問題嗎？

使用者配置 （在Spring Cloud Stream Framework上委派了auto.commit ）：

           auto.commit.interval.ms = 100
           auto.offset.reset = earliest
           bootstrap.servers = [server1:9092]
           check.crcs = true
           client.id = 
           connections.max.idle.ms = 540000
           enable.auto.commit = false
           exclude.internal.topics = true
           fetch.max.bytes = 52428800
           fetch.max.wait.ms = 500
           fetch.min.bytes = 1
           group.id = consumer_group1
           heartbeat.interval.ms = 3000
           interceptor.classes = null
           internal.leave.group.on.close = true
           isolation.level = read_uncommitted
           key.deserializer = class org.apache.kafka.common.serialization.ByteArrayDeserializer
           max.partition.fetch.bytes = 1048576
           max.poll.interval.ms = 300000
           max.poll.records = 500
           metadata.max.age.ms = 300000
           metrics.recording.level = INFO
           metrics.sample.window.ms = 30000
           partition.assignment.strategy = [class org.apache.kafka.clients.consumer.RangeAssignor]
           receive.buffer.bytes = 65536
           reconnect.backoff.max.ms = 1000
           reconnect.backoff.ms = 50
           request.timeout.ms = 305000
           retry.backoff.ms = 100
           value.deserializer = class org.apache.kafka.common.serialization.ByteArrayDeserializer

經紀人配置：

           log.retention.ms = 86400000
           log.retention.minutes = 10080
           log.retention.hours = 168
           log.retention.bytes = -1

           offsets.retention.ms = 864000000
           offsets.retention.minutes = 14400
           offsets.retention.hours = 240 

           unclean.leader.election.enable = false
           log.cleaner.enable = true
           auto.leader.rebalance.enable = true
           leader.imbalance.check.interval.seconds = 300
           log.retention.check.interval.ms = 300000
           log.cleaner.delete.retention.ms = 604800000

謝謝並恭祝安康

Answer 1

你說得對，你遇到此問題，由於不同的價值觀log.retention.*和offsets.retention.*卡夫卡版本（7天和1天分別）2.0之前，請在這里說明 。 這是由於您的主題中出現了罕見的消息，並且抵消數據已經過期。

關於您的短語，這並不完全正確。 Obviously we can't set consumer to "latest" 。 如果你不到1天前收到的最后一封郵件（如前幾個小時），你可以安全地更新auto.offset.reset值latest ，並與同組ID（或application.id ）。 在這種情況下，您將不會丟失消息。

作為另一種選擇，您可以將特定主題的日志保留值更改為1天。 另外，您可以更新offsets.retention.*值，但是由於需要從性能角度對其進行測試，因此它可能會降級。

Answer 2

如果您使應用程序保持24x7全天候運行（例如，在沒有數據的周末），則一個選項是設置一個idleInterval並添加一個ApplicationListener （或@EventListener ）來偵聽ListenerContainerIdleEvent 。

然后，如果idleTime屬性接近日志保留，則可以在事件中使用Consumer重新提交偏移量-獲取分配的分區，找到其當前position() ，然后重新提交。