Kafka生產消息的最大長度是多少？

生(sheng)產消息的最大長度(du)為(wei)10M。

為什么Kafka實例常常發生Rebalance，導致消息拉取失敗？

消費組的(de)Rebalance就是對Topic分區的(de)重(zhong)新分配。

正常(chang)(chang)情況下消(xiao)費(fei)組內加(jia)入新的(de)消(xiao)費(fei)者(zhe)或老(lao)的(de)消(xiao)費(fei)者(zhe)退出都(dou)會(hui)導致Rebalance，這(zhe)種情況是無法避免(mian)的(de)。但是某些特殊(shu)情況下，消(xiao)費(fei)者(zhe)會(hui)被誤(wu)認為異(yi)常(chang)(chang)從而被踢出消(xiao)費(fei)組，此時(shi)可能會(hui)導致消(xiao)費(fei)異(yi)常(chang)(chang)，需要重點關注。

消(xiao)費(fei)(fei)者被誤認為異常從(cong)而被踢(ti)出消(xiao)費(fei)(fei)組的場景如下：

1. 未能及時發送心跳請求。

消(xiao)費者以設(she)置的heartbeat.interval.ms為間(jian)隔向broker發送心(xin)跳請求(qiu)，如果broker在session.timeout.ms時間(jian)內(nei)沒(mei)有收到消(xiao)費者的心(xin)跳請求(qiu)，broker會認為消(xiao)費者異(yi)常(chang)，從而將其(qi)從消(xiao)費組中(zhong)踢(ti)出，然后開始新一(yi)輪的Rebalance。

2. 消費者消費時間間隔過長。

消(xiao)(xiao)費(fei)(fei)者每次(ci)最(zui)多消(xiao)(xiao)費(fei)(fei)max.poll.records條消(xiao)(xiao)息，多數情(qing)況下(xia)客戶端(duan)都會把(ba)一(yi)次(ci)消(xiao)(xiao)費(fei)(fei)到的數據(ju)處理完后才會開(kai)始(shi)(shi)下(xia)一(yi)次(ci)消(xiao)(xiao)費(fei)(fei)，如(ru)果單次(ci)消(xiao)(xiao)費(fei)(fei)的消(xiao)(xiao)息太多導(dao)致無法(fa)在max.poll.interval.ms時間(jian)(jian)內處理完或消(xiao)(xiao)息處理流(liu)程發生了(le)異常（如(ru)需要寫入后端(duan)數據(ju)庫(ku)，后端(duan)數據(ju)庫(ku)壓力太大，時延增加(jia)等）導(dao)致消(xiao)(xiao)費(fei)(fei)時間(jian)(jian)增加(jia)，在max.poll.interval.ms時間(jian)(jian)內消(xiao)(xiao)費(fei)(fei)者沒有(you)發起下(xia)一(yi)次(ci)消(xiao)(xiao)費(fei)(fei)請求，broker認(ren)為(wei)消(xiao)(xiao)費(fei)(fei)者不活躍而將其踢出(chu)消(xiao)(xiao)費(fei)(fei)組(zu)，然后開(kai)始(shi)(shi)新一(yi)輪(lun)的Rebalance。

解決方法/排查思路

場景一： 未能及時發送心跳(tiao)請求

解決方法： 建議在消費者(zhe)客戶端將session.timeout.ms值設置(zhi)為heartbeat.interval.ms值3倍以上。

場景二： 消(xiao)(xiao)費(fei)者消(xiao)(xiao)費(fei)時(shi)間(jian)間(jian)隔過長

排查思路：

1. 檢查單條消息的處理時間是多久，處理max.poll.records條消息會不會超過max.poll.interval.ms時間。
2. 消息處理流程是否有網絡行為，如寫數據庫、調用后端API等，在發生Rebalance的場景下后端是否正常。

解決方法： 建議在消費者客戶(hu)端將max.poll.records值(zhi)減(jian)小。

為什么Console頁面上，消息查詢查不到消息？

• 可能原因1： 消息已被老化。

解決方法： 修改老化時間。

