基于SSD的Kafka应用层缓存架构设计与实现-InfoQ

QCon全球软件开发大会8折优惠倒计时，购票立减¥1760！了解详情 >>> 了解详情 



 写点什么

Kafka 在美团数据平台的现状

Kafka 出色的 I/O 优化以及多处异步化设计，相比其他消息队列系统具有更高的吞吐，同时能够保证不错的延迟，十分适合应用在整个大数据生态中。

目前在美团数据平台中，Kafka 承担着数据缓冲和分发的角色。如下图所示，业务日志、接入层 Nginx 日志或线上 DB 数据通过数据采集层发送到 Kafka，后续数据被用户的实时作业消费、计算，或经过数仓的 ODS 层用作数仓生产，还有一部分则会进入公司统一日志中心，帮助工程师排查线上问题。

image

目前美团线上 Kafka 规模：

集群规模：节点数达 6000+，集群数 100+。
集群承载：Topic 数 6 万+，Partition 数 41 万+。
处理的消息规模：目前每天处理消息总量达 8 万亿，峰值流量为 1.8 亿条/秒
提供的服务规模：目前下游实时计算平台运行了 3 万+作业，而这其中绝大多数的数据源均来自 Kafka。

Kafka 线上痛点分析 &核心目标

当前 Kafka 支撑的实时作业数量众多，单机承载的 Topic 和 Partition 数量很大。这种场景下很容易出现的问题是：同一台机器上不同 Partition 间竞争 PageCache 资源，相互影响，导致整个 Broker 的处理延迟上升、吞吐下降。

接下来，我们将结合 Kafka 读写请求的处理流程以及线上统计的数据来分析一下 Kafka 在线上的痛点。

原理分析

Kafka处理读写流程的示意图

对于 Produce 请求：Server 端的 I/O 线程统一将请求中的数据写入到操作系统的 PageCache 后立即返回，当消息条数到达一定阈值后，Kafka 应用本身或操作系统内核会触发强制刷盘操作（如左侧流程图所示）。

对于 Consume 请求：主要利用了操作系统的 ZeroCopy 机制，当 Kafka Broker 接收到读数据请求时，会向操作系统发送 sendfile 系统调用，操作系统接收后，首先试图从 PageCache 中获取数据（如中间流程图所示）；如果数据不存在，会触发缺页异常中断将数据从磁盘读入到临时缓冲区中（如右侧流程图所示），随后通过 DMA 操作直接将数据拷贝到网卡缓冲区中等待后续的 TCP 传输。

综上所述，Kafka 对于单一读写请求均拥有很好的吞吐和延迟。处理写请求时，数据写入 PageCache 后立即返回，数据通过异步方式批量刷入磁盘，既保证了多数写请求都能有较低的延迟，同时批量顺序刷盘对磁盘更加友好。处理读请求时，实时消费的作业可以直接从 PageCache 读取到数据，请求延迟较小，同时 ZeroCopy 机制能够减少数据传输过程中用户态与内核态的切换，大幅提升了数据传输的效率。

但当同一个 Broker 上同时存在多个 Consumer 时，就可能会由于多个 Consumer 竞争 PageCache 资源导致它们同时产生延迟。下面我们以两个 Consumer 为例详细说明：

image

如上图所示，Producer 将数据发送到 Broker，PageCache 会缓存这部分数据。当所有 Consumer 的消费能力充足时，所有的数据都会从 PageCache 读取，全部 Consumer 实例的延迟都较低。此时如果其中一个 Consumer 出现消费延迟（图中的 Consumer Process2），根据读请求处理流程可知，此时会触发磁盘读取，在从磁盘读取数据的同时会预读部分数据到 PageCache 中。当 PageCache 空间不足时，会按照 LRU 策略开始淘汰数据，此时延迟消费的 Consumer 读取到的数据会替换 PageCache 中实时的缓存数据。后续当实时消费请求到达时，由于 PageCache 中的数据已被替换掉，会产生预期外的磁盘读取。这样会导致两个后果：

消费能力充足的 Consumer 消费时会失去 PageCache 的性能红利。
多个 Consumer 相互影响，预期外的磁盘读增多，HDD 负载升高。

我们针对 HDD 的性能和读写并发的影响做了梯度测试，如下图所示：

image

可以看到，随着读并发的增加，HDD 的 IOPS 和带宽均会明显下降，这会进一步影响整个 Broker 的吞吐以及处理延迟。

