当在其上创建节点的Kafka分布式连接器被杀死时，为什么会死亡？

Question

我要在本地“启动” Docker容器（独立于Kafka节点容器）中以分布式模式启动Kafka连接器。连接器按预期工作，但是当我杀死启动容器时，连接器停止工作。我希望它能够继续工作，因为我相信它会在另一个容器中的Kafka节点上的一个工作程序上注册并运行。我的设置如下：

目前，我正在通过Docker容器在本地运行所有内容。我有：

1. Zookeeper节点（3.4.9）
2. Kafka节点（Apache，0.10.1.0）
3. “启动”节点。

启动节点将下载适当的Kafka版本并解压缩其内容。然后，它构建连接器源，设置类路径以包含必要的JAR，然后按如下方式执行连接器：

connect-distributed.sh config/connect-distributed.properties

分布式属性文件设置组ID，各种主题名称，模式和转换器，以及引导服务器（指向上面的Kafka节点（2））。

该命令似乎正常执行，并且成功启动了宁静的连接器http服务。然后，我可以向http：// example：8083 / connectors发出POST请求，提供连接器任务的配置。该命令将正确完成，并且连接器已成功启动。我可以从Kafka节点（2）的主题中进行消费，然后看到指示连接器正在工作并正在通过发送数据的输出。

当我杀死启动节点（3）时，我希望该连接器能够继续运行，因为我向Kafka群集注册了该连接器，尽管它是一个群集。连接器无法继续运行，并且似乎与启动节点一起消失。现在不应该由集群中的工作人员管理连接器吗？我需要更改启动连接器的方式还是误解了什么？

Answer 1

Kafka连接器不会在Kafka代理上执行。它们在“ Kafka Connect Worker”过程中执行，这就是您的问题所说的“'启动'节点”。这些进程接受对连接器的REST请求，并在工作进程中运行连接器。在后台，这些过程只是通过正常的生产者和消费者与Kafka经纪人进行交互。Kafka Connect在这些客户端之上提供了一个框架，以简化构建可扩展连接器的过程，因此连接器开发人员只需要关注如何将数据拉入或推入编写连接器的系统。这意味着只有在至少一个工作进程仍处于活动状态时，处理才会继续。

有两种类型的工作进程。在独立模式下，连接器配置不会在任何地方持久化-您通常通过命令行将其传递。偏移信息（即，您已经复制了哪些数据）保存在本地文件系统上。因此，在这种模式下，如果您在具有相同文件系统访问权限的同一节点上重新启动该进程，则只能假设您将从中断的地方继续。

在分布式模式下，工作人员进行协调以分配工作，并且他们共享公共的持久性存储（在Kafka中）以用于连接器配置，偏移量等。这意味着，如果启动一个实例并创建一个连接器，则关闭该实例将暂停所有工作。但是，当您再次启动实例时，它将恢复到中断状态，而无需重新提交连接器配置，因为该信息已保存到Kafka。如果启动多个实例，它们将协调以平衡它们之间的任务，并且如果一个实例发生故障（由于崩溃，弹性缩减正在运行的实例数，电源故障等），其余实例将重新分配自动工作。

您可以在Confluent的Kafka Connect文档中找到有关工作程序，不同类型以及故障转移在分布式模式下如何工作的更多详细信息。