Kafka水位(high watermark)與leader epoch的討論
~~~這是一篇有點長的文章，希望不會令你昏昏欲睡~~~ 本文主要討論0.11版本之前Kafka的副本備份機制的設計問題以及0.11是如何解決的。簡單來說，0.11之前副本備份機制主要依賴水位(或水印)的概念，而0.11采用了leader epoch來標識備份進度。后面我們會詳細討論兩種機制的差異 ...
原文：關於Kafka high watermark的討論2
之前寫過一篇關於Kafka High watermark的文章，引起的討論不少：有贊揚之聲，但更多的是針對文中的內容被challenge，於是下定決心找個晚上熬夜再看了一遍，昨晚挑燈通讀了一遍確實發現不少錯誤。鑒於此我決定再寫一篇博客重新梳理一下最新版本中High watermark 下稱HW 的工作原理，也算是糾正之前文章中的錯誤。這次我不打算說leader epoch，而只是專門討論HW l ...
2018-09-04 14:47 9 1767 推薦指數：
相關推薦
Kafka設計解析（二十一）Kafka水位(high watermark)與leader epoch的討論
轉載自 huxihx，原文鏈接 Kafka水位(high watermark)與leader epoch的討論 本文主要討論0.11版本之前Kafka的副本備份機制的設計問題以及0.11是如何解決的。簡單來說，0.11之前副本備份機制主要依賴水位(或水印)的概念，而0.11采用 ...
關於Kafka配額的討論(1)
Kafka自0.9.0.0版本引入了配額管理(quota management)，旨在broker端對clients發送請求進行限流(throttling)。目前Kafka支持兩大類配額管理： 網絡帶寬（network bandwidth）配額管理：定義帶寬閾值來限制請求發送速率，閾值單位 ...
關於Kafka broker IO的討論
Apache Kafka是大量使用磁盤和頁緩存(page cache)的，特別是對page cache的應用被視為是Kafka實現高吞吐量的重要因素之一。實際場景中用戶調整page cache的手段並不太多，更多的還是通過管理好broker端的IO來間接影響page cache從而實現高吞吐量 ...
關於Kafka監控方案的討論
之前在知乎上嘗試過回答這個問題，后來問的人挺多，干脆在博客里面保存一下。 目前Kafka監控方案看似很多，然而並沒有一個“大而全”的通用解決方案。各家框架也是各有千秋，以下是我了解到的一些內容： Kafka manager Github地址： https://github.com ...
關於Kafka冪等producer的討論
眾所周知，Kafka 0.11.0.0版本正式支持精確一次處理語義(exactly once semantics，下稱EOS)。Kafka的EOS主要體現在3個方面： 冪等producer：保證發送單個分區的消息只會發送一次，不會出現重復消息 事務(transaction)：保證 ...
關於Kafka Fetch Session的討論
Kafka在1.1.0版本引入了fetch session的概念，旨在降低“無效”FETCH請求對集群帶寬資源的占用。故事的背景是這樣的： 眾所周知，Kafka的broker和consumer都會定期地向leader broker發送FETCH請求去獲取數據。對於分區數很多的topic ...
關於Kafka __consumer_offests的討論
眾所周知，__consumer__offsets是一個內部topic，對用戶而言是透明的，除了它的數據文件以及偶爾在日志中出現這兩點之外，用戶一般是感覺不到這個topic的。不過我們的確知道它保存的是Kafka新版本consumer的位移信息。本文我們簡單梳理一下這個內部topic(以1.0.0 ...