这个⽅案存在的问题

1. 快⼿的这个patch是针对kafka 0.10.2.0版本，其他版本不⽀持，如果我们引⼊的话，需要针对⽣产环境上的版本进⾏代码修改

2. 设计的缺陷：

a)replica直接从最新的produce offset进⾏复制，⽆法保证kafka⼀致性语义（所有的副本数据完全⼀致），最新的replica缺失now - retention_ms这段时间的数据，如果consumer想要通过⾃定义offset来消费历史数据，可能会抛异常（当这个replica变成leader时）;

b)replica从最新的produce offset进⾏同步，加⼊ISR的时机为 所有consumer offset全部⼤于起始同步offset,如果某个consumer group在此期间停⽌了消费测试⽤的group id），则会导致这个replica⼀直⽆法加⼊ISR

3. 这个patch只能在jdk 7 & scala 2.10编译通过，测试通过，在jdk 8 & scala 2.11环境下，测试⽆法通过

4. 社区的意⻅

5. 快⼿针对这个改进提了⼀个KIP，但是这个KIP已经被删掉了，没有找到他们当时对这个improvement的讨论

6. 这个patch kafka社区没有approve

2. Kafka RPC 队列隔离

Motivation

 

第⼀个 case ： consumer 的 lag 读会对 page cache 产⽣污染。

第⼆个 case ： follower 也会造成 page cache 的污染。

 

在图中 broker1 机器内部，其中 page cache 中除了包括蓝⾊ producer 写⼊的数据之外，

还包括橙⾊ follower 写⼊的数据。但是橙⾊ follower 写⼊的数据，在正常的情况下，之后不

会再有访问，这相当于将不需要再被访问的数据放⼊了 cache ，这是对 cache 的浪费并造

成了污染。所以，很容易想到 Kafka 是否可以⾃⼰维护 cache 呢？⾸先，严格按照时间的

顺序进⾏ cache ，可以避免异常 consumer 的 lag 读造成的 cache 污染。其次，控制

follower 的数据不进⼊ cache ，这样阻⽌了 follower 对 cache 的污染，可以进⼀步提升

cache 的容量。

 

改进⽅案

我们在 broker 中引⼊了两个对象：⼀个是 block cache ；另⼀个是 flflush queue 。 Producer

的写⼊请求在 broker 端⾸先会被以原 message 的形式写⼊ flflush queue 中，之后再将数据

写⼊到 block cache 的⼀个 block 中，之后整个请求就结束了。在 flflush queue 中的数据会

由其他线程异步地写⼊到磁盘中（会经历 page cache 过程）。⽽ follower 的处理流程保持

和原来⼀致，从其他 broker 读到数据之后，直接把数据写到磁盘（也会经历 page

cache ）。这种模式保证了 block cache 中的数据全都是 producer 产⽣的，不会被 follower

污染。

对于 consumer ⽽⾔，在 broker 接到消费请求后，⾸先会从 block cache 中检索数据，如

果命中，则直接返回。否则，则从磁盘读取数据。这样的读取模式保障了 consumer 的

cache miss 读并不会填充 block cache ，从⽽避免了产⽣污染，即使有⼤ lag 的 consumer

读磁盘，也仍然保证 block cache 的稳定。

接下来，我们看下 block cache 的微观设计，整个 block cache 由 3 个部分组成：

第⼀部分： 2 类 block pool ，维护着空闲的 block 信息，之所以分成 2 类，主要是因

segment 数据以及 segment 的索引⼤⼩不同，统⼀划分会导致空间浪费；

第⼆部分：先进先出的 block 队列，⽤于维护 block ⽣产的时序关系，在触发淘汰时，会优

先淘汰时间上最早的 block ；

第三部分： TP+offffset 到有效 blocks 的索引，⽤于快速定位⼀个 block 。⼀个 block 可以看

做是 segment 的⼀部分。 segment 数据以及 segment 索引和 block 的对应关系如图所示。

最后，还有两个额外的线程：

eliminater 线程，⽤于异步进⾏ block cache 淘汰，当然，如果 produce 请求处理时，发现

block cache 满也会同步进⾏ cache 淘汰的；

异步写线程，⽤于将 flflush queue 中的 message 异步写⼊到磁盘中。

这个就是 Kafka cache 的整体设计，可以看出，已经很好地解决了上述的两个对 cache 污

染的问题了。

性能测试

我们搭建了 5 个 broker 的集群，其中⼀个换成了 Kafka cache 的版本。并创建了⼀个 150

个 partition 的 topic ， 3 副本。所以算上副本，⼀共有 450 个 partition ，每台机器上 90 台

TP 。之后我们 Mirror 了⼀个线上的流量数据，并启动 150 个 consumer ，以总体 lag 450w

条数据开始读。

从图中可以看出，原始版本在这种情况下会造成⼤量的磁盘读，⽽ Kafka cache 版本没有任

何磁盘读取操作，这说明 Kafka cache 版本可以 cache 更多的有效数据，这点是排除了

follower 造成的污染，经过精细化统计，发现 Kafka cache 有效空间刚好为原版本的 2 倍

（正好和同⼀台 broker 中 TP 为 leader 和 follower 的数量⽐⼀致）。从恢复的时间上看，

由于排除了读磁盘以及多个 consumer 之间读可能会 cache 产⽣的污染， Kafka cache 的版

本也⽐原有版本速度要快了 30% 。

除此之外，再看下改进后的 broker ，从这个图中可以看出， produce 整个写⼊过程，先是同

步写⼊内存，然后再被异步刷⼊磁盘。虽然 page cache 的模式也是类似这种，但是 page cache 会存在⼀定不稳定性（可能会触发同步写盘）。这个是我们上线 Kafka cache 版本前

后的 produce p999 的延迟对⽐。从图中可以看到： Kafka cache 版本⽐原来版本的延迟低

了很多，且稳定性有极⼤改进。

 

引⼊该⽅案存在的问题

1. ⽬前快⼿只提出了⼀个⾃⼰管理 Cache 的⽅案，没有公开源码，我们需要⾃⼰写代码实

现

2. 我们集群 Kafka 的版本⽬前不统⼀，在实现这个⽅案之前需要统⼀ Kafka 版本