Kafka 调研文档

Kafka是由Scala语言开发，是一个分布式、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统（也可以当做MQ系统），常见可以用于web/nginx日志、访问日志，消息服务等等，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。

主要应用场景是日志收集系统和消息系统。 Kafka主要设计目标如下：

1． 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证

常数时间的访问性能。

2． 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传

输。

3． 支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息

顺序传输。

4． 同时支持离线数据处理和实时数据处理。

2 结构和性能特点

2.1 Kafka的结构

图 2 - 1

如图2-1，kafka接收来自producer发送的消息，核心功能由缓存代理broker实现。发送的消息通过topic进行区分，producer通过topic向kafka broker发送消息，消费者通过topic读取数据。不同topic在物理层面又能以partition为分组，一个topic可以分成若干个

partition， partition还可以细分为segment，一个partition物理上由多个segment组成。Consumer通过topic的区分消费消息。Kafka架构对应一个 zookeeper 集群，通过 zookeeper 管理集群配置。

2.2 Topic 和 Partition

在 kafka 中的每一条消息都有一个 topic。一般来说在我们应用中产生不同类型的数据，都可以设置不同的主题。一个主题一般会有多个消息的订阅者，当生产者发布消息到某个主题时，订阅了这个主题的消费者都可以接收到生产者写入的新消息。Kafka 为每个主题维护了分布式的分区(partition)日志文件，每个 partition 在 kafka 存储层面是 Append Log。任何发布到此 partition 的消息都会被追加到 Log 文件的尾部，在分区中的每条消息都会按照时间顺序分配到一个单调递增的顺序编号，也就是Offset。Offset 是一个 Long 型的数字。通过这个 Offset 可以确定一条在该 Partition 下的唯一消息。如图2-2所示。

图 2 - 2

2.3 Kafka的特性

2.3.1 高吞吐量

高吞吐量是Kafka设计的主要目标，Kafka将数据写到磁盘，充分利用磁盘的顺序读写。同时，Kafka在数据写入及数据同步采用了零拷贝（zero-copy）技术，采用sendFile()函数调用，sendFile()函数是在两个文件描述符之间直接传递数据，完全在内核中操作，从而避免了内核缓冲区与用户缓冲区之间数据的拷贝，操作效率极高。Kafka还支持数据压缩及批量发送，同时Kafka将每个主题划分为多个分区，这一系列的优化及实现方法使得Kafka具有很高的吞吐量，每秒发送的消息可达几十万到百万级别。

2.3.2 扩展性

Kafka要支持对大规模数据的处理，就必须能够对集群进行扩展，分布式必须是其特性之一，这样就可以将多台廉价的PC服务器搭建成一个大规模的消息系统。Kafka依赖ZooKeeper来对集群进行协调管理，这样使得Kafka更加容易进行水平扩展，生产者、消费者和代理都为分布式，可配置多个。同时在机器扩展时无需将整个集群停机，集群能够自动感知，重新进行负责均衡及数据复制。

2.3.3 数据备份和持久化

Kafka的高可靠性的保障来源于其健壮的副本（replication）策略。通过调节其副本相关参数，可以使得Kafka在性能和可靠性之间运转的游刃有余。Kafka从0.8.x版本开始提供partition级别的复制，replication的数量可以在$KAFKA_HOME/config/server.properties中配置（default.replication.refactor）。为了提高消息的可靠性，Kafka每个topic的partition有N个副本（replicas），其中N(大于等于1)是topic的复制因子（replica fator）的个数。Kafka通过

多副本机制实现故障自动转移，当Kafka集群中一个broker失效情况下仍然保证服务可用。在Kafka中发生复制时确保partition的日志能有序地写到其他节点上，N个replicas中，其中一个replica为leader，其他都为follower, leader处理partition的所有读写请求，与此同时，follower会被动定期地去复制leader上的数据。如图2-3即展示了这种patition的副本结构。

图 2 - 3

Kafka提供了数据复制算法保证，如果leader发生故障或挂掉，一个新leader被选举并被接受客户端的消息成功写入。Kafka确保从同步副本列表中选举一个副本为leader，或者说follower追赶leader数据。leader负责维护和跟踪ISR(In-Sync Replicas的缩写，表示副本同步队列)中所有follower滞后的状态。当producer发送一条消息到broker后，leader写入消息并复制到所有follower。消息提交之后才被成功复制到所有的同步副本。消息复制延迟受最慢的follower，重要的是快速检测慢副本，如果follower“落后”太多或者失效，leader将会把它从ISR中删除。

Kafka是要持久化消息的，而且要把消息持久化到磁盘上。普通的系统在实现持久化时可能会先尽量使用内存，当内存资源耗尽时，再一次性地把数据“刷盘”；而Kafka则反其道而行之，所有数据都会立即被写入文件系统的持久化日志中，之后Kafka服务器才会返回结果给客户端通知它们消息已被成功写入。这样做既实时保存了数据，又减少了Kafka程序对于内存的消耗，从而将节省出的内存留给页缓存使用，更进一步地提升了 整体性能。

2.3.4 Kafka的发送特点

Kafka的发送模式由producer端的配置参数producer.type来设置，这个参数指定了在后台线程中消息的发送方式是同步的还是异步的，默认是同步的方式，即producer.type=sync。如果设置成异步的模式，即producer.type=async，可以是producer以batch的形式push数据，这样会极大的提高broker的性能，但是这样会增加丢失数据的风险。如果需要确保消息的可靠性，必须要将producer.type设置为sync。以batch的方式推送数据可以极大的提高处理效率，kafka producer可以将消息在内存中累计到一定数量后作为一个batch发送请求。batch的数量大小可以通过producer的参数控制。通过增加batch的大小，可以减少网络请求和磁盘IO的次数，当然具体参数设置需要在效率和时效性方面做一个权衡。在比较新的版本中还有batch.size这个参数。

3 部署方式

Kafka的部署要求如表3-1：

环境依赖 配置项 启动 资源消耗 Java + Zookeeper 不同节点需要在配置文件种配置节点broker id、节点host.name和zookeeper连接等参数 启动zookeeper，利用kafka-server-start.sh脚本启动 Jvm内存消耗和cpu占用较低，cache容量和硬盘要求较高 表 3 - 1

安装（Linux端） 解压 + 添加环境变量，不同节点单独安装 4 与mq的对比

Kafka与mq（主要是RabbitMq）的一些对比情况如表4-1： kafka RabbitMq 对比项 开发语言 是否支持消息堆积 是否支持事务性消息 是否支持消息全局有序 是否支持消息分区有序 是否支持加密 消息队列协议支持 元数据管理 网络开销 内存消耗

scala,Java 支持消息堆积，并批量持久化到磁盘 支持 不支持 支持 支持 支持自定义协议 通过zookeeper进行管理 相对较小 相对较小 erlang 支持阈值内的消息对接，无法支持较大的消息堆积 不支持 支持 支持 支持 支持AMQP、MQTT、STOMP协议 自身管理 相对较大 相对较大