Kafka居然不支持讀寫分離！今天才知道！

Kafka居然不支持讀寫分離！今天才知道！ 在 Kafka 中，生產者寫入消息、消費者讀取消息的操做都是與 leader 副本進行交互的，從 而實現的是一種主寫主讀的生產消費模型。數據庫、Redis 等都具有主寫主讀的功能，與此同時還支持主寫從讀的功能，主寫從讀也就是讀寫分離，爲了與主寫主讀對應，這裏就以主寫從讀來稱呼!

在 Kafka 中，生產者寫入消息、消費者讀取消息的操做都是與 leader 副本進行交互的，從 而實現的是一種主寫主讀的生產消費模型。數據庫、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 副本，對於上圖中的情形，每一個 broker 都有消息從生產者流入;當消費者讀取消息的時候也是從 leader 副本中讀取 的，對於圖 8-23 中的情形，每一個 broker 都有消息流出到消費者。

咱們很明顯地能夠看出，每一個 broker上的讀寫負載都是同樣的，這就說明 Kafka 能夠經過 主寫主讀實現主寫從讀實現不了的負載均衡。上圖展現是一種理想的部署狀況，有如下幾種 狀況(包含但不只限於)會形成必定程度上的負載不均衡：

(1)broker 端的分區分配不均。當建立主題的時候可能會出現某些 broker 分配到的分區數 多而其餘 broker 分配到的分區數少，那麼天然而然地分配到的 leader 副本也就不均。

(2)生產者寫入消息不均。生產者可能只對某些 broker 中的 leader 副本進行大量的寫入操 做，而對其餘 broker 中的 leader 副本漠不關心。

(3)消費者消費消息不均。消費者可能只對某些 broker 中的 leader 副本進行大量的拉取操 做，而對其餘 broker 中的 leader 副本漠不關心。

(4)leader 副本的切換不均。在實際應用中可能會因爲 broker 宕機而形成主從副本的切換， 或者分區副本的重分配等，這些動做都有可能形成各個 broker 中 leader 副本的分配不均。

對此，咱們能夠作一些防範措施。

針對第一種狀況，在主題建立的時候儘量使分區分配 得均衡，好在 Kafka 中相應的分配算法也是在極力地追求這一目標，若是是開發人員自定義的 分配，則須要注意這方面的內容。對於第二和第三種狀況，主寫從讀也沒法解決。對於第四種 狀況，Kafka 提供了優先副本的選舉來達到 leader 副本的均衡，與此同時，也能夠配合相應的 監控、告警和運維平臺來實現均衡的優化。

在實際應用中，配合監控、告警、運維相結合的生態平臺，在絕大多數狀況下 Kafka 都能 作到很大程度上的負載均衡。

總的來講，Kafka 只支持主寫主讀有幾個優勢：

能夠簡化代碼的實現邏輯，減小出錯的可能;將負載粒度細化均攤，與主寫從讀相比，不只負載效能更好，並且對用戶可控;沒有延時的影響;

在副本穩定的狀況下，不會出現數據不一致的狀況。爲此，Kafka 又何須再去實現對它而言毫無收益的主寫從讀的功能呢?這一切都得益於 Kafka 優秀的架構設計，從某種意義上來講，主寫從讀是因爲設計上的缺陷而造成的權宜之計。

以爲不錯請點贊支持，歡迎留言或進個人我的羣855801563領取【架構資料專題目合集90期】、【BATJTMD大廠JAVA面試真題1000+】，本羣專用於學習交流技術、分享面試機會，拒絕廣告，我也會在羣內不按期答題、探討。