網上看到一篇文章ckafka消費者組反覆重平衡問題解決之道給了點思路：
也參見了kafka消費者平凡被踢出消費者組的問題排查
然後寫了這篇文章kafka高低版本的心跳(heartbeats)和會話(session)超時機制
以下把ckafka的思路記錄了下
ckafka 消費重平衡機制同開源kafka一樣，就是讓乙個消費者組下所有的 consumer 例項就如何消費訂閱主題的所有分割槽達成共識的過程。在重平衡過程中，所有 consumer 例項共同參與，在協調者元件的幫助下，完成訂閱主題分割槽的分配。但是，在整個過程中，所有例項都不能消費任何訊息，會影響到我們業務訊息的正常消費。
ckafka 重平衡的弊端主要有3個：
1、重平衡會影響consumer 端 tps，從而影響整體消費端效能。
2、重平衡過程很慢。如果某個消費者下面的 group 下成員很多，就會遇到這樣的痛點。
3、重平衡效率不高。所有消費成員都要參與，每個消費成員都需要重新搶占分割槽來進行消費。
所以我們在使用ckafka進行訊息消費的時候，需要注意盡量避免消費重平衡。
要避免消費端的重平衡，還是要從 rebalance 發生的時機入手。
rebalance 發生的時機有三個：1、消費組成員數量發生變化。2、訂閱主題數量發生變化。3、訂閱主題的分割槽數發生變化。
訂閱主題數量和訂閱主題分割槽數量變化這兩個通常都是運維的主動操作，所以它們引發的 rebalance 大都是不可避免的。接下來，我們主要說說因為組成員數量變化而引發的重平衡該如何避免。如果 consumer group 下的 consumer 例項數量發生變化，就一定會引發重平衡。這是 rebalance 發生的最常見的原因。一般來說我們碰到的 99% 的 重平衡，都是這個原因導致的。
consumer 例項數增加的情況很好理解，當我們啟動乙個配置有相同 group.id 值的 consumer 應用程式時，實際上就向這個 group 新增了乙個新的 consumer 例項成員。此時，ckafka的coordinator 會接納這個新例項，將其加入到組中，並重新分配分割槽。通常來說，增加 consumer 例項的操作都是計畫內的，可能是出於增加 tps 或提高伸縮性的需要。總之，它不屬於我們要規避的那類「不必要 rebalance」。
對於consumer 例項數減少的情況，需要分2種情況來看：1、開發者自行停掉某些 consumer 例項，這種屬於正常現象。另外一種情況是：consumer 例項會被 coordinator 錯誤地認為「已停止」從而被「踢出」group。如果是這個原因導致的 重平衡，那麼我們就要盡量去進行規避了。
當我們的消費程式出現間接性消費緩慢或者超時異常的時候，可能是遇到消費者組重平衡了，我們可以通過ckafka控制台進行驗證。接下來我們就要聊聊如果規避了。
當 consumer group 完成 重平衡之後，每個 consumer 例項都會定期地向 coordinator 傳送心跳請求，表明它還存活著。如果某個 consumer 例項不能及時地傳送這些心跳請求，coordinator 就會認為該 consumer 已經「死」了，從而將其從 group 中移除，然後開啟新一輪重平衡。
consumer 端有個引數，叫 session.timeout.ms，就是被用來表徵此事的。該引數的預設值是 10 秒，即如果 coordinator 在 10 秒之內沒有收到 group 下某 consumer 例項的心跳，它就會認為這個 consumer 例項已經掛了。可以這麼說，session.timeout.ms 決定了 consumer 存活性的時間間隔。除了這個引數，consumer 還提供了乙個允許你控制傳送心跳請求頻率的引數，就是 heartbeat.interval.ms。這個值設定得越小，consumer 例項傳送心跳請求的頻率就越高。頻繁地傳送心跳請求會額外消耗頻寬資源，但好處是能夠更加快速地知曉當前是否開啟 rebalance。
第一類非必要 rebalance 是因為未能及時傳送心跳，導致 consumer 被「踢出」group 而引發的。因此，需要仔細地設定 session.timeout.ms 和 heartbeat.interval.ms 的值。在這裡給出一些推薦數值：
1、設定 session.timeout.ms = 6s。
2、設定 session.timeout.ms = 6s。
3、要保證 consumer 例項在被判定為「dead」之前，能夠傳送至少 3 輪的心跳請求，即 session.timeout.ms >= 3 * heartbeat.interval.ms。
第二類非必要 rebalance 是 consumer 消費時間過長導致的。例如在這樣的場景中，consumer 消費資料時需要將訊息處理之後寫入到 mongodb。顯然，這是乙個很重的消費邏輯。mongodb 的一丁點不穩定都會導致 consumer 程式消費時長的增加。此時，max.poll.interval.ms 引數值的設定顯得尤為關鍵。如果要避免非預期的 rebalance，你最好將該引數值設定得大一點，比你的下游最大處理時間稍長一點。就拿 mongodb 這個例子來說，如果寫 mongodb 的最長時間是 7 分鐘，那麼你可以將該引數設定為 8 分鐘左右。
72 經常重新造輪子
用一些已有的東西就可以了，重新造輪子是很傻的.你否曾經聽說過這句話或者類似的說法？肯定的！每個開發人員和學生都可能經常聽到這樣的論調。然而為什麼呢？為什麼重新造輪子這麼不被贊同？因為，通常情況下，已有 是管用的。它已經經過了一定的質量控制 嚴格測試，而且成功應用了。此外，投入重新創造的時間和精力的回...
面試經常問的問題
1.擊穿 少量的key過期造成併發訪問資料庫 前期肯定發生了高併發 解決辦法 百萬併發過來 需要訪問快取中k1，redis是單程序的，當發現null後，執行setnx獲取鎖，獲鎖成功 則到db中取資料，獲鎖失敗 sleep一會兒。2.穿透 查詢不存在的資料 解決辦法 布隆過濾器 一種寫是在clien...
kafka分割槽重新分配
擴容kafka之後，針對擴容之前的topic進行重新平衡leader，replicas，isr 1.生成分配計畫 新建乙個json檔案，內容如下 topic為要修改的topic 這裡檔案取名為 topics to move.json version 1 使用kafka reassign partit...