线上数据统计

目前 Kafka 集群 TP99 流量在 170MB/s，TP95 流量在 100MB/s，TP50 流量为 50-60MB/s；单机的 PageCache 平均分配为 80GB，取 TP99 的流量作为参考，在此流量以及 PageCache 分配情况下，PageCache 最大可缓存数据时间跨度为 80*1024/170/60 = 8min，可见当前 Kafka 服务整体对延迟消费作业的容忍性极低。该情况下，一旦部分作业消费延迟，实时消费作业就可能会受到影响。

同时，我们统计了线上实时作业的消费延迟分布情况，延迟范围在 0-8min（实时消费）的作业只占 80%，说明目前存在线上存在 20%的作业处于延迟消费的状态。

痛点分析总结

总结上述的原理分析以及线上数据统计，目前线上 Kafka 存在如下问题：

实时消费与延迟消费的作业在 PageCache 层次产生竞争，导致实时消费产生非预期磁盘读。
传统 HDD 随着读并发升高性能急剧下降。
线上存在 20%的延迟消费作业。

按目前的 PageCache 空间分配以及线上集群流量分析，Kafka 无法对实时消费作业提供稳定的服务质量保障，该痛点亟待解决。

预期目标

根据上述痛点分析，我们的预期目标为保证实时消费作业不会由于 PageCache 竞争而被延迟消费作业影响，保证 Kafka 对实时消费作业提供稳定的服务质量保障。

解决方案

为什么选择 SSD

根据上述原因分析可知，解决目前痛点可从以下两个方向来考虑：

消除实时消费与延迟消费间的 PageCache 竞争，如：让延迟消费作业读取的数据不回写 PageCache，或增大 PageCache 的分配量等。
在 HDD 与内存之间加入新的设备，该设备拥有比 HDD 更好的读写带宽与 IOPS。

对于第一个方向，由于 PageCache 由操作系统管理，若修改其淘汰策略，那么实现难度较为复杂，同时会破坏内核本身对外的语义。另外，内存资源成本较高，无法进行无限制的扩展，因此需要考虑第二个方向。

SSD 目前发展日益成熟，相较于 HDD，SSD 的 IOPS 与带宽拥有数量级级别的提升，很适合在上述场景中当 PageCache 出现竞争后承接部分读流量。我们对 SSD 的性能也进行了测试，结果如下图所示：

image

从图中可以发现，随着读取并发的增加，SSD 的 IOPS 与带宽并不会显著降低。通过该结论可知，我们可以使用 SSD 作为 PageCache 与 HDD 间的缓存层。

架构决策

在引入 SSD 作为缓存层后，下一步要解决的关键问题包括 PageCache、SSD、HDD 三者间的数据同步以及读写请求的数据路由等问题，同时我们的新缓存架构需要充分匹配 Kafka 引擎读写请求的特征。本小节将介绍新架构如何在选型与设计上解决上述提到的问题。

Kafka 引擎在读写行为上具有如下特性：

数据的消费频率随时间变化，越久远的数据消费频率越低。
每个分区（Partition）只有 Leader 提供读写服务。
对于一个客户端而言，消费行为是线性的，数据并不会重复消费。

下文给出了两种备选方案，下面将对两种方案给出我们的选取依据与架构决策。

备选方案一：基于操作系统内核层实现

目前开源的缓存技术有 FlashCache、BCache、DM-Cache、OpenCAS 等，其中 BCache 和 DM-Cache 已经集成到 Linux 中，但对内核版本有要求，受限于内核版本，我们仅能选用 FlashCache/OpenCAS。

如下图所示，FlashCache 以及 OpenCAS 二者的核心设计思路类似，两种架构的核心理论依据为“数据局部性”原理，将 SSD 与 HDD 按照相同的粒度拆成固定的管理单元，之后将 SSD 上的空间映射到多块 HDD 层的设备上（逻辑映射 or 物理映射）。在访问流程上，与 CPU 访问高速缓存和主存的流程类似，首先尝试访问 Cache 层，如果出现 CacheMiss，则会访问 HDD 层，同时根据数据局部性原理，这部分数据将回写到 Cache 层。如果 Cache 空间已满，会通过 LRU 策略替换部分数据。

image

FlashCache/OpenCAS 提供了四种缓存策略：WriteThrough、WriteBack、WriteAround、WriteOnly。由于第四种不做读缓存，这里我们只看前三种。

