大数据

Kafka高可靠场景下的性能表现

大多数业务场景需要使用可靠性消息，Kafka在高可靠场景下的性能表现到底如何呢？
本文的压测结果是消息大小100字节、开启和不开启batch，producer的QPS分别可以达到3.6W和24.8W。

在高可靠场景下，微信开源PhxQueue vs Kafka的性能：消息大小为10字节、开启和不开启batch，Kafka的producer的QPS分别可以达到180W/S和9W/S
压测结果用于评估是否可以用于实际的业务场景，所以压测场景并未穷举多种message.size、batch.size以及partitions.size

受压测环境限制（虚拟机CPU100%；在线压测占用网络带宽，影响线上应用）还未压测到broker的I/O极限。

本文描述的高可靠场景是指无数据丢失的场景、消息100%可靠
在线压测时，需要OPS同时在线，共同关注虚拟机带宽资源、线上网络带宽资源的占用情况，避免对同一宿主机上的其他应用产生影响

相关配置

Kafka提供了高可用、高可靠、高吞吐量和低延时的特征，这些特征取决于client和broker端如何配置对应的属性。
本文压测所使用的高可靠配置属性是直接参考之前的一篇文章，这篇文章中的优化durability都涵盖了具体的属性，不再作具体说明。

Kafka官网推荐使用默认的异步刷盘（OS 30秒刷盘一次）来平衡高可靠和高性能
默认的异步刷盘只能保证在broker不发生宕机的情况下，保证消息100%高可靠，基于此，而追求性能的最大化
但是本文采同步刷盘，牺牲一定的性能，满足在任何情况下确保消息100%可靠

性能测试

  • 服务器
    压测所使用的服务器均是日常使用的服务器。虚拟机部署应用(Kafka的producer)，实体机部署存储系统(Kafka的broker)。

    • 6台虚拟机，其中5台部署producer，1台部署zookeeper
    1
    2
    3
    4
    CPU: x86_64 Intel Xeon E312xx (Sandy Bridge) @ 2.10GHz 4CPU
    Memory: 5GB
    Network: 1GB Ethernet
    Disk: 60GB
    • 3台实体机，部署broker集群
    1
    2
    3
    4
    CPU: x86_64 Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz  6核 开启超程
    Memory: 30GB
    Network: 10GB Ethernet
    Disk: 1T PERC H710P

为什么没有压测consumer？
因为业务场景中，consumer的处理逻辑会相对较重，通常是consumer的消息处理速度会比较慢。

  • 压测脚本
    直接使用kafka_2.11-0.11.0.0的压测脚本kafka-producer-perf-test.sh进行压测
    压测脚本：perf-test-producer. sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#!/bin/bash
export KAFKA_HEAP_OPTS="-Xmx512M"
topic="topic-r3-p30"
numRecords="1000000000"
echo "Running producer perf testing"
/home/q/kafka/kafka_2.11-0.11.0.0/bin/kafka-producer-perf-test.sh \
--topic ${topic} \
--num-records ${numRecords} \
--record-size 100 \
--throughput 1000000000 \
--producer-props \
acks=-1 \
bootstrap.servers=192.168.121.46:9092,192.168.121.48:9092,192.168.121.50:9092 \
compression.type=none \
batch.size=1 \
linger.ms=0 \
request.timeout.ms=3000000

注意：不同版本的kafka自带的压测脚本参数有可能不一样

  • 压测场景
    消息大小=100字节，topic的分区个数=16

partitions为什么是16？
因为压测过partitions=3、6的场景（不开启batch），broker的IO使用率分别是40%、60%，producer的QPS只能到1.6W
每台虚拟机上启动16个producer进程（nohup ./perf-test-producer.sh &）

  • 不开启batch，producer的QPS可以达到3.6W/S
    实际的业务场景不存在需要将消息积压到一定量之后再批量发送给broker，而更多的是一旦消息产生就及时发到broker
    压测时间：11:02–11:16

    • I/O

      不增加partition，IO使用率一直压不上去。
      当partition从6增加到16后，IO使用率从40%增大到80%
    • NetWork

      不增加partitions，网络流量保持在20Mbit/S（partitions=6），网络流量压不上去。
      当增大partitions到16后，网络流量增大到50Mbit/S
    • Memory

      cached增长缓慢
    • CPU

      CPU在35%左右，CPU并不高
    • Load

      load在8左右，也不高，服务器上是12核，开启超程
    • GC

  • 开启batch，producer的QPS可以达到24.8W/S
    batch.size=1000
    压测时间：11:52–11:55

    • I/O

      一直保持在80%
    • NetWork

      开启batch后，网络流量从50Mbit/S迅速飙到240Mbit/S
    • Memory

      开启batch后，短短3分钟内cached从10G涨到20G
    • CPU

      保持在40%，变化不大
    • Load

      保持在9左右，变化不大
    • GC

  • QPS数据
    在压测的过程中，所有producer进程的QPS信息会记录到nohup.out，记录的是单个producer的QPS
    5台虚拟机部署producer，每台虚拟机上开启16个producer进程

    • 不开启batch
    1
    2
    3
    4
    5
    6
    7
    2308 records sent, 459.9 records/sec (0.04 MB/sec), 398272.1 ms avg latency, 420320.0 max latency.
    2303 records sent, 460.0 records/sec (0.04 MB/sec), 398268.9 ms avg latency, 420102.0 max latency.
    2314 records sent, 462.3 records/sec (0.04 MB/sec), 398757.2 ms avg latency, 418233.0 max latency.
    2323 records sent, 464.0 records/sec (0.04 MB/sec), 396975.2 ms avg latency, 415960.0 max latency.
    2309 records sent, 461.2 records/sec (0.04 MB/sec), 399178.9 ms avg latency, 419073.0 max latency.
    2298 records sent, 457.5 records/sec (0.04 MB/sec), 399280.0 ms avg latency, 426313.0 max latency.
    2303 records sent, 460.0 records/sec (0.04 MB/sec), 398136.1 ms avg latency, 416454.0 max latency.

    总的QPS=450516=3.6W/S

    • 开启batch
    1
    2
    3
    4
    5
    6
    7
    15904 records sent, 3170.0 records/sec (0.30 MB/sec), 85798.8 ms avg latency, 90976.0 max latency.
    15776 records sent, 3153.9 records/sec (0.30 MB/sec), 85600.0 ms avg latency, 91577.0 max latency.
    15936 records sent, 3187.2 records/sec (0.30 MB/sec), 85383.0 ms avg latency, 91503.0 max latency.
    15904 records sent, 3178.3 records/sec (0.30 MB/sec), 85640.2 ms avg latency, 91587.0 max latency.
    15776 records sent, 3149.5 records/sec (0.30 MB/sec), 85972.8 ms avg latency, 92308.0 max latency.
    16024 records sent, 3189.5 records/sec (0.30 MB/sec), 85473.7 ms avg latency, 91592.0 max latency.
    15896 records sent, 3174.8 records/sec (0.30 MB/sec), 85727.8 ms avg latency, 91356.0 max latency.

    总的QPS=3100516=24.8W/S

结论

  • partition是最小的并发单元
    增加partition，可以明显提升IO使用率
  • batch直接影响吞吐量
    开启batch，可以显著提升网络流量
  • 100% no data lose,close batch
    message.size=100byte，producer的QPS高达3.6W，IO使用率在80%左右，满足业务场景