• 可能原因2： 消息的createTime時間戳不對。

Console頁面是根據時(shi)間(jian)查(cha)詢的(de)，所以查(cha)不(bu)到。時(shi)間(jian)戳是由客(ke)(ke)戶端生(sheng)成，不(bu)同客(ke)(ke)戶端有不(bu)同的(de)處理策略(lve)，有的(de)客(ke)(ke)戶端默認值(zhi)會(hui)是0或者-1，則查(cha)詢不(bu)到消息。

解決方法： 檢查(cha)客戶端消息的createTime設置是否(fou)正(zheng)確。

• 可能原因3： 磁盤容量超過95%，且“容量閾值策略”設置為“自動刪除”。

“容量閾值策略(lve)”設置為“自動刪除(chu)”，表(biao)示磁(ci)盤(pan)容量達到(dao)95%時(shi)(shi)，系統(tong)會刪除(chu)最(zui)早(zao)的(de)10%的(de)消(xiao)息(xi)，以(yi)(yi)保證磁(ci)盤(pan)容量充足(zu)。當磁(ci)盤(pan)容量超過95%時(shi)(shi)，未到(dao)達老化(hua)時(shi)(shi)間的(de)消(xiao)息(xi)也會被刪除(chu)，所(suo)以(yi)(yi)可能會導致(zhi)部分消(xiao)息(xi)查詢不(bu)到(dao)。

解決方法： 修改容量(liang)閾(yu)值(zhi)(zhi)策略或(huo)擴(kuo)大磁(ci)盤容量(liang)。“容量(liang)閾(yu)值(zhi)(zhi)策略”設置為“生產(chan)受限”，表示(shi)一旦磁(ci)盤使用達到容量(liang)閾(yu)值(zhi)(zhi)95%，會導(dao)致(zhi)后續(xu)生產(chan)失敗(bai)，但保留(liu)了(le)當前磁(ci)盤中的數(shu)(shu)據(ju)，直(zhi)至數(shu)(shu)據(ju)自然(ran)老化(hua)。該場(chang)(chang)景(jing)適用于對數(shu)(shu)據(ju)不能丟的業務(wu)場(chang)(chang)景(jing)，但是會導(dao)致(zhi)生產(chan)業務(wu)失敗(bai)。

Kafka消息堆積了怎么辦？

問題現象： 實例的監控(kong)指標“堆(dui)積(ji)消息數(shu)”產生了(le)告(gao)警。

處理方法： 登錄Kafka Manager，找出消(xiao)息堆積的消(xiao)費(fei)組(zu)，觀(guan)察消(xiao)費(fei)組(zu)是否有(you)消(xiao)費(fei)者(zhe)在消(xiao)費(fei)，如果(guo)有(you)，讓業務(wu)方加快(kuai)消(xiao)費(fei)效率，如果(guo)沒(mei)有(you)，讓客(ke)戶酌(zhuo)情刪(shan)掉(diao)不使(shi)用的消(xiao)費(fei)組(zu)。

消息超過老化時間，消息仍存在的原因

問題現象： 消(xiao)息超(chao)過(guo)設(she)置(zhi)的(de)老(lao)化時(shi)(shi)間(jian)(jian)（如果Topic已經(jing)設(she)置(zhi)了老(lao)化時(shi)(shi)間(jian)(jian)，此(ci)(ci)時(shi)(shi)“配置(zhi)參(can)數(shu)”中的(de)log.retention.hours值將不(bu)對(dui)(dui)此(ci)(ci)Topic生效(xiao)。僅在Topic中未設(she)置(zhi)老(lao)化時(shi)(shi)間(jian)(jian)時(shi)(shi)，“配置(zhi)參(can)數(shu)”中的(de)log.retention.hours值才會對(dui)(dui)此(ci)(ci)Topic生效(xiao)。），消(xiao)息仍存在。