写入：

WriteThrough：数据写操作在写入 SSD 的同时会写入到后端存储。
WriteBack：数据写操作仅写入 SSD 即返回，由缓存策略 flush 到后台存储。
WriteAround：数据写入操作直接写入后端存储，同时 SSD 对应的缓存会失效。

读取：

WriteThrough/WriteBack/WriteAround：首先读取 SSD，命中不了的将再次读取后端存储，并数据会被刷入到 SSD 缓存中。

image

更多详细实现细节，极大可参见这二者的官方文档：

备选方案二：Kafka 应用内部实现

上文提到的第一类备选方案中，核心的理论依据“数据局部性”原理与 Kafka 的读写特性并不能完全吻合，“数据回刷”这一特性依然会引入缓存空间污染问题。同时，上述架构基于 LRU 的淘汰策略也与 Kafka 读写特性存在矛盾，在多 Consumer 并发消费时，LRU 淘汰策略可能会误淘汰掉一些近实时数据，导致实时消费作业出现性能抖动。

可见，备选方案一并不能完全解决当前 Kafka 的痛点，需要从应用内部进行改造。整体设计思路如下，将数据按照时间维度分布在不同的设备中，近实时部分的数据缓存在 SSD 中，这样当出现 PageCache 竞争时，实时消费作业从 SSD 中读取数据，保证实时作业不会受到延迟消费作业影响。下图展示了基于应用层实现的架构处理读请求的流程：

image

当消费请求到达 Kafka Broker 时，Kafka Broker 直接根据其维护的消息偏移量（Offset）和设备的关系从对应的设备中获取数据并返回，并且在读请求中并不会将 HDD 中读取的数据回刷到 SSD，防止出现缓存污染。同时访问路径明确，不会由于 Cache Miss 而产生的额外访问开销。

下表对不同候选方案进行了更加详细的对比：

最终，结合与 Kafka 读写特性的匹配度，整体工作量等因素综合考虑，我们采用 Kafka 应用层实现这一方案，因为该方案更贴近 Kafka 本身读写特性，能更加彻底地解决 Kafka 的痛点。

新架构设计

概述

根据上文对 Kafka 读写特性的分析，我们给出应用层基于 SSD 的缓存架构的设计目标：

数据按时间维度分布在不同的设备上，近实时数据分布在 SSD 上，随时间的推移淘汰到 HDD 上。
Leader 分区中所有数据均写入 SSD 中。
从 HDD 中读取的数据不回刷到 SSD 中。

依据上述目标，我们给出应用层基于 SSD 的 Kafka 缓存架构实现：

Kafka 中一个 Partition 由若干 LogSegment 构成，每个 LogSegment 包含两个索引文件以及日志消息文件。一个 Partition 的若干 LogSegment 按 Offset（相对时间）维度有序排列。

image

根据上一小节的设计思路，我们首先将不同的 LogSegment 标记为不同的状态，如图所示（图中上半部分）按照时间维度分为 OnlyCache、Cached 以及 WithoutCache 三种常驻状态。而三种状态的转换以及新架构对读写操作的处理如图中下半部分所示，其中标记为 OnlyCached 状态的 LogSegment 只存储在 SSD 上，后台线程会定期将 Inactive（没有写流量）的 LogSegment 同步到 SSD 上，完成同步的 LogSegment 被标记为 Cached 状态。

最后，后台线程将会定期检测 SSD 上的使用空间，当空间达到阈值时，后台线程将会按照时间维度将距离现在最久的 LogSegment 从 SSD 中移除，这部分 LogSegment 会被标记为 WithoutCache 状态。

对于写请求而言，写入请求依然首先将数据写入到 PageCache 中，满足阈值条件后将会刷入 SSD。对于读请求（当 PageCache 未获取到数据时），如果读取的 offset 对应的 LogSegment 的状态为 Cached 或 OnlyCache，则数据从 SSD 返回（图中 LC2-LC1 以及 RC1），如果状态为 WithoutCache，则从 HDD 返回（图中 LC1）。

对于 Follower 副本的数据同步，可根据 Topic 对延迟以及稳定性的要求，通过配置决定写入到 SSD 还是 HDD。

关键优化点

