點(diǎn)擊“程序員面試吧”，選擇“星標(biāo)??”
下拉至文末查看更多
快遞小哥手上有很多快遞需要送，他每次都需要先電話一一確認(rèn)收貨人是否有空、哪個(gè)時(shí)間段有空，然后再確定好送貨的方案。這樣完全依賴收貨人了！如果快遞一多，快遞小哥估計(jì)的忙瘋了……如果有了便利店，快遞小哥只需要將同一個(gè)小區(qū)的快遞放在同一個(gè)便利店，然后通知收貨人來取貨就可以了，這時(shí)候快遞小哥和收貨人就實(shí)現(xiàn)了解耦！快遞小哥打電話給我后需要一直在你樓下等著，直到我拿走你的快遞他才能去送其他人的。快遞小哥將快遞放在小芳便利店后，又可以干其他的活兒去了，不需要等待你到來而一直處于等待狀態(tài)。提高了工作的效率。假設(shè)雙十一我買了不同店里的各種商品，而恰巧這些店發(fā)貨的快遞都不一樣，有中通、圓通、申通、各種通等……更巧的是他們都同時(shí)到貨了！中通的小哥打來電話叫我去北門取快遞、圓通小哥叫我去南門、申通小哥叫我去東門。我一時(shí)手忙腳亂……我們能看到在系統(tǒng)需要交互的場(chǎng)景中，使用消息隊(duì)列中間件真的是好處多多，基于這種思路，就有了豐巢、菜鳥驛站等比小芳便利店更專業(yè)的“中間件”了。
ack：producer收到多少broker的答復(fù)才算真的發(fā)送成功- 0表示producer無需等待leader的確認(rèn)(吞吐最高、數(shù)據(jù)可靠性最差)
- 1代表需要leader確認(rèn)寫入它的本地log并立即確認(rèn)
- -1/all 代表所有的ISR都完成后確認(rèn)(吞吐最低、數(shù)據(jù)可靠性最高)
問題4：Kafka 如何判斷節(jié)點(diǎn)是否存活
（2）如果節(jié)點(diǎn)是個(gè) follower,他必須能及時(shí)的同步 leader 的寫操作，延時(shí)不能太久問題5：Kafka 消息是采用 Pull 模式，還是 Push 模式
Kafka 最初考慮的問題是，customer 應(yīng)該從 brokes 拉取消息還是 brokers 將消息推送到 consumer，也就是 pull 還 push。在這方面，Kafka 遵循了一種大部分消息系統(tǒng)共同的傳統(tǒng) 的設(shè)計(jì)：producer 將消息推送到 broker，consumer 從 broker 拉取消息 一些消息系統(tǒng)比如 Scribe 和 Apache Flume 采用了 push 模式，將消息推送到下游的 consumer。這樣做有好處也有壞處：由 broker 決定消息推送的速率，對(duì)于不同消費(fèi)速率的 consumer 就不太好處理了。消息系統(tǒng)都致力于讓 consumer 以最大的速率最快速的消費(fèi)消 息，但不幸的是，push 模式下，當(dāng) broker 推送的速率遠(yuǎn)大于 consumer 消費(fèi)的速率時(shí)， consumer 恐怕就要崩潰了。最終 Kafka 還是選取了傳統(tǒng)的 pull 模式 Pull 模式的另外一個(gè)好處是 consumer 可以自主決定是否批量的從 broker 拉取數(shù)據(jù)。Push 模式必須在不知道下游 consumer 消費(fèi)能力和消費(fèi)策略的情況下決定是立即推送每條消息還 是緩存之后批量推送。如果為了避免 consumer 崩潰而采用較低的推送速率，將可能導(dǎo)致一 次只推送較少的消息而造成浪費(fèi)。Pull 模式下，consumer 就可以根據(jù)自己的消費(fèi)能力去決 定這些策略 Pull 有個(gè)缺點(diǎn)是，如果 broker 沒有可供消費(fèi)的消息，將導(dǎo)致 consumer 不斷在循環(huán)中輪詢， 直到新消息到 t 達(dá)。為了避免這點(diǎn)，Kafka 有個(gè)參數(shù)可以讓 consumer 阻塞知道新消息到達(dá) (當(dāng)然也可以阻塞知道消息的數(shù)量達(dá)到某個(gè)特定的量這樣就可以批量發(fā)）我們知道ZooKeeper集群中也有選舉機(jī)制，是通過Paxos算法，通過不同節(jié)點(diǎn)向其他節(jié)點(diǎn)發(fā)送信息來投票選舉出leader，但是Kafka的leader的選舉就沒有這么復(fù)雜了。問題7：kafka什么情況下會(huì)rebalance
rebalance 的觸發(fā)條件有五個(gè)。- 條件3：coordinator掛了，集群選舉出新的coordinator
- 條件5：consumer調(diào)用unsubscrible()，取消topic的訂閱
rebalance 發(fā)生時(shí)，Group 下所有 consumer 實(shí)例都會(huì)協(xié)調(diào)在一起共同參與，kafka 能夠保證盡量達(dá)到最公平的分配。但是 Rebalance 過程對(duì) consumer group 會(huì)造成比較嚴(yán)重的影響。在 Rebalance 的過程中 consumer group 下的所有消費(fèi)者實(shí)例都會(huì)停止工作，等待 Rebalance 過程完成。問題7.1：能簡(jiǎn)單說一下rebalance過程嗎？
- 發(fā)送GCR請(qǐng)求尋找Coordinator：這個(gè)過程主要會(huì)向集群中負(fù)載最小的broker發(fā)起請(qǐng)求，等待成功返回后，那么該Broker將作為Coordinator，嘗試連接該Coordinator
- 發(fā)送JGR請(qǐng)求加入該組：當(dāng)成功找到Coordinator后，那么就要發(fā)起加入group的請(qǐng)求，表示該consumer是該組的成員，Coordinator會(huì)接收到該請(qǐng)求，會(huì)給集群分配一個(gè)Leader（通常是第一個(gè)），讓其負(fù)責(zé)partition的分配
- 發(fā)送SGR請(qǐng)求：JGR請(qǐng)求成功后，如果發(fā)現(xiàn)當(dāng)前Consumer是leader，那么會(huì)進(jìn)行partition的分配，并發(fā)起SGR請(qǐng)求將分配結(jié)果發(fā)送給Coordinator;如果不是leader，那么也會(huì)發(fā)起SGR請(qǐng)求，不過分配結(jié)果為空
Rebalance本身是Kafka集群的一個(gè)保護(hù)設(shè)定，用于剔除掉無法消費(fèi)或者過慢的消費(fèi)者，然后由于我們的數(shù)據(jù)量較大，同時(shí)后續(xù)消費(fèi)后的數(shù)據(jù)寫入需要走網(wǎng)絡(luò)IO，很有可能存在依賴的第三方服務(wù)存在慢的情況而導(dǎo)致我們超時(shí)。Rebalance對(duì)我們數(shù)據(jù)的影響主要有以下幾點(diǎn)：- 數(shù)據(jù)重復(fù)消費(fèi): 消費(fèi)過的數(shù)據(jù)由于提交offset任務(wù)也會(huì)失敗，在partition被分配給其他消費(fèi)者的時(shí)候，會(huì)造成重復(fù)消費(fèi)，數(shù)據(jù)重復(fù)且增加集群壓力
- Rebalance擴(kuò)散到整個(gè)ConsumerGroup的所有消費(fèi)者，因?yàn)橐粋€(gè)消費(fèi)者的退出，導(dǎo)致整個(gè)Group進(jìn)行了Rebalance，并在一個(gè)比較慢的時(shí)間內(nèi)達(dá)到穩(wěn)定狀態(tài)，影響面較大
- 頻繁的Rebalance反而降低了消息的消費(fèi)速度，大部分時(shí)間都在重復(fù)消費(fèi)和Rebalance
- 數(shù)據(jù)不能及時(shí)消費(fèi)，會(huì)累積lag，在Kafka的TTL之后會(huì)丟棄數(shù)據(jù) 上面的影響對(duì)于我們系統(tǒng)來說，都是致命的。
問題7.3：怎么解決rebalance中遇到的問題呢？
要避免 Rebalance，還是要從 Rebalance 發(fā)生的時(shí)機(jī)入手。我們?cè)谇懊嬲f過，Rebalance 主要發(fā)生的時(shí)機(jī)有三個(gè)：- 訂閱主題的分區(qū)數(shù)發(fā)生變化
后兩個(gè)我們大可以人為的避免，發(fā)生rebalance最常見的原因是消費(fèi)組成員的變化。消費(fèi)者成員正常的添加和停掉導(dǎo)致rebalance，這種情況無法避免，但是時(shí)在某些情況下，Consumer 實(shí)例會(huì)被 Coordinator 錯(cuò)誤地認(rèn)為 “已停止” 從而被“踢出”Group。從而導(dǎo)致rebalance。當(dāng) Consumer Group 完成 Rebalance 之后，每個(gè) Consumer 實(shí)例都會(huì)定期地向 Coordinator 發(fā)送心跳請(qǐng)求，表明它還存活著。如果某個(gè) Consumer 實(shí)例不能及時(shí)地發(fā)送這些心跳請(qǐng)求，Coordinator 就會(huì)認(rèn)為該 Consumer 已經(jīng) “死” 了，從而將其從 Group 中移除，然后開啟新一輪 Rebalance。這個(gè)時(shí)間可以通過Consumer 端的參數(shù) session.timeout.ms進(jìn)行配置。默認(rèn)值是 10 秒。除了這個(gè)參數(shù)，Consumer 還提供了一個(gè)控制發(fā)送心跳請(qǐng)求頻率的參數(shù)，就是 heartbeat.interval.ms。這個(gè)值設(shè)置得越小，Consumer 實(shí)例發(fā)送心跳請(qǐng)求的頻率就越高。頻繁地發(fā)送心跳請(qǐng)求會(huì)額外消耗帶寬資源，但好處是能夠更加快速地知曉當(dāng)前是否開啟 Rebalance，因?yàn)椋壳?Coordinator 通知各個(gè) Consumer 實(shí)例開啟 Rebalance 的方法，就是將 REBALANCE_NEEDED 標(biāo)志封裝進(jìn)心跳請(qǐng)求的響應(yīng)體中。除了以上兩個(gè)參數(shù)，Consumer 端還有一個(gè)參數(shù)，用于控制 Consumer 實(shí)際消費(fèi)能力對(duì) Rebalance 的影響，即 max.poll.interval.ms 參數(shù)。它限定了 Consumer 端應(yīng)用程序兩次調(diào)用 poll 方法的最大時(shí)間間隔。它的默認(rèn)值是 5 分鐘，表示你的 Consumer 程序如果在 5 分鐘之內(nèi)無法消費(fèi)完 poll 方法返回的消息，那么 Consumer 會(huì)主動(dòng)發(fā)起 “離開組” 的請(qǐng)求，Coordinator 也會(huì)開啟新一輪 Rebalance。通過上面的分析，我們可以看一下那些rebalance是可以避免的：第一類非必要 Rebalance 是因?yàn)槲茨芗皶r(shí)發(fā)送心跳，導(dǎo)致 Consumer 被 “踢出”Group 而引發(fā)的。這種情況下我們可以設(shè)置 session.timeout.ms 和 heartbeat.interval.ms 的值，來盡量避免rebalance的出現(xiàn)。（以下的配置是在網(wǎng)上找到的最佳實(shí)踐，暫時(shí)還沒測(cè)試過）設(shè)置 session.timeout.ms = 6s。設(shè)置 heartbeat.interval.ms = 2s。要保證 Consumer 實(shí)例在被判定為 “dead” 之前，能夠發(fā)送至少 3 輪的心跳請(qǐng)求，即 session.timeout.ms >= 3 * heartbeat.interval.ms。將 session.timeout.ms 設(shè)置成 6s 主要是為了讓 Coordinator 能夠更快地定位已經(jīng)掛掉的 Consumer，早日把它們踢出 Group。第二類非必要 Rebalance 是 Consumer 消費(fèi)時(shí)間過長導(dǎo)致的。此時(shí)，max.poll.interval.ms 參數(shù)值的設(shè)置顯得尤為關(guān)鍵。如果要避免非預(yù)期的 Rebalance，你最好將該參數(shù)值設(shè)置得大一點(diǎn)，比你的下游最大處理時(shí)間稍長一點(diǎn)。總之，要為業(yè)務(wù)處理邏輯留下充足的時(shí)間。這樣，Consumer 就不會(huì)因?yàn)樘幚磉@些消息的時(shí)間太長而引發(fā) Rebalance 。問題7.4：kafka一次reblance大概要多久
1個(gè)Topic，10個(gè)partition，3個(gè)consumer 測(cè)試結(jié)果 經(jīng)過幾輪測(cè)試發(fā)現(xiàn)每次rebalance所消耗的時(shí)間大概在 80ms~100ms平均耗時(shí)在87ms左右。這個(gè)在我看來是一個(gè)偽命題，如果要保證順序消費(fèi)為啥要用kafka呢，只是需要做到異步或者解耦？如果一定要做到順序消費(fèi)，肯定是可以的，但是這個(gè)浪費(fèi)資源，因?yàn)閗afka就是針對(duì)高并發(fā)大吞吐量而生，下面說一下順序消費(fèi)方案：1、一個(gè)topic、一個(gè)partition、一個(gè)線程 2、一個(gè)topic、n個(gè)partition、n個(gè)線程，這里生產(chǎn)時(shí)需要根據(jù)需求將需要排序的數(shù)據(jù)發(fā)送到指定的message key批處理能夠進(jìn)行更有效的數(shù)據(jù)壓縮并減少 I/O 延遲，Kafka 采取順序?qū)懭氪疟P的方式，避免了隨機(jī)磁盤尋址的浪費(fèi)，更多關(guān)于磁盤尋址的了解，請(qǐng)參閱 程序員需要了解的硬核知識(shí)之磁盤 。總結(jié)一下其實(shí)就是四個(gè)要點(diǎn)
作者：lipengxs
地址：my.oschina.net/lipengxs/blog/4312