可能原因1： Topic的(de)(de)每個(ge)(ge)分區都是(shi)(shi)由(you)多個(ge)(ge)大小相同的(de)(de)segment文(wen)(wen)件(jian)(jian)組成，每個(ge)(ge)segment文(wen)(wen)件(jian)(jian)的(de)(de)大小為500MB，當segment文(wen)(wen)件(jian)(jian)存(cun)儲(chu)的(de)(de)消(xiao)息(xi)(xi)大小到達(da)500MB后(hou)，才會(hui)新建下一個(ge)(ge)segment文(wen)(wen)件(jian)(jian)。Kafka刪(shan)除(chu)消(xiao)息(xi)(xi)是(shi)(shi)刪(shan)除(chu)segment文(wen)(wen)件(jian)(jian)，而(er)不是(shi)(shi)刪(shan)除(chu)一條消(xiao)息(xi)(xi)。Kafka要求(qiu)至少保留一個(ge)(ge)segment文(wen)(wen)件(jian)(jian)用來存(cun)儲(chu)消(xiao)息(xi)(xi)，如果正在(zai)使用的(de)(de)segment文(wen)(wen)件(jian)(jian)中包含超過老化時間的(de)(de)消(xiao)息(xi)(xi)，由(you)于此時segment文(wen)(wen)件(jian)(jian)不會(hui)被刪(shan)除(chu)，所以超過老化時間的(de)(de)消(xiao)息(xi)(xi)也(ye)不會(hui)被刪(shan)除(chu)。

處理方法： 等待(dai)segment文件被使用(yong)完，或者刪除超過老化時間的消(xiao)息所在的Topic。

可能原因2： Topic中存在一條create time為未來時(shi)間(jian)的消(xiao)(xiao)息（例如當前(qian)時(shi)間(jian)為1月1日，create time設置成(cheng)了2月1日），此消(xiao)(xiao)息在72小時(shi)后，并不會被老(lao)化(hua)，導致在此消(xiao)(xiao)息后創建的其他消(xiao)(xiao)息都(dou)不會被老(lao)化(hua)。

處理方法： 刪除create time為(wei)未(wei)來時間的消息所(suo)在的Topic。

Kafka實例是否支持延遲消息？

不支持延遲消息。

如何查看堆積消息數？

通過以下任(ren)意(yi)一種方法，查看(kan)堆積消息數。

• 在Kafka控制臺的“消費組管理”頁面，單擊待查看堆積消息的消費組名稱，進入消費組詳情頁。在“消費進度”頁簽，查看消費組中每個Topic的總堆積數。具體步驟，請參考查詢消費組信息。

• 在Kafka控制臺的“監控”頁面的“消費組”頁簽中，“消費組”選擇待查看堆積消息數的消費組名稱，“隊列”選擇“全部隊列”，“消費組可消費消息數”表示此消費組中所有Topic的堆積消息數之和。查看監控數據的具體步驟，請參考查看監控數據。

• 在云監控頁面的“消費組”頁簽中，“消費組”選擇待查看堆積消息數的消費組名稱，“隊列”選擇“全部隊列”，“消費組可消費消息數”表示此消費組中所有Topic的堆積消息數之和。查看監控數據的具體步驟，請參考查看監控數據。

• 在Kafka客戶端，在“/{命令行工具所在目錄}/kafka_{version}/bin/”目錄下，通過 kafka-consumer-groups.sh --bootstrap-server {kafka連接地址} --describe --group {消費組} 命(ming)令查看消(xiao)費組(zu)中(zhong)每個Topic的堆(dui)積(ji)消(xiao)息(xi)數(shu)。“LAG”表示(shi)每個Topic的總堆(dui)積(ji)數(shu)。

圖 查(cha)看每(mei)個Topic的總(zong)堆積數

說明

如果Kafka實例開啟SASL認證，則以上命令還需要增加SASL認證的“consumer.properties”配置文件參數： --command-config {SASL認證的consumer.properties配置文件} ，“consumer.properties”配置文件參考開啟SASL認證的Kafka命令行連接說明。

為什么消息創建時間顯示1970？

消息創建時間是由生產客戶端在生產消息時通過CreateTime指定(ding)的，如果生(sheng)產消息(xi)時沒有設置此參(can)數(shu)，消息(xi)創建時間會默認為(wei)1970。