上文介绍了基于 SSD 的 Kafka 应用层缓存架构的设计概要以及核心设计思路，包括读写流程、内部状态管理以及新增后台线程功能等。本小节将介绍该方案的关键优化点，这些优化点均与服务的性能息息相关。主要包括 LogSegment 同步以及 Append 刷盘策略优化，下面将分别进行介绍。

LogSegment 同步

LogSegment 同步是指将 SSD 上的数据同步到 HDD 上的过程，该机制在设计时主要有以下两个关键点：

同步的方式：同步方式决定了 HDD 上对 SSD 数据的可见时效性，从而会影响故障恢复以及 LogSegment 清理的及时性。
同步限速：LogSegment 同步过程中通过限速机制来防止同步过程中对正常读写请求造成影响

同步方式

关于 LogSegment 的同步方式，我们给出了三种备选方案，下表列举了三种方案的介绍以及各自的优缺点：

最终，我们对一致性维护代价、实现复杂度等因素综合考虑，选择了后台同步 Inactive 的 LogSegment 的方式。

同步限速

LogSegment 同步行为本质上是设备间的数据传输，会同时在两个设备上产生额外的读写流量，占用对应设备的读写带宽。同时，由于我们选择了同步 Inactive 部分的数据，需要进行整段的同步。如果在同步过程中不加以限制会对服务整体延迟造成较大的影响，主要表现在下面两个方面：

从单盘性能角度，由于 SSD 的性能远高于 HDD，因此在数据传输时，HDD 写入带宽会被写满，此时其他的读写请求会出现毛刺，如果此时有延迟消费从 HDD 上读取数据或者 Follower 正在同步数据到 HDD 上，会造成服务抖动。
从单机部署的角度，单机会部署 2 块 SSD 与 10 块 HDD，因此在同步过程中，1 块 SSD 需要承受 5 块 HDD 的写入量，因此 SSD 同样会在同步过程中出现性能毛刺，影响正常的请求响应延迟。

基于上述两点，我们需要在 LogSegment 同步过程中增加限速机制，总体的限速原则为在不影响正常读写请求延迟的情况下尽可能快速地进行同步。因为同步速度过慢会导致 SSD 数据无法被及时清理而最终被写满。同时为了可以灵活调整，该配置也被设置为单 Broker 粒度的配置参数。

日志追加刷盘策略优化

除了同步问题，数据写入过程中的刷盘机制同样影响服务的读写延迟。该机制的设计不仅会影响新架构的性能，对原生 Kafka 同样会产生影响。

下图展示了单次写入请求的处理流程：

image

在 Produce 请求处理流程中，首先根据当前 LogSegment 的位置与请求中的数据信息确定是否需要滚动日志段，随后将请求中的数据写入到 PageCache 中，更新 LEO 以及统计信息，最后根据统计信息确定是否需要触发刷盘操作，如果需要则通过fileChannel.force强制刷盘，否则请求直接返回。

在整个流程中，除日志滚动与刷盘操作外，其他操作均为内存操作，不会带来性能问题。日志滚动涉及文件系统的操作，目前，Kafka 中提供了日志滚动的扰动参数，防止多个 Segment 同时触发滚动操作给文件系统带来压力。针对日志刷盘操作，目前 Kafka 给出的机制是以固定消息条数触发强制刷盘（目前线上为 50000），该机制只能保证在入流量一定时，消息会以相同的频率刷盘，但无法限制每次刷入磁盘的数据量，对磁盘的负载无法提供有效的限制。

如下图所示，为某磁盘在午高峰时间段 write_bytes 的瞬时值，在午高峰时间段，由于写入流量的上升，在刷盘过程中会产生大量的毛刺，而毛刺的值几乎接近磁盘最大的写入带宽，这会使读写请求延迟发生抖动。

image

针对该问题，我们修改了刷盘的机制，将原本的按条数限制修改为按实际刷盘的速率限制，对于单个 Segment，刷盘速率限制为 2MB/s。该值考虑了线上实际的平均消息大小，如果设置过小，对于单条消息较大的 Topic 会过于频繁的进行刷新，在流量较高时反而会加重平均延迟。目前该机制已在线上小范围灰度，右图展示了灰度后同时间段对应的 write_bytes 指标，可以看到相比左图，数据刷盘速率较灰度前明显平滑，最高速率仅为 40MB/s 左右。

对于 SSD 新缓存架构，同样存在上述问题，因此在新架构中，在刷盘操作中同样对刷盘速率进行了限制。