我只是想确认我认为在文档行之间的内容。说 kafka 流中的提交与偏移量/消息是否由应用程序拓扑的整个处理节点集处理无关，但仅取决于提交间隔是否正确？换句话说，在典型的 kafka 消费者应用程序中，当消息被完全处理而不是仅获取时，人们会在 Kafka 流中提交，只需被获取就足以让提交间隔启动并提交该消息/偏移量？也就是说，即使该偏移量/消息尚未由应用程序拓扑的整个处理节点集处理？
或者消息是否有资格提交，基于拓扑的整个处理节点集处理它们的事实，并且它们已准备好在主题或外部系统中发出。
从某种意义上说，这个问题可以总结为，偏移量/消息何时有资格在 Kafka 流中提交？ 它是有条件的吗？ 如果是这样，条件是什么？
你必须明白，一个Kafka Streams程序，即它的Topology我的包含多个子拓扑(https://docs.confluent.io/current/streams/architecture.html#stream-partitions-and-tasks(。子拓扑通过主题相互连接。
如果记录由子拓扑完全处理，则可以提交该记录。对于这种情况，记录的中间输出在提交发生之前写入连接两个子拓扑的主题中。下游子拓扑将从"连接主题"读取并提交此主题的偏移量。
提交确实仅基于commit.interval.ms发生。如果 fetch 返回 100 条记录(偏移量 0 到 99(，并且当commit.interval.ms命中时，子拓扑处理 30 条记录，Kafka Streams 将首先确保这 30 条消息的输出被刷新到 Kafka(即Producer.flush()(，然后提交偏移量30- 其他 70 条消息只是在 Kafka Streams 的内部缓冲区中，并在提交后进行处理。如果缓冲区为空，则将发送新的提取。每个线程独立跟踪commit.interval.ms，如果提交间隔过去，将提交其所有任务。
由于提交是在子拓扑的基础上进行的，因此它可以比输入主题记录提交，而输出主题还没有结果数据，因为下游子拓扑尚未处理中间结果。
可以通过Topology#describe()检查程序的结构，以查看程序具有哪些子拓扑。
无论是使用流还是只是一个简单的消费者，关键是自动提交发生在轮询线程中，而不是单独的线程中 - 一批消息的偏移量仅在后续轮询中提交，commit.interval.ms只定义了提交之间的最短时间，即大值意味着提交不会在每次轮询时发生。
这意味着，只要您不生成额外的线程，您就只会为已完全处理的消息提交偏移量，无论该处理涉及什么。