還在加班，收到一個小伙伴的吐槽：狼哥宪赶，阿里的面試太變態(tài)了宗弯，我只是在工作中用過kafka，然后簡歷上提了下搂妻，就被抓著一個勁的問蒙保，一些基礎(chǔ)的問題，我還可以勉強答出來欲主，但是問到“為什么Kafka不支持讀寫分離”邓厕，我就懵逼了。
說實話扁瓢，這個狼哥也不知道详恼，對于kafka，我也只會生產(chǎn)引几、消費单雾。
一直沒有接觸過kafka相關(guān)的知識，為了拓展一下技術(shù)廣度，找到了我廝大
為什么數(shù)據(jù)庫硅堆、redis都支持了讀寫分離功能屿储，而kafka卻沒有？
廝大也是狠人渐逃，直接打開源碼從頭開始講够掠，我一看這情況不對，按照這進度得講到天黑了茄菊，蹭著廝大上廁所的空隙疯潭，我呲溜跑了~~~
廝大估計見我已經(jīng)呲溜了，第二天就甩我一篇文章面殖，還是熱乎的竖哩，文末還有精華
從代碼層面上來說，在 Kafka 中完全可以支持這種功能脊僚，但是會大大增加代碼的復(fù)雜度相叁，所以我們要從“收益點”這個角度來做具體分析。主寫從讀可以讓從節(jié)點去分擔(dān)主節(jié) 點的負載壓力辽幌，預(yù)防主節(jié)點負載過重而從節(jié)點卻空閑的情況發(fā)生增淹。但是主寫從讀也有 2 個很明 顯的缺點:
數(shù)據(jù)一致性問題。數(shù)據(jù)從主節(jié)點轉(zhuǎn)到從節(jié)點必然會有一個延時的時間窗口乌企，這個時間 窗口會導(dǎo)致主從節(jié)點之間的數(shù)據(jù)不一致虑润。某一時刻，在主節(jié)點和從節(jié)點中 A 數(shù)據(jù)的值都為 X加酵， 之后將主節(jié)點中 A 的值修改為 Y拳喻，那么在這個變更通知到從節(jié)點之前，應(yīng)用讀取從節(jié)點中的 A 數(shù)據(jù)的值并不為最新的 Y猪腕，由此便產(chǎn)生了數(shù)據(jù)不一致的問題舞蔽。
延時問題。類似 Redis 這種組件码撰，數(shù)據(jù)從寫入主節(jié)點到同步至從節(jié)點中的過程需要經(jīng) 歷網(wǎng)絡(luò)→主節(jié)點內(nèi)存→網(wǎng)絡(luò)→從節(jié)點內(nèi)存這幾個階段，整個過程會耗費一定的時間个盆。而在 Kafka 中脖岛，主從同步會比 Redis 更加耗時，它需要經(jīng)歷網(wǎng)絡(luò)→主節(jié)點內(nèi)存→主節(jié)點磁盤→網(wǎng)絡(luò)→從節(jié) 點內(nèi)存→從節(jié)點磁盤這幾個階段颊亮。對延時敏感的應(yīng)用而言柴梆，主寫從讀的功能并不太適用。
現(xiàn)實情況下终惑，很多應(yīng)用既可以忍受一定程度上的延時绍在，也可以忍受一段時間內(nèi)的數(shù)據(jù)不一 致的情況，那么對于這種情況，Kafka 是否有必要支持主寫從讀的功能呢?
主寫從讀可以均攤一定的負載卻不能做到完全的負載均衡偿渡，比如對于數(shù)據(jù)寫壓力很大而讀 壓力很小的情況臼寄，從節(jié)點只能分攤很少的負載壓力，而絕大多數(shù)壓力還是在主節(jié)點上溜宽。而在 Kafka 中卻可以達到很大程度上的負載均衡吉拳，而且這種均衡是在主寫主讀的架構(gòu)上實現(xiàn)的。我們來看 一下 Kafka 的生產(chǎn)消費模型适揉，如下圖所示留攒。
在 Kafka 集群中有 3 個分區(qū)，每個分區(qū)有 3 個副本嫉嘀，正好均勻地分布在 3個 broker 上炼邀，灰色陰影的代表 leader 副本，非灰色陰影的代表 follower 副本剪侮，虛線表示 follower 副本從 leader 副本上拉取消息拭宁。當生產(chǎn)者寫入消息的時候都寫入 leader 副本，對于圖 8-23 中的 情形票彪，每個 broker 都有消息從生產(chǎn)者流入;當消費者讀取消息的時候也是從 leader 副本中讀取 的红淡，對于圖 8-23 中的情形，每個 broker 都有消息流出到消費者降铸。
我們很明顯地可以看出在旱，每個 broker 上的讀寫負載都是一樣的，這就說明 Kafka 可以通過 主寫主讀實現(xiàn)主寫從讀實現(xiàn)不了的負載均衡推掸。上圖展示是一種理想的部署情況桶蝎，有以下幾種 情況(包含但不僅限于)會造成一定程度上的負載不均衡:
broker 端的分區(qū)分配不均。當創(chuàng)建主題的時候可能會出現(xiàn)某些 broker 分配到的分區(qū)數(shù) 多而其他 broker 分配到的分區(qū)數(shù)少谅畅，那么自然而然地分配到的 leader 副本也就不均登渣。
生產(chǎn)者寫入消息不均。生產(chǎn)者可能只對某些 broker 中的 leader 副本進行大量的寫入操 作毡泻，而對其他 broker 中的 leader 副本不聞不問胜茧。
消費者消費消息不均。消費者可能只對某些 broker 中的 leader 副本進行大量的拉取操 作仇味，而對其他 broker 中的 leader 副本不聞不問呻顽。
leader 副本的切換不均。在實際應(yīng)用中可能會由于 broker 宕機而造成主從副本的切換丹墨， 或者分區(qū)副本的重分配等廊遍，這些動作都有可能造成各個 broker 中 leader 副本的分配不均。
對此贩挣，我們可以做一些防范措施喉前。針對第一種情況没酣，在主題創(chuàng)建的時候盡可能使分區(qū)分配 得均衡，好在 Kafka 中相應(yīng)的分配算法也是在極力地追求這一目標卵迂，如果是開發(fā)人員自定義的 分配裕便，則需要注意這方面的內(nèi)容。對于第二和第三種情況狭握，主寫從讀也無法解決闪金。對于第四種 情況，Kafka 提供了優(yōu)先副本的選舉來達到 leader 副本的均衡论颅，與此同時哎垦，也可以配合相應(yīng)的 監(jiān)控、告警和運維平臺來實現(xiàn)均衡的優(yōu)化恃疯。
所以漏设，從某種意義上來說，主寫從讀是由于設(shè)計上的缺陷而形成的權(quán)宜之計今妄。
