Die erste Methode wird ein Knoten in zookeper admin/delete_topics/<topic>, erstellen und wenn Sie Thema Löschen aktiviert haben, wie Sie ein bestimmten Thread in kafka Broker (TopicDeletionManager), die die delete_topics Childs wird dies tat, überwachen, handhaben, bedeutet das Löschen von zoekeper protokolliert aber auch alle Kafka-Replikate und stellt sicher, dass Sie nicht in einen ungültigen Zustand geraten. Ganze Prozess ist hier beschrieben: https://github.com/apache/kafka/blob/0.11.0/core/src/main/scala/kafka/controller/TopicDeletionManager.scala
/**
* 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.
Löschen direkt von zookeeper bedeutet nur aus der Orchestrierung zu löschen. Sicher, wenn Metadaten angefordert werden, sind die Themen nicht mehr da (naja, vielleicht könnten sie aus dem Cache), aber Logdateien werden nicht gelöscht (zumindest momentan nicht, ich nehme an, Broker werden die Logs für ungültig halten und sie irgendwann löschen)), aber Sie können eine gewisse Inkohärenz bei Brokern haben (wenn Sie mitten in einem Rebalancing waren, könnten Sie viele Dinge kaputt machen). Dies kann bedeuten, dass einige Broker es als gelöscht betrachten, während andere daran denken, dass es immer noch da ist ... weit vom Ideal entfernt.
Löschen von Tierpfleger (und Logs von Brokern) scheint in der Tat möglich von jetzt an, aber Vorsicht, es kann zu Konflikten, ungültigen Zustand, Zufallsfehler, und es möglicherweise nicht funktionieren in zukünftigen Versionen.