轉載自??阿里面試，為什么Kafka不支持讀寫分離

為什么數據庫、redis都支持了讀寫分離功能，而kafka卻沒有？

廝大也是狠人，直接打開源碼從頭開始講，我一看這情況不對，按照這進度得講到天黑了，蹭著廝大上廁所的空隙，我呲溜跑了~~~

廝大估計見我已經呲溜了，第二天就甩我一篇文章，還是熱乎的，文末還有精華

從代碼層面上來說，在 Kafka 中完全可以支持這種功能，但是會大大增加代碼的復雜度，所以我們要從“收益點”這個角度來做具體分析。主寫從讀可以讓從節點去分擔主節 點的負載壓力，預防主節點負載過重而從節點卻空閑的情況發生。但是主寫從讀也有 2 個很明 顯的缺點:

• 數據一致性問題。數據從主節點轉到從節點必然會有一個延時的時間窗口，這個時間 窗口會導致主從節點之間的數據不一致。某一時刻，在主節點和從節點中 A 數據的值都為 X， 之后將主節點中 A 的值修改為 Y，那么在這個變更通知到從節點之前，應用讀取從節點中的 A 數據的值并不為最新的 Y，由此便產生了數據不一致的問題。

• 延時問題。類似 Redis 這種組件，數據從寫入主節點到同步至從節點中的過程需要經 歷網絡→主節點內存→網絡→從節點內存這幾個階段，整個過程會耗費一定的時間。而在 Kafka 中，主從同步會比 Redis 更加耗時，它需要經歷網絡→主節點內存→主節點磁盤→網絡→從節 點內存→從節點磁盤這幾個階段。對延時敏感的應用而言，主寫從讀的功能并不太適用。

現實情況下，很多應用既可以忍受一定程度上的延時，也可以忍受一段時間內的數據不一 致的情況，那么對于這種情況，Kafka 是否有必要支持主寫從讀的功能呢?

主寫從讀可以均攤一定的負載卻不能做到完全的負載均衡，比如對于數據寫壓力很大而讀 壓力很小的情況，從節點只能分攤很少的負載壓力，而絕大多數壓力還是在主節點上。而在 Kafka 中卻可以達到很大程度上的負載均衡，而且這種均衡是在主寫主讀的架構上實現的。我們來看 一下 Kafka 的生產消費模型，如下圖所示。

在 Kafka 集群中有 3 個分區，每個分區有 3 個副本，正好均勻地分布在 3個 broker 上，灰色陰影的代表 leader 副本，非灰色陰影的代表 follower 副本，虛線表示 follower 副本從 leader 副本上拉取消息。當生產者寫入消息的時候都寫入 leader 副本，對于圖 8-23 中的 情形，每個 broker 都有消息從生產者流入;當消費者讀取消息的時候也是從 leader 副本中讀取 的，對于圖 8-23 中的情形，每個 broker 都有消息流出到消費者。

我們很明顯地可以看出，每個 broker 上的讀寫負載都是一樣的，這就說明 Kafka 可以通過 主寫主讀實現主寫從讀實現不了的負載均衡。上圖展示是一種理想的部署情況，有以下幾種 情況(包含但不僅限于)會造成一定程度上的負載不均衡:

• broker 端的分區分配不均。當創建主題的時候可能會出現某些 broker 分配到的分區數 多而其他 broker 分配到的分區數少，那么自然而然地分配到的 leader 副本也就不均。

• 生產者寫入消息不均。生產者可能只對某些 broker 中的 leader 副本進行大量的寫入操 作，而對其他 broker 中的 leader 副本不聞不問。

• 消費者消費消息不均。消費者可能只對某些 broker 中的 leader 副本進行大量的拉取操 作，而對其他 broker 中的 leader 副本不聞不問。

• leader 副本的切換不均。在實際應用中可能會由于 broker 宕機而造成主從副本的切換， 或者分區副本的重分配等，這些動作都有可能造成各個 broker 中 leader 副本的分配不均。

對此，我們可以做一些防范措施。針對第一種情況，在主題創建的時候盡可能使分區分配 得均衡，好在 Kafka 中相應的分配算法也是在極力地追求這一目標，如果是開發人員自定義的 分配，則需要注意這方面的內容。對于第二和第三種情況，主寫從讀也無法解決。對于第四種 情況，Kafka 提供了優先副本的選舉來達到 leader 副本的均衡，與此同時，也可以配合相應的 監控、告警和運維平臺來實現均衡的優化。

所以，從某種意義上來說，主寫從讀是由于設計上的缺陷而形成的權宜之計。

總結

以上是生活随笔為你收集整理的阿里面试，为什么Kafka不支持读写分离的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。