日志收集之kafka

日志收集之kafka

http://www.jianshu.com/p/f78b773ddde5

一、介绍

　　Kafka是一种分布式的，基于发布/订阅的消息系统。主要设计目标如下：

• 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间复杂度的访问性能
• 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条以上消息的传输
• 支持Kafka Server间的消息分区，及分布式消费，同时保证每个Partition内的消息顺序传输
• 同时支持离线数据处理和实时数据处理
• Scale out：支持在线水平扩展

架构与原理

　　kafka的架构和原理想必大家都已经在很多地方看过，今天暂时不讲，下次再开篇详谈，整个kafka的具体工作流和架构如下图：

整体架构

　　如上图所示，一个典型的Kafka集群中包含若干Producer（可以是web前端产生的Page View，或者是服务器日志，系统CPU、Memory等），若干broker（Kafka支持水平扩展，一般broker数量越多，集群吞吐率越高），若干Consumer Group，以及一个Zookeeper集群。Kafka通过Zookeeper管理集群配置，选举leader，以及在Consumer Group发生变化时进行rebalance。Producer使用push模式将消息发布到broker，Consumer使用pull模式从broker订阅并消费消息。

二、安装

　　在centos上安装kafka，我推荐安装confluent公司的kafka套装，我们可以选择自己想要的组件就行。

2.1 yum安装

1. sudo rpm --import http://packages.confluent.io/rpm/2.0/archive.key
2. 添加yum源, confluent.repo

   [confluent-2.0]
   name=Confluent repository for 2.0.x packages
   baseurl=http://packages.confluent.io/rpm/2.0
   gpgcheck=1
   gpgkey=http://packages.confluent.io/rpm/2.0/archive.keyenabled=1

3. sudo yum install confluent-platform-2.11.7安装即可，里面包含confluent-kafka-2.11.7和confluent-schema-registry等组件。

安装完成后马上快速开始吧。

三、kafka命令行

kafka工具安装后，会有很多自带的工具来测试kafka，下面就举几个例子

3.1 kafka-topics

创建、改变、展示全部和描述topics, 例子：

 [root@localhost ~]#/usr/bin/kafka-topics --zookeeper zk01.example.com:2181 --list
sink1
test
[root@localhost ~]#/usr/bin/kafka-topics --zookeeper zk01.example.com:2181 --create --topic

3.2 kafka-console-consumer

从kafka中读取数据，输出到控制台

[root@localhost ~]#kafka-console-consumer --zookeeper zk01.example.com:2181 --topic test

3.3 kafka-console-producer

从标准输出读取数据然后写入到kafka队列中

[root@localhost ~]#/usr/bin/kafka-console-producer --broker-list kafka02.example.com:9092,kafka03.example.com:9092 --topic test2

3.4 kafka-consumer-offset-checker

检查读写的消息量

[root@localhost ~]#/usr/bin/kafka-consumer-offset-checker --group flume --topic test1 --zookeeper zk01.example.com:2181

四、kafka web UI

利用开源项目KafkaOffsetMonitor或者kafka-manager将kafka情况直观的展示出来。

4.1 运行KafkaOffsetMonitor

• 下载jar包，KafkaOffsetMonitor-assembly-0.2.1.jar.
• 执行命令运行即可

  java -cp /root/kafka_web/KafkaOffsetMonitor-assembly-0.2.1.jar com.quantifind.kafka.offsetapp.OffsetGetterWeb  --dbName kafka --zk  zk-server1,zk-server2 --port 8080 --refresh 10.seconds --retain 2.days

• 利用supervisor运行, 在/etc/supervisord.d目录下创建kafka_web.conf文件，内容如下

  [program:kafka_web]
  command=java -cp /root/kafka_web/KafkaOffsetMonitor-assembly-0.2.1.jar com.quantifind.kafka.offsetapp.OffsetGetterWeb  --dbName kafka -zk  zk-server1,zk-server2 --port 8080 --refresh 10.seconds --retain 2.days
  startsecs=0
  stopwaitsecs=0
  autostart=true
  autorestart=true

4.2 运行kafka-manager

运行kafka-manager需要sbt编译，但是编译起来太麻烦了，而且还不一定成功，所以我就直接用docker跑了一个。

• 在centos上，在docker的配置/etc/sysconfig/docker上增加daocloud的加速mirror, 修改docker运行参数：

  other_args=" --registry-mirror=http://7919bcde.m.daocloud.io --insecure-registry=0.0.0.0:5000 -H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock -api-enable-cors=true"

  直接重启docker即可。
