我正在尝试使用Kafka Sink Connector将数据批量发送到NOSQL数据库。我正在关注https://kafka.apache.org/documentation/#connect文档，并对发送记录的逻辑必须实现的位置感到困惑。请帮助我理解如何在内部处理记录以及必须使用什么Put（）或Flush（）来批量处理记录。
答案 0 :(得分：5)
当Kafka Connect工作程序正在运行接收器任务时，它将使用分配给该任务的主题分区的消息。在这样做时，它通过put(Collection<SinkRecord>)方法重复将一批消息传递给接收器任务。只要连接器及其任务正在运行，这将继续。
Kafka Connect还会定期记录接收器任务的进度，即每个主题分区上最近处理的消息的偏移量。这称为提交偏移，它执行此操作，以便如果连接器意外停止且不正常，Kafka Connect会知道每个主题分区中的任务应该继续处理消息。但就在Kafka Connect将偏移量写入Kafka之前，Kafka Connect工作人员通过flush(...)方法为接收器连接器提供了在此阶段工作的机会。
特定接收器连接器可能不需要执行任何操作（如果put(...)执行了所有工作），或者它可能利用此机会将已通过put(...)处理的所有消息提交到数据商店。例如，Confluent's JDBC sink connector使用事务（通过连接器的使用者设置可以控制其大小）写入通过put(...)方法传递的每批消息，因此flush(...)方法不会不需要做任何事情。另一方面，Confluent's ElasticSearch sink connector只是累积了一系列put(...)方法的所有消息，并且只在flush(...)期间将它们写入Elasticsearch。
为源和接收器连接器提交偏移的频率由连接器的offset.flush.interval.ms配置属性控制。默认设置是每60秒提交一次偏移，这种情况很少会提高性能并减少开销，但是如果连接器任务意外死亡，则频繁到足以限制可能的重新处理量。请注意，当连接器正常关闭或遇到异常时，Kafka Connect将始终有机会提交偏移量。只有当Kafka Connect工作人员意外被杀时，它才可能无法提交识别已处理消息的偏移量。因此，只有在这样的故障之后重新启动之后，连接器才可能重新处理它在故障之前所做的一些消息。这是因为消息可能至少被看到一次，消息应该是幂等的。在为此设置确定适当的值时，请考虑所有 plus 连接器的行为。
有关更多示例和详细信息，请查看Confluent documentation for Kafka Connect以及开源接收器连接器。