大数据

解读Kafka基准测试报告

从LinkedIn发布的Kafka benchmark来看，Kafka（基准测试使用的版本是0.8.1)）的性能相当彪悍。
在3台普通的服务器上其消息写入的QPS可以高达200万/秒（消息大小100字节）。

硬件配置

  • 硬件配置
    • Intel Xeon 2.5 GHz processor with six cores
    • Six 7200 RPM SATA drives
    • 32GB of RAM
    • 1Gb Ethernet

磁盘采用的是JBOD方式，而不是RAID阵列，RAID具备更强的读写性能。二者的区别。

部署结构

一共6台机器，3台部署broker，另外3台部署zk和压测脚本

压测结果汇总

  • 压测脚本

    • 消息大小：100byte ，消息数量：50 million，分区数：6个
    • 相关脚本

    该脚本只适用于0.8.x；如果想自己压测最新版本，可以参考这个脚本

  • 压测结果

    • 常规场景
压测场景 部署 线程数 复制 QPS 吞吐量
Case1 Producer Single thread no replication 821,557 records/sec 78.3 MB/sec
Case2 Producer Single thread async 3x replication 786,980 records/sec 75.1 MB/sec
Case3 Producer Single thread sync 3x replication 421,823 records/sec 40.2 MB/sec
Case4 Producer Three producers async 3x replication 2,024,032 records/sec 193.0 MB/sec
Case5 Consumer Single Consumer 3x replication 940,521 records/sec 89.7 MB/sec
Case6 Consumer Three Consumers 3x replication 2,615,968 records/sec 249.5 MB/sec
Case7 Producer & Consumer Single Producer & Consumer async 3x replication 795,064 records/sec 75.8 MB/sec

  • 压测分析

    • 同步/异步和replication-factor对生产者QPS的影响

    消息的写入次数直接影响生产者的QPS。写入次数和消息复制方式（同步/异步）、replication-factor有关。
    同步（acks=-1）意味着消息在成功写入leader后，还需要成功写入ISR列表中剩下的follower，消息才算发送成功，因此同步意味着消息需要成功写入replication-factor=N次才算成功；
    异步（acks=1）意味着消息在成功写入leader后，消息就算发送成功，因此异步意味着消息只需成功写入1次就算成功，和replication-factor=N无关。

    replication-factor=1,同步和异步都意味着只要消息成功写入leader就算成功
    replication-factor>1,同步意味着要消息成功写入replication-factor次才算成功，异步意味着消息只用成功写入leader就算成功

    Case1和Case2都只需要消息成功写入1次后就算发送成功，所以Case1和Case2的QPS差别不大，而Case3需要消息成功写入3次才算成功，所以Case3和Case1，Case2的QPS相差较大。

    因此当replication-factor > 1时，同步（acks=-1）对生产者的QPS影响非常大；当replication-factor > 1时，同步和异步对生产者的QPS影响不大。

    • Consumer个数对吞吐量的影响
      Case5和Case6的数据说明了Consumer的吞吐量几乎是和Consumer的个数成线性增长的，完全符合预期。因为Kafka的Consumer Scale的设计思路是同一个group里面的Consumer只能消费一个partition（leader），所以增加Consumer的个数可以快速提升消息消费的吞吐量。但是如果Consumer超过partitions的个数时，多余的Consumer会一直收不到消息。

    建议：Consumer的个数>=partitions的个数

  • 其他压测场景

    • Case8 Broker消息积压对生产者QPS的影响
      很多消息中间件的Broker在出现消息积压时，客户端的QP会显著下降，尤其是在积压到GB级别的时候。
      然而，Kafka并不会受到影响，这个和Kafka的设计密切相关。
      下图展示了随着消息从1GB积压到1TB的过程中，生产者QPS的变化情况。从中可以看出生产者的QPS并未出现急剧下降，只是出现了毛刺，而这些毛刺是由于Linux的I/O周期性地批量地将数据刷到磁盘对生产者的QPS产生一定的影响导致的。

    • Case9 消息大小对生产者吞吐量的影响

      • 10字节时QPS最高，高达90+W/S
      • 消息大小在100字节以下时，生产者的QPS是最高的，可以到60W/sec，但是吞吐量较低，只能到60MB/sec；
      • 消息大小超过1K时，生产者的QPS会急剧下降到18W/sec，而吞吐量非常高，高达80M/sec。

    • Case10 端到端的延时
      端到端是指从生产者发送消息开始到消息被消费者消费掉的整个时间。
      以下是生产者同步发送5000条消息的端到端的延时

    2 ms (均值)
    3 ms (99%)
    14 ms (99.9%)

端到端的代码
代码实现