Kafka在美团数据平台的现状及原理分析(图)

原文链接：

美团数据平台Kafka的现状

Kafka 出色的 I/O 优化和多重异步设计，相比其他消息队列系统具有更高的吞吐量，同时可以保证良好的延迟，非常适合在整个大数据生态系统中应用。

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

美团在线Kafka目前的规模：

Kafka 痛点分析&核心目标

目前，Kafka 支持大量的实时作业，以及单机承载的大量主题和主题。这种场景下容易出现的问题是同一台机器上的不同资源相互竞争、相互影响，导致整体处理延迟增加，吞吐量下降。

接下来，我们将根据Kafka读写请求的处理流程和在线统计数据来分析Kafka在线的痛点。

原理分析

Kafka处理读写过程示意图

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

对于请求：主要使用操作系统的机制。当Kafka收到数据读取请求时，会向操作系统发送系统调用。操作系统收到后，首先尝试从中获取数据（如中间流程图所示）；如果数据不存在，则会触发缺页异常，将数据从磁盘读入临时缓冲区（如右侧流程图所示），然后直接将数据复制到网卡缓冲区通过 DMA 操作进行后续 TCP 传输。

综上所述，Kafka对于单个读写请求具有良好的吞吐量和延迟。处理写入请求时，数据写入后立即返回，并以异步方式将数据批量刷新到磁盘，这样既保证了大部分写入请求可以有更低的延迟，也更加磁盘-友好的批量顺序冲洗。在处理读请求时，实时消费作业可以直接从数据读取到数据，请求延迟小。同时该机制可以减少数据传输过程中用户态和内核态的切换，大大提高了数据传输的效率。

但是当同一时间有多个时，它们可能会由于多个竞争资源而延迟。下面我们举两个例子来详细说明：

如上图所示，发送数据到会缓存这部分数据。当所有消耗功率足够时，将读取所有数据，并且所有实例都具有低延迟。这时候如果其中一个有消费延迟（图中），根据读请求处理流程，此时会触发磁盘读取，在从磁盘读取数据的同时会提前读取一些数据. 当空间不足时，会根据 LRU 策略淘汰数据。此时，延迟消费的读取数据将取代实时缓存的数据。当后续的实时消费请求到来时，由于其中的数据已经被替换，会发生意外的磁盘读取。这会导致两个后果：

以足够的消费能力消费时将失去的绩效奖金。多次交互、磁盘读取意外增加和 HDD 负载增加。

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

可以看出，随着读并发的增加，HDD的IOPS和带宽会明显下降，进而影响整体的吞吐量和处理延迟。

在线统计

目前Kafka集群中TP99的流量为170MB/s，TP95的流量为100MB/s，TP50的流量为50-60MB/s；单机平均分配80GB，以TP99的流量为参考。缓存数据的时间跨度为 80*1024/170/60 = 8min。可以看出，目前的Kafka服务整体对于延迟消费作业的容忍度非常低。这种情况下，一旦部分作业的消费延迟，可能会影响实时消费作业。

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

痛点分析总结

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

实时消耗和延迟消耗的作业在级别上竞争，导致实时消耗的意外磁盘读取。随着读取并发的增加，传统 HDD 性能急剧下降。线上有20%的延迟消费工作。

根据目前的空间分配和线上集群流量分析，Kafka无法为实时消费作业提供稳定的服务质量保障配置高速缓存是为了解决，这个痛点亟待解决。

预期目标

根据以上痛点分析，我们预期的目标是保证实时消费作业不会因为竞争而受到延迟消费作业的影响，同时保证Kafka为实时消费作业提供稳定的服务质量保证。

解决方案为什么选择 SSD

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

消除实时消耗和延迟消耗之间的竞争，例如：防止延迟消耗作业读取的数据被写回，或者增加分配量等。在HDD和内存之间增加一个新设备，具有更好的读写性能带宽和 IOPS 高于 HDD。

