從kafka的底層實現來說，主題和分割槽都是邏輯上的概念，分割槽可以有一至多個副本，每個副本對應乙個日誌檔案，每個日誌檔案對應一至多個日誌分段（logsegment），每個日誌分段還可以細分為索引檔案、日誌儲存檔案和快照檔案等。
kafka會預設建立主題
如果broker端配置引數auto.create.topics.enable設定為true（預設值就是true），那麼當生產者向乙個尚未建立的主題傳送訊息時，會自動建立乙個分割槽數為num.partitions （預設值為1）、副本因子為default.replication.factor（預設值為1）的主題。
除此之外，當乙個消費者開始從未知主題中讀取訊息時，或者當任意乙個客戶端向未知主題傳送元資料請求時，都會按照配置引數num.partitions和default.replication.factor的值來建立乙個相應的主題。很多時候，這種自動建立主題的行為都是非預期的。除非有特殊應用需求，否則不建議將auto.create.topics.enable引數設定為true，這個引數會增加主題的管理與維護的難度。
kafka的修改主題的api支援對topic擴充套件分割槽，不支援減少分割槽
當主題中的訊息包含key時（即key不為null），根據key計算分割槽的行為就會受到影響。當topic-config的分割槽數為1時，不管訊息的key為何值，訊息都會發往這乙個分割槽；當分割槽數增加到3時，就會根據訊息的key來計算分割槽號，原本發往分割槽0的訊息現在有可能會發往分割槽1或分割槽2。如此還會影響既定訊息的順序，所以在增加分割槽數時一定要三思而後行。對於基於key計算的主題而言，建議在一開始就設定好分割槽數量，避免以後對其進行調整。
按照kafka現有的**邏輯，此功能完全可以實現，不過也會使**的複雜度急劇增大。實現此功能需要考慮的因素很多，比如刪除的分割槽中的訊息該如何處理？如果隨著分割槽一起消失則訊息的可靠性得不到保障；如果需要保留則又需要考慮如何保留。直接儲存到現有分割槽的尾部，訊息的時間戳就不會遞增，如此對於spark、flink這類需要訊息時間戳（事件時間）的元件將會受到影響；如果分散插入現有的分割槽，那麼在訊息量很大的時候，內部的資料複製會占用很大的資源，而且在複製期間，此主題的可用性又如何得到保障？與此同時，順序性問題、事務性問題，以及分割槽和副本的狀態機切換問題都是不得不面對的。反觀這個功能的收益點卻是很低的，如果真的需要實現此類功能，則完全可以重新建立乙個分割槽數較小的主題，然後將現有主題中的訊息按照既定的邏輯複製過去即可。
kafka的修改副本數支援新增和減少
kafka的可以通過重分配分割槽來下線某個節點
當有3個節點，需要下線某個節點。要不分割槽遷移到其他兩個broker上
kafka-reassign-partitions.sh 指令碼的使用分為 3 個步驟：首先建立需要乙個包含主題清單的json檔案，其次根據主題清單和 broker 節點清單生成乙份重分配方案，最後根據這份方案執行具體的重分配動作。
分割槽重分配本質在於資料複製，先增加新的副本，然後進行資料同步，最後刪除舊的副本來達到最終的目的。資料複製會占用額外的資源，如果重分配的量太大必然會嚴重影響整體的效能，尤其是處於業務高峰期的時候。減小重分配的粒度，以小批次的方式來操作是一種可行的解決思路。如果集群中某個主題或某個分割槽的流量在某段時間內特別大，那麼只靠減小粒度是不足以應對的，這時就需要有乙個限流的機制，可以對副本間的複製流量加以限制來保證重分配期間整體服務不會受太大的影響。
kafka自動平衡分割槽(預設開啟，不建議開啟)
在 kafka 中可以提供分割槽自動平衡的功能，與此對應的 broker 端引數是auto.leader.rebalance.enable，此引數的預設值為true，即預設情況下此功能是開啟的。如果開啟分割槽自動平衡的功能，則 kafka 的控制器會啟動乙個定時任務，這個定時任務會輪詢所有的 broker節點，計算每個broker節點的分割槽不平衡率（broker中的不平衡率=非優先副本的leader個數/分割槽總數）是否超過leader.imbalance.per.broker.percentage引數配置的比值，預設值為 10%，如果超過設定的比值則會自動執行優先副本的選舉動作以求分割槽平衡。執行週期由引數leader.imbalance.check.interval.seconds控制，預設值為300秒，即5分鐘。
不過在生產環境中不建議將auto.leader.rebalance.enable設定為預設的true，因為這可能引起負面的效能問題，也有可能引起客戶端一定時間的阻塞。因為執行的時間無法自主掌控，如果在關鍵時期（比如電商大促波峰期）執行關鍵任務的關卡上執行優先副本的自動選舉操作，勢必會有業務阻塞、頻繁超時之類的風險。前面也分析過，分割槽及副本的均衡也不能完全確保集群整體的均衡，並且集群中一定程度上的不均衡也是可以忍受的，為防止出現關鍵時期「掉鍊子」的行為，筆者建議還是將掌控權把控在自己的手中，可以針對此類相關的埋點指標設定相應的告警，在合適的時機執行合適的操作，而這個「合適的操作」就是指手動執行分割槽平衡。
kafka中kafka-perferred-replica-election.sh指令碼提供了對分割槽leader副本進行重新平衡的功能
在實際生產環境中，一般使用 path-to-json-file 引數來分批、手動地執行優先副本的選舉操作。尤其是在應對大規模的 kafka 集群時，理應杜絕採用非 path-to-json-file引數的選舉操作方式。同時，優先副本的選舉操作也要注意避開業務高峰期，以免帶來效能方面的負面影響。
Kafka的topic主題的命令操作
topic主題操作 開啟kafka?bin kafka server start.sh config server.properties 或者 指令碼一鍵啟動 或者 進入到kafka的bin目錄 sh kafka server start.sh 開啟 每乙個kafka的命令都有寫入 bootstra...
kafka刪除topic的方法
0.8的官方文件提供了乙個刪除topic的命令 kafka topics.sh delete 但是在執行時會報錯找不到這個方法。kafka topics.sh最終是執行了kafka.admin.topiccommand這個類，在0.8的原始碼中這個類中沒有找到有delete topic相關的 在ka...
Kafka主題 topic 的刪除
step1 如果需要被刪除topic 此時正在被程式 produce和consume，則這些生產和消費程式需要停止。因為如果有程式正在生產或者消費該topic，則該topic的offset資訊一致會在broker更新。呼叫kafka delete命令則無法刪除該topic。同時，需要設定 auto....