消息在kafka保留多長時間？
消息保存72小時，超過72小時的消息將會被刪除。
Kafka可以創建多少個主題？
Kafka基礎版可以創建50個主題、Kafka高級版可以創建100個主題。
如果想消費已經被消費過的數據？
consumer是底層采用的是一個阻塞隊列，只要一有producer生產數據，那consumer就會將數據消費。當然這里會產生一個很嚴重的問題，如果你重啟一消費者程序，那你連一條數據都抓不到，但是log文件中明明可以看到所有數據都好好的存在。換句話說，一旦你消費過這些數據，那你就無法再次用同一個groupid消費同一組數據了。針對這種情況，你可在控制臺重置消費組消費點（3天內）。
是否需要預先創建消費組
消費組和消費組訂閱主題關系雖然業務應用客戶端接入時可自動創建，但建議都先預先創建做好管理。
出現“Not authorized to access group”的錯誤信息
沒有創建消費組時會遇到此報錯信息，創建消費組可解決此問題。
為什么PHP發送延時比較長？
PHP發送延時比較長是PHP的語言特性導致的。PHP每次發送時，都會重新初始化一個KafkaProducer對象，這個初始化會進行各種操作，包括連接各個Broker、更新元數據等，在VPC內耗時100ms以上，在公網可能耗時500ms以上。相比之下，Java會復用KafkaProducer，發送延遲較低。
哪里可以找到生產消費消息的示例
最佳實踐 - 生產者實踐、消費者實踐。
如何進行發送消息的測試？
可以直接在Kafka控制臺進行發送消息的測試。在控制臺的Topic管理頁面，單擊目標Topic右側的生產撥測，進行消息發送測試，以驗證集群是否運轉正常。
使用客戶端發送消息后，如何確定是否發送成功？
如果回調成功則說明消息發送成功。大部分客戶端在發送之后，會返回Callback或者Future，如果回調成功，則說明消息發送成功。
此外，還可以在控制臺通過以下方式確認消息發送是否正常：
查看“監控信息”，實例消息生產條數。
查看“消息查詢”，可按時間查詢消息。
發送消息的回調是否會影響發送速度？
Java客戶端設置回調是否會影響消息發送的速度取決于如下兩點：
（1）回調的處理耗時：為減少回調的處理耗時，不要過于頻繁地在回調做耗時較長的處理。可以積累一定量Ack后再做批量的回調處理，或者在另一個異步的線程去處理，從而不阻塞回調的完成。
（2）max.in.flight.requests.per.connection：該參數指定了生產者在收到服務器響應之前可以發送多少個消息。它的值越高，就會占用越多的內存，不過也會提升吞吐量。
實例支持哪些開源版本？
當前服務端支持的版本為2.3.1和2.8.2。實例創建后，服務端版本不支持升級，不支持定制版本。
如何選擇實例硬盤大小？
磁盤大小：流量均值×存儲時長×3（備份），建議在遷移上云過程中優化Topic以降低成本。
升級Broker可能產生哪些影響？
升級Broker可能產生消息亂序、客戶端連接中斷、消息量不均衡等影響。
升級Broker包含以下影響：
升級過程中，會逐個重啟云消息隊列 Kafka 版集群中所有的Broker。在重啟Broker的過程中服務不會中斷，但是從每個Broker重啟完成之后的5分鐘內消費的分區消息可能會發生亂序。
- 重啟過程中已有的客戶端連接可能會中斷。客戶端要有自動重連功能，服務端的其他Broker會自動接替服務。
- 此外，升級和重啟Broker期間，各個分區處理的消息量也會出現一定的不均衡，需要評估一下升級變更對業務可能產生的影響。
升級所有Broker大概需要5分鐘~15分鐘。如果有多個實例，可以考慮先升級測試集群，驗證通過后再升級生產集群。
實例的地域無法變更？
實例購買部署之后，其地域與物理資源緊密結合，無法變更。如需變更實例的地域，請釋放實例，并重新購買。
如何快速測試分布式消息服務Kafka服務端是否正常？
前提條件
已創建并部署分布式消息服務Kafka實例，且實例處于服務中狀態。
操作流程
快速測試分布式消息服務Kafka服務端的流程如下：
（1）新建Topic
（2）在主題管理頁面，生產撥測，體驗發送消息
（3）在主題管理頁面，查看分區狀態
（4）在消息查詢頁面，按時間或位點查詢消息
是否支持延遲消息？
和開源Apache Kafka一樣，分布式消息服務Kafka同樣不支持延遲消息。
是否支持壓縮消息？
分布式消息服務Kafka服務端支持收發壓縮消息。
如需使用壓縮消息，需要在分布式消息服務Kafka的客戶端進行設置。在分布式消息服務Kafka客戶端進行消息壓縮的說明如下：
壓縮格式：支持Snappy、LZ4、GZIP等壓縮格式。其中，GZIP對CPU的消耗較高，因此不建議選擇GZIP，建議選擇Snappy或LZ4。
適用場景：一般來說，CPU的價格比流量和存儲要高。對于日志類等壓縮比較高的場景，可以考慮使用壓縮。其余場景，不建議使用壓縮。
CPU消耗：壓縮會消耗額外的CPU，平均在20%以上。具體額外CPU消耗，需要根據實際場景進行測試。
如何釋放實例？
若不再需要使用實例，可以在控制臺上退訂實例。
為什么限制Topic總數（分區總數）？
Topic總數（分區總數）太多會使集群性能和穩定性能急劇下降。
分布式消息服務Kafka的存儲和協調機制是以分區為粒度的，分區數太多，會導致存儲碎片化嚴重，集群性能和穩定性都會急劇下降。
為什么Topic不能減分區？
Topic減分區會造成數據丟失，這是Apache Kafka自身設計所限制的。
是否支持Compact的日志清理策略？
開源版本為2.2.0或以上的分布式消息服務Kafka實例支持Compact的日志清理策略。
如何查看哪些IP在消費消息？
在控制臺消費組管理頁面，查看消費實例。
哪里可以找到消費最佳實踐？
最佳實踐 - 消費者實踐。
如何在修改Consumer的offset？
提交消費位點的機制取決于客戶端SDK，一般支持以下兩種機制：
自動提交：按照時間間隔，SDK把消費過的最新消息的位點+1提交上去。
手動提交：應用程序里，把消費過的最新消息的位點+1提交上去。
在控制臺的消費組管理頁面，可以重置消費位置。
為什么在控制臺看不到Group的訂閱關系？
問題現象
已啟動某個Group的消費線程，但在分布式消息服務Kafka控制臺的消費組管理頁面，查不到該Group訂閱的Topic信息。
可能原因
客戶端的配置錯誤或者所處的網絡環境異常導致無法成功訂閱消息。
采用assign方式手動指定消費者訂閱某個Topic分區的消息，并未提交消費位點。
解決方案
排查客戶端配置問題
排查客戶端網絡問題
需提交消費位點
為什么同一個分區被多個消費線程消費了？
消費客戶端使用“StickyAssignor”分配模式消費消息時，發現同一個分區被多個消費線程消費，出現數據錯亂的情況。
可能原因
客戶端低于2.3版本。2.3版本以前的客戶端有可能將同一個分區分配給多個消費線程進行消費。
解決方案
建議您升級客戶端至2.3或以上版本，或者換成其他分區分配策略。
使用建議：“StickyAssignor”分配策略目前在一些情況下會產生分配偏差，比如分區重復分配問題。如果不是業務特殊需求，不建議使用該分配策略。
為什么Group的狀態一直處于“刪除中”？
當前刪除Group采用的是異步刪除方式，一般情況下，刪除一個Group大概需要耗時1-2分鐘。
問題現象
在分布式消息服務Kafka控制臺的消費組管理頁面刪除Group后，此Group的狀態一直處于刪除中。刪除中
可能原因
Group中存在活躍的訂閱關系。
Group上有消費線程在提交新的消費位點。
解決方案
登錄分布式消息服務Kafka控制臺，查看Group的訂閱關系。
若查詢到Group訂閱了Topic或者有消費線程在提交新的消費位點，請先取消訂閱關系再刪除Group。
為什么消費組的消息堆積量為“0”或者未顯示
查看Group的消費狀態時，消費位點不等于最大位點，但Group的堆積量顯示為“0”，或者未顯示。
可能原因
未曾提交過消費位點，或者消費位點已過期。
提交過消費位點并且未過期，但由于部分消息數據過期被刪除，導致消費位點小于或者等于最小位點。
為什么不能登錄部署分布式消息服務Kafka的機器？
分布式消息服務Kafka提供全托管免運維服務，您無需登錄機器，集群的一些基礎信息會通過監控告警進行透傳。
修改企業項目，是否會導致Kafka重啟？
修改企業項目不會導致Kafka重啟。
Kafka實例支持批量導入Topic功能么？
支持批量創建Topic，可下載批量創建模板填寫信息后導入。見操作指南批量創建Topic。
消息被消費后，沒有刪除，導致Kafka存儲空間占滿？
當消息被消費后，Kafka默認情況下并不會立即刪除它們，而是將其保留在磁盤上。這可能會導致Kafka存儲空間占滿的問題。
Kafka可以刪除消費組下不用的Topic嗎？
可以。操作步驟如下：
（1）登錄管理控制臺。
（2）進入Kafka管理控制臺。
（3）在實例列表頁在操作列，目標實例行點擊“管理”。
（4）點擊“主題管理”后進入主題管理頁面后點擊“更多”，出現如下圖彈窗。
（5）在Topic所在行，單擊“刪除”，并選擇確定。
Kafka實例是否需要創建消費組、生產者和消費者？
不需要額外創建，支持創建消費組，操作步驟如下：
（1）登錄管理控制臺。
（2）進入Kafka管理控制臺。
（3）在實例列表頁在操作列，目標實例行點擊“管理”。
（4）點擊“消費組管理”后進入消費組管理頁面。
（5）點擊“新建消費組”后，輸入消費組名稱，點擊創建。
注：消費組業務應用接入使用時客戶端也可自動創建。
Kafka生產消息的最大長度是多少？
Kafka生產消息的最大長度默認情況下為1MB。
消息超過老化時間，消息仍存在的原因
消息超過老化時間（message retention time）仍然存在的原因可能有以下幾種情況：
- 消息存儲配置錯誤：可能是由于配置錯誤導致消息的老化時間沒有按照預期進行清理。您可以檢查Kafka的配置文件中log.retention.ms或log.retention.hours參數，確保其設置正確。
- 消費者組延遲或故障：如果消息被分發給了一個消費者組，但消費者組中的某個消費者出現延遲或故障，導致消息無法及時消費，那么這些消息可能會超過老化時間而仍然存在。
- 消息處理邏輯問題：在消費者端的消息處理邏輯中可能存在問題，導致消息無法被及時處理或消費。這可能是由于代碼bug、處理邏輯錯誤或其他原因引起的。
- 多個分區或主題的不一致：如果您的消息被分布在多個分區或主題中，而某些分區或主題的老化時間設置與其他分區或主題不一致，那么消息可能會在某些分區或主題中超過老化時間而仍然存在。
為了解決這個問題，您可以采取以下措施：
- 檢查Kafka的配置文件，確保消息的老化時間設置正確。
- 檢查消費者組的消費情況，確保消費者能夠及時消費消息。
- 檢查消費者端的消息處理邏輯，確保消息能夠被正確處理和消費。
- 檢查分區或主題的配置，確保它們的老化時間設置一致。
控制臺消費組管理不能訂閱Topic的問題
消費組如需消費某個Topic，無需在控制臺新建訂閱，直接訂閱消費即可。如果需要使用sasl連接進行生產消費，可以在用戶管理頁面對用戶權限進行管理，增加用戶對Topic的生產消費權限。