• 运行docker命令即可访问

    docker run -p 9000:9000 -e ZK_HOSTS="zk_host:2181" -e APPLICATION_SECRET=kafka-manager  sheepkiller/kafka-manager

五 、性能测试

　　关于性能测试，找到了Kafka的创始人之一的Jay Kreps的bechmark。以下描述皆基于该benchmark。（该benchmark基于Kafka0.8.1）

5.1 测试环境

　　该benchmark用到了六台机器，机器配置如下

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

这6台机器其中3台用来搭建Kafka broker集群，另外3台用来安装Zookeeper及生成测试数据。6个drive都直接以非RAID方式挂载。实际上kafka对机器的需求与Hadoop的类似。

5.2 producer吞吐率

　　该项测试只测producer的吞吐率，也就是数据只被持久化，没有consumer读数据。

• 1个producer线程，无replication
  　　在这一测试中，创建了一个包含6个partition且没有replication的topic。然后通过一个线程尽可能快的生成50 million条比较短（payload100字节长）的消息。测试结果是821,557 records/second（78.3MB/second）。　　
  　　之所以使用短消息，是因为对于消息系统来说这种使用场景更难。因为如果使用MB/second来表征吞吐率，那发送长消息无疑能使得测试结果更好。　　
  　　整个测试中，都是用每秒钟delivery的消息的数量乘以payload的长度来计算MB/second的，没有把消息的元信息算在内，所以实际的网络使用量会比这个大。对于本测试来说，每次还需传输额外的22个字节，包括一个可选的key，消息长度描述，CRC等。另外，还包含一些请求相关的overhead，比如topic，partition，acknowledgement等。这就导致我们比较难判断是否已经达到网卡极限，但是把这些overhead都算在吞吐率里面应该更合理一些。因此，我们已经基本达到了网卡的极限。　　
  　　初步观察此结果会认为它比人们所预期的要高很多，尤其当考虑到Kafka要把数据持久化到磁盘当中。实际上，如果使用随机访问数据系统，比如RDBMS，或者key-velue store，可预期的最高访问频率大概是5000到50000个请求每秒，这和一个好的RPC层所能接受的远程请求量差不多。而该测试中远超于此的原因有两个。
  Kafka确保写磁盘的过程是线性磁盘I/O，测试中使用的6块廉价磁盘线性I/O的最大吞吐量是822MB/second，这已经远大于1Gb网卡所能带来的吞吐量了。许多消息系统把数据持久化到磁盘当成是一个开销很大的事情，这是因为他们对磁盘的操作都不是线性I/O。
  在每一个阶段，Kafka都尽量使用批量处理。如果想了解批处理在I/O操作中的重要性，可以参考David Patterson的”Latency Lags Bandwidth“
• 1个producer线程，3个异步replication
  　　该项测试与上一测试基本一样，唯一的区别是每个partition有3个replica（所以网络传输的和写入磁盘的总的数据量增加了3倍）。每一个broker即要写作为leader的partition，也要读（从leader读数据）写（将数据写到磁盘）作为follower的partition。测试结果为75.1MB/second。　　
  　　该项测试中replication是异步的，也就是说broker收到数据并写入本地磁盘后就acknowledge producer，而不必等所有replica都完replication。也就是说，如果leader crash了，可能会丢掉一些最新的还未备份的数据。但这也会让message acknowledgement延迟更少，实时性更好。　　
  　　这项测试说明，replication可以很快。整个集群的写能力可能会由于3倍的replication而只有原来的三分之一，但是对于每一个producer来说吞吐率依然足够好。　　
• 1个producer线程，3个同步replication
  　　该项测试与上一测试的唯一区别是replication是同步的，每条消息只有在被in sync集合里的所有replica都复制过去后才会被置为committed（此时broker会向producer发送acknowledgement）。
  　　在这种模式下，Kafka可以保证即使leader crash了，也不会有数据丢失。测试结果40.2MB/second。Kafka同步复制与异步复制并没有本质的不同。leader会始终track follower replica从而监控它们是否还alive，只有所有in sync集合里的replica都acknowledge的消息才可能被consumer所消费。而对follower的等待影响了吞吐率。可以通过增大batch size来改善这种情况，但为了避免特定的优化而影响测试结果的可比性，本次测试并没有做这种调整。　　
• 3个producer,3个异步replication
  　　该测试相当于把上文中的1个producer,复制到了3台不同的机器上（在1台机器上跑多个实例对吞吐率的增加不会有太大帮忙，因为网卡已经基本饱和了），这3个producer同时发送数据。整个集群的吞吐率为193,0MB/second。