对于第一个方向，由于是由操作系统管理的，如果修改淘汰策略，实现起来会比较困难，同时也会破坏内核本身的外部语义。另外，内存资源成本高，不可能无限扩展，所以需要考虑第二个方向。

SSD的发展越来越成熟。与HDD相比，SSD的IOPS和带宽都有一个数量级的提升，非常适合在上述场景发生竞争后承担部分读取流量。我们还测试了SSD的性能，结果如下图所示：

从图中可以看出，随着读并发的增加，SSD的IOPS和带宽不会有明显下降。从这个结论来看，我们可以使用 SSD 作为 HDD 的缓存层。

架构决策

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

Kafka引擎在读写行为方面具有以下特点：

下面给出了两个备选方案，下面给出了我们的选择基础和架构决策。

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

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

如下图所示，并且两者的核心设计思想是相似的，两种架构的核心理论基础是“数据局部性”原则。SSD 和 HDD 按照相同的粒度划分为固定的管理单元，然后将 SSD 上的空间映射到多个 HDD 层（逻辑或物理）的设备上。在访问过程中，和CPU访问cache和主存的过程类似，首先尝试访问Cache层，如果出现则访问HDD层，根据数据局部性原则，这部分数据将被写回缓存层。如果缓存空间满了，一些数据会被LRU策略替换掉。

/ 提供四种缓存策略： , , . 由于第四种不做读缓存，这里只看前三种。

写：

读：

更详细的实现细节请参考两者的官方文档：

选项 2：Kafka 应用程序的内部实现

在上面提到的第一类替代方案中，“数据局部性”原理的核心理论基础并不完全符合Kafka的读写特性，“数据刷新”特性仍然会引入缓存空间污染的问题。同时，上述架构基于LRU的淘汰策略也与Kafka的读写特性相矛盾。在多个并发消费的情况下，LRU淘汰策略可能会误淘汰一些近实时的数据，导致实时消费作业的性能抖动。

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

当消费请求到达 Kafka 时，Kafka 直接根据消息 () 与其维护的设备的关系从对应的设备获取数据并返回，并不将从 HDD 读取的数据刷回读取请求。SSD 防止缓存污染。同时访问路径清晰，不会因为Cache Miss而产生额外的访问开销。

下表更详细地比较了不同的候选人：

最后，考虑到对Kafka读写特性的兼容性，整体工作量等因素，我们使用Kafka应用层来实现这个方案，因为这个方案更接近Kafka自身的读写特性，可以更彻底的解决Kafka的痛点。

新架构设计概述

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

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

Kafka中的一个由几个组成，每个包含两个索引文件和日志消息文件。有几个是按（相对时间）维度排序的。

根据上一节的设计思路，我们首先将不同的状态标记为不同的状态，如图（上图）按照时间维度，分为三个永久状态。三种状态的转换以及新架构对读写操作的处理如图下半部分所示。标记为状态的状态只存储在SSD上，后台线程会定期同步（无写入流量）到SSD。，完成同步被标记为状态。

最后，后台线程会定期检测 SSD 上的已用空间。当空间达到阈值时，后台线程会根据时间维度移除与SSD的最长距离，并将这部分标记为状态。

对于写请求，写请求还是先将数据写入SSD，在达到阈值条件后会flush到SSD。对于一个读请求（没有获取到数据时），如果读的对应状态为OR，则从SSD返回数据（图中LC2-LC1和RC1），如果状态为） ，它将从硬盘返回（图中的LC1）。

对于副本数据同步，您可以根据Topic的延迟和稳定性要求配置高速缓存是为了解决，通过配置来决定是写入SSD还是HDD。

关键优化点

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

同步

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

同步方式：同步方式决定了SSD数据在HDD上可见的及时性，影响故障恢复和清理的及时性。同步限速：在同步过程中采用限速机制，防止在同步过程中影响正常的读写请求。

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

