这是我的消费者设置。
enable.auto.commit - true (default value)
auto.commit.interval.ms - 5000 ms (default value)
max.poll.interval.ms - 5 mins (default value)
max.poll.records - 500 (default value)
使用这些设置，假设我轮询时会获得500条记录，如果消费者在这5000毫秒内只能处理100条记录，那么我的问题是
答案 0 :(得分：0)
假设您正在询问现代的Java使用者。
它只会提交100条记录吗？
（如果您使用消费者组管理（subscribe()功能）向代理发送心跳，则消费者的 EVERYTHING 发生在调用者线程（您的线程）上，这是一部分调用poll()。这包括提交偏移量。这意味着在您致电poll()之前，不会发送任何偏移量，因此，在您的情况下，答案是否定的-偏移量仅在您完成这500条记录后才提交。
如果上述问题的答案是肯定的，那么其他记录会怎样？
答案是否定的，但是在某些较旧的客户端中，后台线程负责自动偏移量提交，更糟糕的情况是，如果您的应用程序崩溃了，它将恢复到第500条记录的位置（因此您将跳过）超过您尚未处理的400条记录）。但是，现代消费者并非如此
仅当您使用消费者组管理（如果第一个问题的答案为否，则应为所有500条记录提交偏移量。那么“ max.poll.interval.ms”何时会出现，这如何影响偏移量提交？
subscibe()，而不是assign()）时，偏移提交和“活动”才相关。假设您使用CGM，则kafka集群需要确定某个消费者是否“活跃”，以及他们是否认为某个消费者死亡，将其工作（分区）重新分配给另一个实时消费者。现代的卡夫卡将“活力”定义为“不断进步”，而进步意味着您将民意测验称为“经常”。 “足够多”由max.poll.interval定义-因此，即使您停止在5分钟内调用民意调查，即使有心跳线程也会以较短的时间间隔（我认为默认值为〜3秒）使心跳到kafka线程将停止。更准确地说-心跳线将向Kafka发送请假组请求，然后停止。如果您在这种情况下（由于缺乏进展而退出小组），任何由用户提交抵消的尝试都将失败-如果使用CGM，kafka仅接受来自实时成员的抵消提交。
这意味着max.poll.interval和max.poll.records之间存在着固有的权衡-您poll()从消费者那里进行的工作量越大，直到您完成处理所需的时间越长他们并再次致电poll()，您被踢出小组的风险就更高。