5.3 Producer Throughput Vs. Stored Data

　　消息系统的一个潜在的危险是当数据能都存于内存时性能很好，但当数据量太大无法完全存于内存中时（然后很多消息系统都会删除已经被消费的数据，但当消费速度比生产速度慢时，仍会造成数据的堆积），数据会被转移到磁盘，从而使得吞吐率下降，这又反过来造成系统无法及时接收数据。这样就非常糟糕，而实际上很多情景下使用queue的目的就是解决数据消费速度和生产速度不一致的问题。　　
　　但Kafka不存在这一问题，因为Kafka始终以O（1）的时间复杂度将数据持久化到磁盘，所以其吞吐率不受磁盘上所存储的数据量的影响。为了验证这一特性，做了一个长时间的大数据量的测试。测试表明当磁盘数据量达到1TB时，吞吐率和磁盘数据只有几百MB时没有明显区别，这个variance是由Linux I/O管理造成的，它会把数据缓存起来再批量flush。　

5.4 consumer吞吐率

　　需要注意的是，replication factor并不会影响consumer的吞吐率测试，因为consumer只会从每个partition的leader读数据，而与replicaiton factor无关。同样，consumer吞吐率也与同步复制还是异步复制无关。　　
1个consumer
　　该测试从有6个partition，3个replication的topic消费50 million的消息。测试结果为89.7MB/second。可以看到，Kafka的consumer是非常高效的。它直接从broker的文件系统里读取文件块。Kafka使用sendfile API来直接通过操作系统直接传输，而不用把数据拷贝到用户空间。该项测试实际上从log的起始处开始读数据，所以它做了真实的I/O。在生产环境下，consumer可以直接读取producer刚刚写下的数据（它可能还在缓存中）。实际上，如果在生产环境下跑I/O stat，你可以看到基本上没有物理“读”。也就是说生产环境下consumer的吞吐率会比该项测试中的要高。
3个consumer
　　将上面的consumer复制到3台不同的机器上，并且并行运行它们（从同一个topic上消费数据）。测试结果为249.5MB/second,正如所预期的那样，consumer的吞吐率几乎线性增涨。　　

5.5 Producer and Consumer

　　上面的测试只是把producer和consumer分开测试，而该项测试同时运行producer和consumer，这更接近使用场景。实际上目前的replication系统中follower就相当于consumer在工作。　　
　　该项测试，在具有6个partition和3个replica的topic上同时使用1个producer和1个consumer，并且使用异步复制。测试结果为75.8MB/second, 可以看到，该项测试结果与单独测试1个producer时的结果几乎一致。所以说consumer非常轻量级。　　

5.6 消息长度对吞吐率的影响

　　上面的所有测试都基于短消息（payload 100字节），而正如上文所说，短消息对Kafka来说是更难处理的使用方式，可以预期，随着消息长度的增大，records/second会减小，但MB/second会有所提高。正如我们所预期的那样，随着消息长度的增加，每秒钟所能发送的消息的数量逐渐减小。但是如果看每秒钟发送的消息的总大小，它会随着消息长度的增加而增加，当消息长度为10字节时，因为要频繁入队，花了太多时间获取锁，CPU成了瓶颈，并不能充分利用带宽。但从100字节开始，我们可以看到带宽的使用逐渐趋于饱和（虽然MB/second还是会随着消息长度的增加而增加，但增加的幅度也越来越小）。　　

5.7 端到端的Latency

　　上文中讨论了吞吐率，那消息传输的latency如何呢？也就是说消息从producer到consumer需要多少时间呢？该项测试创建1个producer和1个consumer并反复计时。结果是，2 ms (median), 3ms (99th percentile, 14ms (99.9th percentile),（这里并没有说明topic有多少个partition，也没有说明有多少个replica，replication是同步还是异步。实际上这会极大影响producer发送的消息被commit的latency，而只有committed的消息才能被consumer所消费，所以它会最终影响端到端的latency）　　

5.8 重现该benchmark

　　如果读者想要在自己的机器上重现本次benchmark测试，可以参考本次测试的配置和所使用的命令。　　
　　实际上Kafka Distribution提供了producer性能测试工具，可通过bin/kafka-producer-perf-test.sh脚本来启动。　
　　读者也可参考另外一份Kafka性能测试报告

文／modeyangg_cs（简书作者）
原文链接：http://www.jianshu.com/p/f78b773ddde5
著作权归作者所有，转载请联系作者获得授权，并标注“简书作者”。