最后综合考虑一致性维护成本和实现复杂度等因素，选择了后台同步的方式。

同步限速

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

基于以上两点，我们需要在同步过程中加入限速机制。整体限速原则是在不影响正常读写请求延迟的情况下，尽可能快地同步。由于同步速度太慢，SSD数据无法及时清理，最终变满。同时，为了灵活调整，配置也设置为单粒度配置参数。

日志追加刷新策略优化

除了同步问题，数据写入过程中的flush机制也会影响服务的读写延迟。这种机制的设计不仅影响新架构的性能，还会影响原生的Kafka。

下图为单个写请求的处理流程：

在请求处理流程中，首先根据当前位置和请求中的数据信息判断是否需要滚动日志段，然后将请求中的数据写入，更新LEO和统计信息，最后判断是否滚动根据统计信息触发flush。磁盘操作，必要时使用.force强制磁盘，否则请求会直接返回。

整个过程中，除了日志滚动和磁盘刷新外，其他操作都是内存操作，不会造成性能问题。日志滚动涉及文件系统操作。目前，Kafka 提供了日志滚动干扰参数，以防止多个同时滚动操作对文件系统造成压力。对于日志刷新操作，目前Kafka提供的机制是触发强制刷新，固定数量的消息（目前在线50000），这个机制只能保证在传入流量不变的情况下，消息会以相同的值发送）频繁刷新磁盘，但无法限制每次刷新到磁盘的数据量，无法对磁盘的负载提供有效的限制。

如下图所示，是某个盘在正午高峰时段的瞬时值。中午高峰期，由于写入流量增加，刷盘过程中会产生大量毛刺，毛刺值几乎接近磁盘最大值。写入带宽，会抖动读写请求延迟。

针对这个问题，我们修改了刷机机制，将原来的记录数限制改为实际刷机速率限制。对于单个，闪烁速率限制为 2MB/s。该值考虑了在线的实际平均消息大小。设置过小，单条消息较大的Topic会刷新过于频繁，流量大时平均延迟会增加。目前，该机制已在小范围灰度上线。右图为灰度后对应同一时间段的指标。可以看出，与左图相比，数据刷新速率明显比灰度前平滑，最高速率仅为40MB/s左右。

对于新的SSD缓存架构，同样存在上述问题。因此，在新架构中，刷新率在刷新操作中也是受限的。

方案测试 测试目标 测试场景描述 测试内容和重点指标 测试结果

从单个请求延迟的角度来看：

在磁盘刷新机制优化之前，全新的SSD缓存架构在所有场景下都比其他方案优势明显。

优化刷新机制后，其他方案的服务质量在延迟方面有所提升。由于小流量下Flush机制的优化，新架构等方案的优势变小了。当单节点写入流量较大（大于170MB）时，优势明显。

从延迟作业对实时作业的影响来看：

新的缓存架构在所有测试的场景中，延迟作业对实时作业没有影响，正如预期的那样。

总结和未来展望

Kafka承担了美团数据平台统一数据缓存和分发的角色。针对当前实时作业因相互污染和竞争而受到延迟作业影响的痛点，我们开发了基于SSD的Kafka应用层缓存架构。

本文主要介绍Kafka新架构的设计思路以及与其他开源方案的对比。与普通集群相比，新的缓存架构具有非常明显的优势：

减少读写时间：与普通集群相比，新架构集群的读写时间减少了80%。实时消费不受延迟消费影响：与普通集群相比，新架构集群实时读写性能稳定，不受延迟消费影响。目前，该缓存架构的优化已经得到验证，处于灰度阶段。未来还将部署到高质量的集群上。涉及的代码也将提交给 Kafka 社区。作为对社区的反馈，也欢迎您与我们交流。

文章来源:http://www.toutiao.com/a7029180801946239526/

------本页内容已结束，喜欢请分享------

感谢您的来访，获取更多精彩文章请收藏本站。