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 ...