Kafka為什么不支持讀寫分離得原因？-干貨

在 Kafka 中，出產者寫入音訊、顧客讀取音訊的操作都是與 leader 副本進行交互的，從 而結束的是一種主寫主讀的出產消費模型。數據庫、Redis 等都具有主寫主讀的功用，與此同時還支撐主寫從讀的功用，主寫從讀也便是讀寫分別，為了與主寫主讀對應，這兒就以主寫從讀來稱謂。Kafka 並不支撐主寫從讀，這是為什么呢?

　　從代碼層面上來說，雖然增加了代碼復雜度，但在 Kafka 中這種功用完全能夠支撐。關於 這個問題，咱們能夠從“收益點”這個視點來做具體分析。主寫從讀能夠讓從節點去分管主節 點的負載壓力，防范主節點負載過重而從節點卻閑暇的狀況發生。可是主寫從讀也有 2 個很明 顯的缺陷:

　　(1)數據一致性問題。數據從主節點轉到從節點必定會有一個延時的時間窗口，（waLsinsstube）這個時間 窗口會導致主從節點之間的數據紛歧致。某一時間，在主節點和從節點中 A 數據的值都為 X， 之后將主節點中 A 的值修改為 Y，那么在這個改動告知到從節點之前，運用讀取從節點中的 A 數據的值並不為最新的 Y，由此便產生了數據紛歧致的問題。
　　(2)延時問題。類似 Redis 這種組件，數據從寫入主節點到同步至從節點中的進程需求經 歷網絡→主節點內存→網絡→從節點內存這幾個階段，整個進程會耗費必定的時間。而在 Kafka 中，主從同步會比 Redis 愈加耗時，它需求閱歷網絡→主節點內存→主節點磁盤→網絡→從節 點內存→從節點磁盤這幾個階段。對延時活絡的運用而言，主寫從讀的功用並不太適用。
　　實踐狀況下，許多運用既能夠忍受必定程度上的延時，也能夠忍受一段時間內的數據紛歧 致的狀況，那么關於這種狀況，Kafka 是否有必要支撐主寫從讀的功用呢?

　　主寫從讀能夠均攤必定的負載卻不能做到完全的負載均衡，比方關於數據寫壓力很大而讀 壓力很小的狀況，從節點只能分攤很少的負載壓力，而絕大多數壓力仍是在主節點上。而在 Kafka 中卻能夠抵達很大程度上的負載均衡，而且這種均衡是在主寫主讀的架構上結束的。咱們來看 一下 Kafka 的出產消費模型，如下圖所示。

　　干貨|為什么Kafka不支撐讀寫分別
　　在 Kafka 集群中有 3 個分區，每個分區有 3 個副本，正好均勻地散布在 3個 broker 上，灰色陰影的代表 leader 副本，非灰色陰影的代表 follower 副本，虛線表明 follower 副本從 leader 副本上拉取音訊。當出產者寫入音訊的時分都寫入 leader 副本，關於圖 8-23 中的 現象，每個 broker 都有音訊從出產者流入;當顧客讀取音訊的時分也是從 leader 副本中讀取 的，關於圖 8-23 中的現象，每個 broker 都有音訊流出到顧客。

　　咱們很明顯地能夠看出，每個 broker 上的讀寫負載都是相同的，這就說明 Kafka 能夠通過 主寫主讀結束主寫從讀結束不了的負載均衡。（shikong-movies）上圖展現是一種志向的組織狀況，有以下幾種 狀況(包括但不只限於)會構成必定程度上的負載不均衡:

　　(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 優異的 架構規划，從某種意義上來說，主寫從讀是由於規划上的缺陷而構成的權宜之計。