Apache kafka 使用zookeeper-shall.sh rmr brokers/topics删除主题与kafka-topics.sh上Kafka10的delete标志之间的区别

从我在网上和其他stack overflow帖子上找到的信息来看，删除卡夫卡主题的方法主要有两种。 第一个是：a）

delete.topic.enable=true

并运行

/kafka-topics.sh--delete--topic

第二种方式：

/zookeeper-shell.sh localhost:2181 rmr代理/主题

---

我注意到第一种方法会标记每个要删除的主题，几分钟后主题就会被删除，而第二种方法会立即删除它们。我还注意到重新启动服务器需要几个小时，这正常吗？我在一个代理上有1000多个主题（出于测试目的）。

第一种方法将在zookeper

admin/delete\u topics/

中创建一个节点，如果您像以前一样启用了主题删除，kafka代理（TopicDeletionManager）中的一个给定线程将处理此问题，该线程监视

删除主题
子对象，这意味着要从zookeper中删除日志，但也要从所有kafka副本中删除日志，以确保不会以无效状态结束。整个过程如下所述：

/**
*这将管理主题删除的状态机。
* 1. TopicCommand通过创建新的管理路径/admin/delete\u topics来发布主题删除/
* 2. 控制器侦听/admin/delete_主题上的子更改，并开始删除相应主题的主题
* 3. 控制器的ControllerEventThread处理主题删除。主题将不合格
*用于在以下场景中删除-
*3.1托管该主题的其中一个副本的代理失败
*3.2正在为该主题的分区重新分配分区
* 4. 主题删除在以下情况下恢复：-
*4.1启动托管该主题的一个副本的代理
*4.2该主题分区的分区重新分配完成
* 5. 要删除的主题的每个副本都处于3种状态之一-
*5.1调用OnPartitionDelete时，TopicDeletionStarted复制副本进入TopicDeletionStarted阶段。
*当在控制器上触发子更改watch for/admin/delete_主题时，会发生这种情况。作为这个国家的一部分
*更改后，控制器向所有副本发送StopReplica请求。它为
*StopReplicaResponse when deletePartition=true，从而在响应删除复制副本时调用回调
*（从每个复制副本接收）
*5.2 TopicDeletion成功从
*TopicDeletionStarted->TopicDeletionSuccessful取决于StopReplicaResponse中的错误代码
*5.3 TopicDeletion未能从中移动副本
*TopicDeletionStarted->TopicDeletion失败，具体取决于StopReplicaResponse中的错误代码。
*通常，如果代理死了，并且为要删除的主题托管了副本，则控制器会将
*onBrokerFailure回调中处于TopicDeletionFailed状态的各个副本。原因是如果
*代理在发送请求之前以及副本处于TopicDeletionStarted状态之后失败，
*复制副本可能会错误地保持在TopicDeletionStarted状态和topic Delete状态
*当代理返回时将不会重试。
* 6. 只有当所有副本都在TopicDeletionSuccessful中时，主题才会被标记为已成功删除
*国家。主题删除下拉模式从controllerContext中删除所有主题状态
*还有动物园管理员。这是唯一一次删除/brokers/topics/path。另一方面
*如果没有副本处于TopicDeletionStarted状态，并且至少有一个副本处于TopicDeletionFailed状态，则
*它将主题标记为删除重试。

直接从zookeeper中删除只意味着从orchestrator中删除。当然，当请求元数据时，主题不再在这里（好吧，也许它们可以从缓存中删除），但日志文件不会被删除（至少现在不会，我假设代理会检测到日志无效，并在某个时候删除它们），但您可能在代理上存在一些不一致性（如果你处于一个再平衡的中间，你可能会破坏很多东西）。这可能意味着一些经纪人会考虑删除它，而另一些人会认为它仍然存在……远不是理想的。< / P>
从现在起删除fom zookeeper（以及代理的日志）似乎确实是可能的，但请注意，它可能会导致冲突、无效状态、随机错误，并且在将来的版本中可能根本不起作用

/**
 * This manages the state machine for topic deletion.
 * 1. TopicCommand issues topic deletion by creating a new admin path /admin/delete_topics/<topic>
 * 2. The controller listens for child changes on /admin/delete_topic and starts topic deletion for the respective topics
 * 3. The controller's ControllerEventThread handles topic deletion. A topic will be ineligible
 *    for deletion in the following scenarios -
  *   3.1 broker hosting one of the replicas for that topic goes down
  *   3.2 partition reassignment for partitions of that topic is in progress
 * 4. Topic deletion is resumed when -
 *    4.1 broker hosting one of the replicas for that topic is started
 *    4.2 partition reassignment for partitions of that topic completes
 * 5. Every replica for a topic being deleted is in either of the 3 states -
 *    5.1 TopicDeletionStarted Replica enters TopicDeletionStarted phase when onPartitionDeletion is invoked.
 *        This happens when the child change watch for /admin/delete_topics fires on the controller. As part of this state
 *        change, the controller sends StopReplicaRequests to all replicas. It registers a callback for the
 *        StopReplicaResponse when deletePartition=true thereby invoking a callback when a response for delete replica
 *        is received from every replica)
 *    5.2 TopicDeletionSuccessful moves replicas from
 *        TopicDeletionStarted->TopicDeletionSuccessful depending on the error codes in StopReplicaResponse
 *    5.3 TopicDeletionFailed moves replicas from
 *        TopicDeletionStarted->TopicDeletionFailed depending on the error codes in StopReplicaResponse.
 *        In general, if a broker dies and if it hosted replicas for topics being deleted, the controller marks the
 *        respective replicas in TopicDeletionFailed state in the onBrokerFailure callback. The reason is that if a
 *        broker fails before the request is sent and after the replica is in TopicDeletionStarted state,
 *        it is possible that the replica will mistakenly remain in TopicDeletionStarted state and topic deletion
 *        will not be retried when the broker comes back up.
 * 6. A topic is marked successfully deleted only if all replicas are in TopicDeletionSuccessful
 *    state. Topic deletion teardown mode deletes all topic state from the controllerContext
 *    as well as from zookeeper. This is the only time the /brokers/topics/<topic> path gets deleted. On the other hand,
 *    if no replica is in TopicDeletionStarted state and at least one replica is in TopicDeletionFailed state, then
 *    it marks the topic for deletion retry.