Kafka實例的Topic數量是否有限制？
Topic數量和Topic總分(fen)區(qu)數、每個Topic的分(fen)區(qu)數有(you)關，Kafka實例(li)對Topic總分(fen)區(qu)數設置(zhi)了上限，當達(da)到上限后，會導(dao)致用戶無法繼續創建(jian)Topic。
不(bu)同(tong)規格配置的Topic總(zong)分區數不(bu)同(tong)，如下表所示。
表 Kafka實例規格
| 實例規格 | 代理個數范圍 | 單個代理TPS | 單個代理分區上限 | 單個代理Consumer Group上限 | 單個代理客戶端總連接數上限 | 存儲空間范圍 |
|---|---|---|---|---|---|---|
| kafka.2u4g.cluster | 3~30 | 30000 | 250 | 20 | 2000 | 300GB~300000GB |
| kafka.4u8g.cluster | 3~30 | 100000 | 500 | 100 | 4000 | 300GB~600000GB |
| kafka.8u16g.cluster | 3~30 | 150000 | 1000 | 150 | 4000 | 300GB~900000GB |
| kafka.12u24g.cluster | 3~30 | 200000 | 1500 | 200 | 4000 | 300GB~900000GB |
| kafka.16u32g.cluster | 3~30 | 250000 | 2000 | 200 | 4000 | 300GB~900000GB |
為什么限制Topic的總分區數？
Kafka以分(fen)區(qu)為粒(li)度(du)管理消(xiao)息，分(fen)區(qu)多(duo)導(dao)致生產、存儲、消(xiao)費(fei)都碎片(pian)化，影響(xiang)性能穩定性。在使用過程中，當Topic的(de)總分(fen)區(qu)數(shu)達到上限后，用戶就無法繼續創(chuang)建(jian)Topic。
不同規(gui)格配(pei)置的Topic總分區數不同，如下表(biao)所(suo)示。
表 Kafka實例規(gui)格
| 實例規格 | 代理個數范圍 | 單個代理TPS | 單個代理分區上限 | 單個代理Consumer Group上限 | 單個代理客戶端總連接數上限 | 存儲空間范圍 |
|---|---|---|---|---|---|---|
| kafka.2u4g.cluster | 3~30 | 30000 | 250 | 20 | 2000 | 300GB~300000GB |
| kafka.4u8g.cluster | 3~30 | 100000 | 500 | 100 | 4000 | 300GB~600000GB |
| kafka.8u16g.cluster | 3~30 | 150000 | 1000 | 150 | 4000 | 300GB~900000GB |
| kafka.12u24g.cluster | 3~30 | 200000 | 1500 | 200 | 4000 | 300GB~900000GB |
| kafka.16u32g.cluster | 3~30 | 250000 | 2000 | 200 | 4000 | 300GB~900000GB |
Kafka支持減少分區數嗎？
Kafka不支持減少分區(qu)數(shu)，您可以通過刪(shan)除原先的Topic，然后創建新(xin)Topic，重(zhong)新(xin)設置分區(qu)數(shu)。
Kafka實例創建Topic失敗
可能原因：已創建的Topic，分區數之和達到實例規格的分區數上限。不同規格實例配置的分區數上限不同，具體請參考產品規格。
解(jie)決方(fang)案：對(dui)Kafka實(shi)例擴容，或者刪除不需要的Topic。
Kafka實例支持批量導入Topic功能么？或者是自動生成Topic功能？
支持(chi)自動生成Topic功(gong)能(neng)，但不支持(chi)Topic批量(liang)導入功(gong)能(neng)，僅支持(chi)批量(liang)導出Topic功(gong)能(neng)。
通過以(yi)下任意一種方法，開啟自動生成Topic功能(neng)：
- 創建實例時，開啟Kafka自動創建Topic。
- 創建實例后，在實例詳情頁開啟Kafka自動創建Topic。
為什么刪除Topic不生效？刪除后該Topic仍然存在
可能原(yuan)因：您(nin)開(kai)啟了(le)自動創建Topic功能，且有消(xiao)費(fei)者正在連(lian)接該(gai)Topic。所以(yi)，如果(guo)沒有停止您(nin)的業務(wu)，刪除了(le)Topic后(hou)，還會有消(xiao)息生(sheng)產(chan)行(xing)為，并(bing)自動創建Topic。
解決辦(ban)法(fa)：需要關(guan)閉自(zi)動(dong)創建Topic功能，才(cai)可(ke)以正常(chang)刪除Topic。
Kafka實例是否支持查看單個Topic占用磁盤空間？
支(zhi)持(chi)。通過以下任意(yi)一種(zhong)方(fang)法，查看單個Topic占用磁盤空(kong)間大小。
- 在Kafka實例名稱后，單擊
，跳轉到云監控頁面。在“隊列”頁簽中，“隊列”選擇待查看磁盤空間大小的Topic名稱，“監控類型”選擇“基本監控”，查看“隊列數據容量”，該指標表示該隊列當前的消息數據大小。 - 單擊Kafka實例名稱，進入實例詳情頁。在左側導航欄單擊“監控”，進入監控頁面。在“主題”頁簽中，“主題”選擇待查看磁盤空間大小的Topic名稱，“監控類型”選擇“基本監控”，查看“隊列數據容量”，該指標表示該隊列當前的消息數據大小。
Topic是否支持ACL權限配置？
Kafka實例(li)已開啟(qi)Kafka SASL_SSL功能，此時Topic支(zhi)持配置ACL權(quan)(quan)限(xian)。在(zai)Kafka控制臺的“Topic管理”頁面，在(zai)需要設(she)置用(yong)戶(hu)(hu)權(quan)(quan)限(xian)的Topic所在(zai)行，單擊“設(she)置用(yong)戶(hu)(hu)權(quan)(quan)限(xian)”，為用(yong)戶(hu)(hu)設(she)置不同的權(quan)(quan)限(xian)。
具體操作請參考設置Topic權限。
消息被消費后，沒有刪除，導致Kafka存儲空間占滿？
消息被消費后，并不會被刪除(chu)，只有超過老(lao)化時間，才會被刪除(chu)。
您可以通過減小老化時間或者擴容存儲空間，解決此問題。
如何擴總分區？
增加(jia)基(ji)準(zhun)帶(dai)寬(kuan)/代(dai)理數量，可以(yi)擴大總分區(qu)數。
在Kafka控制臺的實例所在行，單擊“更多 > 變更規格”，進入變更規格頁面，根據實際情況擴容基準帶寬/代理數量。具體操作請參考變更實例規格。
修改自動創建Topic的配置，會觸發重啟嗎？
開啟或(huo)者(zhe)關閉“Kafka自動創(chuang)建Topic”，會導(dao)致(zhi)Kafka重啟。
如何關閉自動創建Topic功能？
- 在Kafka控制臺，單擊實例名稱，進入實例詳情頁面。
- 在“基本信息”頁面的“實例信息”區域，單擊“Kafka自動創建Topic”后的
，關閉自動創建Topic功能。
您可以在“后臺(tai)任(ren)務(wu)管理”頁簽(qian)，查看關閉任(ren)務(wu)執(zhi)行狀態。
Kafka可以刪除消費組下不用的Topic嗎？
可以刪除(chu)。在Kafka客戶端(duan)取消(xiao)訂(ding)閱該Topic，即可達到在消(xiao)費組(zu)下刪除(chu)該Topic的效果。
消費者消費Topic失敗，提示沒有權限？
問題現象： 同一個消(xiao)(xiao)(xiao)(xiao)費(fei)組內有多(duo)個消(xiao)(xiao)(xiao)(xiao)費(fei)者，為每(mei)個消(xiao)(xiao)(xiao)(xiao)費(fei)者授權不(bu)同的Topic訪問權限，某一消(xiao)(xiao)(xiao)(xiao)費(fei)者消(xiao)(xiao)(xiao)(xiao)費(fei)其中一個Topic時，提示消(xiao)(xiao)(xiao)(xiao)費(fei)失(shi)敗，報錯(cuo)信息如下(xia)：Not authorized to access topics。
問題原因： 消費(fei)組(zu)的(de)leader在進(jin)行(xing)分(fen)區(qu)分(fen)配(pei)(pei)時，不會考慮某一個消費(fei)者(zhe)的(de)授權(quan)(quan)和訂(ding)閱信(xin)息，只會根據消費(fei)組(zu)整體(ti)的(de)訂(ding)閱情(qing)況(kuang)進(jin)行(xing)分(fen)區(qu)分(fen)配(pei)(pei)，此種(zhong)情(qing)況(kuang)下可能會給消費(fei)者(zhe)分(fen)配(pei)(pei)到未(wei)授權(quan)(quan)的(de)Topic，從而導致(zhi)了上述問題的(de)出現。
例如：消費組(zu)中有(you)消費者A、B、C，A訂閱(yue)并(bing)授(shou)(shou)權Topic 0、Topic 1、Topic 2，B訂閱(yue)并(bing)授(shou)(shou)權Topic 3、Topic 4、Topic 5，C訂閱(yue)并(bing)授(shou)(shou)權Topic 6、Topic 7、Topic 8，假(jia)設以上(shang)Topic都(dou)只有(you)一個(ge)分(fen)區(qu)，消費組(zu)的(de)(de)leader會根(gen)據(ju)策略進(jin)行分(fen)區(qu)分(fen)配，分(fen)配的(de)(de)結(jie)果(guo)可能變成：A消費Topic 0、Topic 3、Topic 6，B消費Topic 1、Topic 4、Topic 7，C消費Topic 2、Topic 5、Topic 8。此(ci)時A對Topic 3和(he)Topic 6是沒(mei)有(you)授(shou)(shou)權的(de)(de)，因此(ci)會出現“Not authorized to access topics”的(de)(de)報錯。
圖消費者訪問權限
處理方法：
- 如果業務要求所有消費者在同一個消費組內，即group.id相同，解決方法：為所有消費者授權相同的Topic訪問權限。
- 如果消費者不需要在同一個消費組內，解決方法：修改group.id，讓每個消費者單獨在一個消費組內。
為什么實例中存在默認名為__trace和__consumer_offsets的Topic？
問題現象： Kafka Manager中存在默(mo)認名為__trace和__consumer_offsets的Topic。
處理方法： __trace和__consumer_offsets是Kafka實例內部預留的Topic，不(bu)建議刪除(chu)(chu)這兩個Topic，刪除(chu)(chu)后可(ke)能導致實例無法(fa)使(shi)用。
