---

歡迎支持筆者新作：《深入理解Kafka:核心設計與實踐原理》和《RabbitMQ實戰指南》，同時歡迎關注筆者的微信公眾號：朱小廝的博客。

歡迎跳轉到本文的原文鏈接：https://honeypps.com/mq/the-secret-behind-kafka-topic-deletion/

---

在本文開篇中先讓大家來思考一個問題，這個問題也是來源于一次真實的應用案例，案例內容的具體步驟如下：

• step 1. 創建一個主題，假設主題名為topic-offset；
• step 2. 創建生產者往這個主題中寫入若干消息，然后關閉生產者；
• step 3. 創建消費者消費這個主題中的消息，并將消費位移存入__consumer_offsets這個主題中（假設這里消費組的名稱groupId=“group.offset”），然后關閉消費者；
• step 4. 刪除topic-offset這個主題；
• step 5. 在step3中提交的消費位移過期時間內（Kafka中默認過期時間是1440mins，即1天）再次創建topic-offset主題，主題的所有屬性均和step 1中的相同;

至此，便可以引出了筆者的問題了：如果此時再創建一個消費者，并且這個消費者設置的消費組的名稱也為"group.offset"，那么這個消費者是從step 3中__consumer_offsets中保存的位置開始消費還是根據消費者自身所設置的“auto.offset.reset”參數來決定開始消費的位置。

或許你對這個問題一臉懵逼，筆者先來簡單講一下消費位移的相關知識點：我們知道在舊版的消費者中會將消費位移存儲在Zookeeper節點中，顯然Zookeeper不適合多寫的應用場景。在新版的消費者中將消費位移存儲在了Kafka內部的主題__consumer_offsets中。每當消費者有消費位移提交時，會通過OffsetCommitRequest請求將所提交的位移發送給消費者所屬消費組對應的組協調器GroupCoordinator中，組協調器GroupCoordinator會將消費位移存入到__consumer_offsets主題中，同時也會在內存中保留一份備份。Kafka重啟之后會將__consumer_offsets中所有的消息保存到內存中，即保存到各個GroupCoordinator中來進行維護。

如此看起來__consumer_offsets中的消費位移不會丟失，也就是說在step 5之后再創建一個相同消費組下的消費者時是會獲取（OffsetFetchRequest）到之前提交的位移信息的，事實是否真的如此，這里先賣個關子，我們從主題的刪除過程來進行切入分析。

就以topic-offset為例，我們可以通過kafka-topics.sh腳本、KafkaAdminClient等工具來刪除它，這波操作產生的最直接的結果就是在Kafka對應的Zoopeer中的/admin/delete_topics/路徑下創建一個以“topic-offset”命名的實節點。KafkaController會監聽/admin/delete_topics/路徑下的節點變化，當監聽到有節點變化時就會接過前面kafka-topics.sh腳本、KafkaAdminClient等工具的交接棒，負責接下去的具體的刪除工作，對于刪除“topic-offset”而言，具體的工作有如下：

刪除Zookeeper中的/admin/delete_topics/topic-offset節點、/brokers/topics/topic-offset節點以及/config/topics/topic-offset節點，后兩個節點和主題的元數據信息、配置信息有關，所以也要刪除掉。

通知各個broker節點將主題“topic-offset”下的所有日志文件標記刪除，具體可以查看Kafka日志刪除那部分的細節。

通知各個broker節點中的GroupCoordinator以刪除有關此主題的消費位移信息。
前兩個大家都能猜想的出來，第3個大家未必有所了解。GroupCoordinator會遍歷旗下所有的消費組，然后刪除有關topic-offset的分區信息，并且通過在__consumer_offsets中設置墓碑消息來刪除對應的記錄。

下圖中__consumer_offsets主題中有關消費位移的消息格式，圖中上半部分表示消息的key，里面包含version（版本信息）、group（消費組的名稱）、topic（主題名稱，這里就是topic-offset）以及partition（分區編號）；圖中下半部分表示消息的value，對于墓碑消息來說，value設置為null，由于__consumer_offsets的清理策略是compact的，這個墓碑消息最終會被清除掉。

分析到這里，我們再來回顧文中開篇的問題，相信到這里答案已經顯而易見了，刪除了主題之后會順帶著將主題相關的所有消費位移信息全部刪除，故在step 5之后的新消費者無跡可尋，故只能按照其所配置的auto.offset.reset參數來做具體的earliest或者lateset的重置消費。

本文中涉及到的概念有GroupCoordinator、KafkaController、Kafka日志刪除、Kafka協議、GroupMetadata、墓碑消息等，如果你對此一無所知或者一知半解的話，那么說明你對Kafka的認知接近為0，如何排解未知的恐慌？——掃描關注微信公眾號：朱小廝的博客。

歡迎跳轉到本文的原文鏈接：https://honeypps.com/mq/the-secret-behind-kafka-topic-deletion/

---

歡迎支持筆者新作：《深入理解Kafka:核心設計與實踐原理》和《RabbitMQ實戰指南》，同時歡迎關注筆者的微信公眾號：朱小廝的博客。

---

總結

以上是生活随笔為你收集整理的Kafka冷门知识——主题删除背后的秘密的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。