Pafka 0.3.0 发布：低成本解决 Kafka 高峰流量场景

来源：原创
如需转载，请注明来自 MemArk 技术社区 (https://memark.io/)

1. Pafka 0.3.0 简介

Pafka GitHub: https://github.com/4paradigm/pafka

Pafka 基于分级存储的方法论，对流行开源消息队列系统 Apache Kafka 基于现代存储架构进行了优化。其使用第一级的高速存储设备（比如持久内存，SSD 等）来存放热数据，配合存储层级之间的自动迁移策略，使得 Kafka 的读写都尽量保持在第一级高速存储设备中，来提升整体的吞吐性能。在最新发布的 0.3.0 版本中，Pafka 引入了存储层级的可适配性，对于第一层的高速存储介质，既可以使用高持久化性能的持久内存（PMem）来追求极致性能，也可以使用更大容量的 SSD，在性能和容量之间取得平衡。相比较于 PMem，基于更大容量和更低成本的 SSD 作为第一级存储介质，虽然在单节点能达到的最大吞吐上有所减弱，但是由于其容量和价格优势，因此可以低成本的支撑更长的流量高峰期时间。

关于 Pafka 所使用的的分级存储和自动迁移的技术原理，以及 0.2.0 版本如何使用 PMem 来追求极致性能，请参照此篇 blog。本文将会着重介绍 Pafka 0.3.0 引入的基于 SSD 的优势场景。

2. 低成本支撑高峰流量

Pafka 支撑突发高峰流量是其一个典型使用优势场景。其解决问题的基本思想为：在非高峰期，Pafka 会将存放于第一级快速设备上的数据在后台自动迁移到第二级的慢速设备上，以空出第一级设备的可用存储空间；当高峰来临时，尽量使用第一级快速存储设备来服务消息队列的读写，提高节点的整体吞吐。因此，其能支撑的高峰流量时间大约为把第一级高速存储设备写满的时间；同时需要一定的非高峰期来完成数据迁移工作，该时间大概是把第一级存储设备上的数据搬移到第二级存储设备所需要的时间。关于高峰期和非高峰期所需时间的具体计算逻辑可以参考 下载我们准备的计算器。

Pafka 0.2.0 版本仅支持使用 PMem 作为第一级存储，虽然 PMem 拥有优秀的性能，但是其容量（典型配置 1.5 TB 或者 3 TB）相比较于传统硬盘存在明显弱势。在某些 Kafka 需要存储较大数据量的场景下，单节点 PMem 很容易被快速写满，仅仅能支持几分钟的高峰吞吐。相反，SSD 可以支持相对较大容量，虽然降低了单节点的最大吞吐，却可以较好的满足某些场景下性能、容量、成本的平衡。

我们使用外卖平台来作为一个典型场景。基于实际的生活经验，外卖平台一般会存在两个高峰，分别是中午和傍晚，每一个高峰持续周期一般会在两个小时左右。在这两个高峰时间段，其外卖平台的流量将会远远显著高于非高峰期。我们假设系统需要存储较多的数据，因此 Kafka 基于容量较大的 HDD 搭建（如果需要存储数据不多可以参照 Pafka 0.2.0 基于 PMem 的改进方案）。假设某外卖平台一天两个高峰期分别为中午 12-2 PM，以及傍晚 6-8 PM。假如其高峰期需要满足整体 12.5 GB/Sec 的同时读和写的吞吐能力，非高峰期的吞吐需求总量为 1 GB/sec，我们有两种技术方案：

• 方案一，基于普通 Kafka 方案：如果每一台服务器使用 HDD 组成 RAID，提供大约 500 MB/sec 的吞吐。则为了满足高峰期总共 12.5 GB/sec 的性能需求，需要服务器 25 台，总成本大约为 25 万美元。并且大部分的机器资源在非高峰期实际处于空闲状态。
• 方案二：基于分级存储优化的 Pafka 方案：假设每台服务器配备 6 TB 容量的 SSD，每台机器承担的高峰期的吞吐规划为 1.25 GB/sec（注意该数值需要在 SSD 所能达到的性能范围之内）。则基于以上配置，我们可以预估每台机器可以支撑的高峰期为 2 小时，另外用于数据从第一级 SSD 往 HDD 迁移的所需要的时间为 4 小时（即需要大概 4 小时的非高峰期来完成迁移数据），以上高峰和非高峰期的持续时间可以满足该外卖平台的业务需求。从成本上计算，我们仅仅需要 10 台服务器，并且每台配备 6 TB SSD，10 台服务器（包含 SSD）总成本大约为 11 万美元。关于此方案的具体计算逻辑，请参照此计算器。

通过以上比较可以看到，对于具有明显高峰期的场景来说，Pafka 提供了一种基于 SSD 的低成本方案，使用 SSD 来满足高峰期的高吞吐需求。基于以上的例子计算，Pafka 方案可以节省硬件成本多达一倍以上。当然，在实际情况中，对于不同高峰期的性能要求、高峰期长短预期等因素，都会影响到实际的硬件配置的选择。

3. 快速上手

想要快速体验Pafka，直接使用我们提供的docker image (https://hub.docker.com/r/4pdopensource/pafka-dev)，docker image里面提供了运行Pafka所依赖的环境和配置。

可以根据以下步骤，来启动Pafka的服务端，以及通过自带的测试脚本进行基本的测试验证。

# 下载并启动docker
docker run -it 4pdopensource/pafka-dev bash

# 启动zookeeper
bin/zookeeper-server-start.sh config/zookeeper.properties > zk.log 2>&1 &

# 启动pafka server
bin/kafka-server-start.sh config/server.properties > pafka.log 2>&1 &

# 测试Producer性能
bin/kafka-producer-perf-test.sh --topic test --throughput 1000000 --num-records 1000000 --record-size 1024 --producer.config config/producer.properties --producer-props bootstrap.servers=localhost:9092

# 测试Consumer性能
bin/kafka-consumer-perf-test.sh --topic test --consumer.config config/consumer.properties --bootstrap-server localhost:9092 --messages 1000000 --show-detailed-stats --reporting-interval 1000 --timeout 100000

4. 性能实测

4.1 实验环境

硬件配置

Broker机器配置：

Client机器配置（1台）

Pafka配置

下面列出一些和标准kafka配置（config/server.properties）有区别的配置:

# 100 Gbps网络配置
listeners=PLAINTEXT://172.29.100.24:9092

# 线程相关
num.network.threads=32
num.io.threads=16

# 分级存储相关配置
# log file channel type; Options: "file", "pmem", "tiered".
# if "file": use normal file as vanilla Kafka does. Following configs are not applicable.
log.channel.type=tiered
# the storage types for each layers (separated by ,)
storage.tiers.types=NVME,HDD
# first-layer storage paths (separated by ,)
storage.tiers.first.paths=/nvme
# first-layer storage capacities in bytes (separated by ,); -1 means use all the space
storage.tiers.first.sizes=700000000000
# second-layer storage paths (separated by ,)
storage.tiers.second.paths=/hdd
# threshold to control when to start the migration; -1 means no migration.
storage.migrate.threshold=0.1
# migration threads
storage.migrate.threads=8

配置中需要注意：

• 基于我们的NVMe SSD的容量，storage.tiers.first.sizes配置为700, 000, 000, 000 Bytes
• 为了快速把一级存储迁移到二级存储上面，storage.migrate.threads可以配置为较大数值，比如8，加快迁移速度
• 为了能够支持更长时间的高峰流量，storage.migrate.threshold可以配置的较小些，这里配置为0.1，即当一级存储的使用量达到10%时，就开始进行后台迁移

Producer配置

batch.size=163840 

4.2 测试脚本

可以直接使用我们提供的测试脚本来进行测试

# 启动Producer测试进程，并把log写入到producer.log
python3 bin/bench.py --brokers 172.29.100.24:9092 --threads 16 --hosts "$TEST_NODE" --num_records 2000000000 --record_size 1024 --type producer --use_dynamic --dynamic 100000:500000:2000000 --sleept 360 --only_min_max --wait_for_all > producer.log 2>&1 &

# 启动consumer测试进程，并把log写入到consumer.log
python3 bin/bench.py --brokers 172.29.100.24:9092 --threads 16 --hosts "$TEST_NODE" --num_records 2000000000 --type consumer --wait_for_all > consumer.log 2>&1 &

以上脚本会在$TEST_NODE上面启动16个Producer和16个Consumer进程，同时对broker进行压测。总共会插入大概2 TB的数据（$num_records * $record_size）。压测总流量为100, 000 records/s – 2, 000, 000 records/s之间变化，平均值为500, 000 records/s（–dynamic 100000:500000:2000000）。通过–only_min_max选项，流量只会是100, 000或者2, 000, 000，高流量持续时间设为360s，对应的低流量持续时间，会根据设定的平均值来自动计算。

4.3 测试结果

如上图显示了 Pafka 的实测结果。可以看到，基于我们的实验配置，Pafka 可以非常好的支撑 2 GB/sec 的读写高峰期，持续时间大约 6 分钟，然后需要非高峰时间大约半小时进行数据迁移。该实测结果也基本符合我们所提供的计算器的预估结果，表明该计算模型的准确性符合预期。对于实际的不同性能要求的场景，我们可以通过配置不同容量的 SSD，以及每节点上的吞吐支撑规划，来达到预期的支撑高峰期所需要的时间长度。针对实际场景的相关估算，也可以参考借助我们提供的计算器来进行计算。

5. 了解更多

• Pafka GitHub: https://github.com/4paradigm/pafka
• Pafka 关于高峰期持续时间的预估计算器
• 了解关于 Pafka 的分级存储技术原理以及基于持久内存的高性能方案
• MemArk 分级存储技术专栏
• Slack Workspace
• 扫码加入微信分级存储讨论群