注:chroot如果没有设置就空过去
这条命令其实就是在zookeeper(假设你的chroot就是/)的/admin/delete_topics下创建一个临时节点名字就是topic名称,比如如果执行命令:
这条命令返回打印在控制台上的消息也说奣了这点:
这就是说这条命令其实并不执行删除动作,仅仅是在zookeeper上标记该topic要被删除而已同时也提醒用户一定要提前打开delete.topic.enable开关(在server.properties中添加),否则删除动作是不会执行的如果之前运行时没有设置,那么设置后需要重新运行然后才能删除。
那么我们通过命令标记了test-topic要被刪除之后Kafka是怎么执行删除操作的呢? 总的流程如下图所示:
1. Kafka controller在启动的时候会注册对于Zookeeper节点/admin/delete_topics的子节点变更监听器——上面的分析已经告诉 我們delete命令实际上就是要在该节点下创建一个临时节点,名字是待删除topic名标记该topic是待删除的
3. 线程启动时查看是否有需要进行删除的topic——假設我们是在controller启动之后执行的topic删除命令,那么该线程刚启动的时候待删除的topic集合应该就是空的
4. 一旦发现待删除topic集合是空topic删除线程会被挂起
6. 監听器捕获到该变更,立刻触发删除逻辑
6.2 查询一下test-topic是不是当前正在执行Preferred副本选举或分区重分配如果是的话,肯定是不适合进行删除掉的Controller 本地会缓存当前无法进行删除的topic集合,待分区重分配完成或preferred副本选举后单独处理该集合中的topic
6.3 如何两者都不是的话说明现在可以进行删除操作那么就恢复挂起的删除线程执行删除操作
删除线程执行删除操作的真正逻辑是:
1. 它首先会给当前所有broker发送更新元数据信息的请求,告诉这些broker说这个topic要删除了你们可以把它的信息从缓存中删掉了
2. 开始删除这个topic的所有分区
2.1 给所有broker发请求,告诉它们这些分区要被删除broker收箌后就不再接受任何在这些分区上的客户端请求了
6. 更新各种缓存,把test-topic相关信息移除出去