[TOC]
Kafka起初是由 Linkedin公司采用 Scala语言开发的一个多分区、多副本且基于 ZooKeeper 协调的分布式消息系统，现己被捐献给 Apache 基金会 。 目前 Kafka 已经定位为一个分布式流式 处理平台，它以高吞吐、可持久化、可水平扩展、支持流数据处理等多种特性而被广泛使用。目前越来越多的开源分布式处理系统如 Cloudera、 Storm、 Spark、 Flink 等都支持与 Kafka 集成 。

Kafka之所以受到越来越多的青睐，与它所“扮演 ”的三大角色是分不开的 :

消息系统: Kafka 和传统的消息系统(也称作消息中间件〉都具备系统解稿、冗余存 储、流量削峰、缓冲、异步通信、扩展性、 可恢复性等功能。与此同时， Kafka 还提 供了大多数消息系统难以实现的消息 顺序性保障及回溯消费 的功能 。

存储系统: Kafka 把消息持久化到磁盘，相比于其他基于内存存储的系统而言，有效 地降低了数据丢失的风险 。 也正是得益于 Kafka 的消息持久化功能和多副本机制，我 们可以把 Kafka 作为长期的数据存储系统来使用，只需要把对应的数据保留策略设置 为“永久”或启用主题的日志压缩功能即可 。

流式处理平台: Kafka 不仅为每个流行的流式处理框架提供了可靠 的数据来源，还 提 供了一个完整的流式处理类库，比如窗口、连接、变换和聚合等各类操作 。

基本概念

一个典型的 Kafka 体系架构包括若干 Producer、若干 Broker、若干 Consumer，以及一个 ZooKeeper集群，如图 1-1 所示。 其中 ZooKeeper是 Kafka用来负责集群元数据的管理、控制器 的选举等操作的 。 Producer 将消息发送到 Broker, Broker 负责将收到的消息存储到磁盘中，而Consumer 负责从 Broker 订阅并消 费消息。

image.png

整个 Kafka 体系结构中引入了以下 3 个术语。
( 1) Producer: 生产者，也就是发送消息的一方。生产者负责创建消息 ， 然后将其投递到Kafka 中 。

( 2 ) Consumer:消费者，也就是接收消息的 一方。消费者连接到 Kafka 上并接收消息，进而进行相应的业务逻辑处理 。

(3) Broker:服务代理节点。对于 Kafka 而言， Broker 可以简单地看作一个独立的 Kafka 服务节点或 Kafka服务实例。大多数情况下也可以将 Broker看作一台 Kafka服务器，前提是这 台服务器上只部署了一个 Kafka 实例。一个或多个 Broker 组成了 一个 Kafka 集群 。一般而言， 我们更习惯使用首字母小写的 broker 来表示服务代理节点 。

在Kafka中还有两个特别重要的概念一一主题(Topic)与分区(Partition)。 Kafka中的消 息以主题为单位进行归类，生产者负责将消息发送到特定的主题(发送到 Kafka 集群中的每一 条消息都要指定一个主题)，而消费者负责订阅主题并进行消费。

主题是一个逻辑上的概念，它还可以细分为多个分区，一个分区只属于单个主题，很多时 候也会把分区称为主题分区( Topic-Partition)。同一主题下的不同分区包含的消息是不同的， 分区在存储层面可以看作一个可追加的日志( Log)文件，消息在被追加到分区日志、文件的时 候都会分配一个特定的偏移量(offset)。 offset是消息在分区中的唯一标识， Kafka通过它来保 证消息在分区内的顺序性，不过 offset并不跨越分区，也就是说， Kafka保证的是分区有序而不 是主题有序。

如图 1-2 所示，主题中有 4 个分区，消息被顺序追加到每个分区日志文件的尾部。 Kafka中的分区可以分布在不同的服务器 (broker)上，也 就是说，一个主题可以横跨多个 broker，以 此来提供比单个 broker 更强大的性能 。

image.png

每一条消息被发送到 broker 之前，会根据分区规则选择存储到哪个具体的分区 。 如果分区 规则设定得合理，所有的消息都可以均匀地分配到不同的分区中 。 如果一个主题只对应一个文 件，那么这个文件所在的机器 I/O 将会成为这个主题的性能瓶颈，而分区解决了这个问题 。 在 创建主题的时候可以通过指定的参数来设置分区的个数，当然也可以在主题创建完成之后去修 改分区的数量，通过增加分区的数量可以实现水平扩展。

Kafka 为分区引入了多副本 (Replica) 机制， 通过增加副本数量可以提升容灾能力。同一 分区的不同副本中保存的是相同的消息(在同一时刻，副本之间并非完全一样)，自1J本之间是 “一主多从”的关系，其中 leader副本负责处理读写请求， follower副本只负责与 leader副本的 消息同步。副本处于不同的 broker 中 ，当 leader 副本出现故障时，从 follower 副本中重新选举 新的 leader副本对外提供服务。 Kafka通过多副本机制实现了故障的自动转移，当 Kafka集群中某个 broker 失效时仍然能保证服务可用 。

如图1-3所示， Kafka集群中有4个broker，某个主题中有3个分区，且副本因子(即副本个数〉也为 3，如此每个分区便有 l 个 leader副本和 2个 follower副本 。生产者和消费者只与 leader 副本进行交互，而 follow巳r副本只负责消息的同步，很多时候 follower副本中的消息相对 leader 副本而言会有一定的滞后。

image.png

Kafka 消费端也具备一定的容灾能力。 Consumer 使用拉 (Pull)模式从服务端拉取消息， 并且保存消费 的具体位置 ， 当消费者看机后恢复上线时可以根据之前保存的消费位置重新拉取 需要 的消息进行消 费 ，这样就不 会造 成消息丢失 。

分区中 的所有副本统称为 AR ( Assigned Replicas) 。 所有与 leader 副本保持 一定程度 同步 的副本(包括 leader 副本在内〕组成 ISR On-Sync Replicas ) , ISR 集合是 AR 集合中 的一个子 集 。 消息会先发送到 lead巳r 副本，然后 follower 副本才能从 leader 副本中拉取消息进行同步， 同步期间内 follower 副本相对于 leader 副本而言会有一定程度的滞后。 前面所说的“一定程度 的同步”是指可忍受的滞后范围，这个范围可以通过参数进行配置 。 与 leader 副本同 步滞后过 多的副本(不包 括 leader 副本)组成 OSR ( Out-of-Sync Replicas)，由 此可见， AR=ISR+OSR。 在正常情况下， 所有的 follower副本都应该与 leader副本保持一定程度的同步，即 AR=ISR, OSR 集合为空。

leader 副本负 责维护和跟踪 ISR 集合中所有 follower 副 本 的滞后状态， 当 follower 副本落后 太多或失效时， leader副本会把它从ISR集合中剔除。 如果OSR集合中有follower副本“追上’p 了 leader副本，那么 leader副本会把它从 OSR集合转移至 ISR集合。 默认情况下， 当 leader副 本发生故障时，只有在 ISR集合中的副本才有资格被选举为新的 leader， 而在 OSR集合中的副 本则没有任何机会(不过这个原则也可以通过修改相应的参数配置来改变) 。

ISR 与 HW 和 LEO 也有紧密的关系 。 HW 是 High Watermark 的缩写，俗称高水位，它标识 了一个特定的消息偏移量(offset)，消费者只能拉取到这个 offset之前的消息。

如图 1-4 所示，它代表一个日志文件，这个日志文件中有 9 条消息，第一条消息的 offset (LogStartOffset)为 0
最后一条消息的 offset为 8, offset为 9 的消息用虚线框表示，代表下一条待写入 的消息 。日志文件的 HW 为 6，表示消费者只能拉取到 offset 在 0 至 5 之间的消息， 而 offset 为 6 的消息对消 费者而言是不可见 的

image.png

LEO 是 Log End Offset 的缩写，它标识当前日志文件中下一条待写入消息 的 offset，图 1-4 中offset为9的位置即为当前日志文件的LEO, LEO的大小相当于当前日志分区中最后一条消 息的 offset值加 l。分区 ISR集合中的每个副本都会维护自身的 LEO，而ISR集合中最小的 LEO，即为分区的 HW ，对消费者而言只能消费 HW 之前的消息 。

很多资料中误将图1-4 offset为5看做HW,而把offset为8的位置看作LEO，这显然是不对的

为了让读者更好地理解ISR集合， 以及HW和LEO之间的关系， 下面通过一个简单的示 例来进行相关的说明 。 如图 1-5 所示，假设某个分区的 ISR 集合中有 3 个副本，即一个 leader副本和 2 个 follower 副本，此时分区的 LEO 和 HW 都为 3。消息 3 和消息 4 从生产者发出之后会被先存入 leader 副本，如图 1-6 所示 。

image.png

image.png

在消息写入leader副本之后， follower 副本会发送拉取请求来拉取消息3和消息4以进行消息同步。

在同步过程中，不同的 follower 副本的同步效率也不尽相同。如图 1-7 所示， 在某一时刻 follower! 完全跟上了 leader 副本而 follower2 只同步了消息 3，如此 leader 副本的 LEO 为 5, follower! 的 LEO 为 5, follower2 的 LEO 为 4， 那么当前分区的 HW 取最小值 4，此时消费者可以消费到 offset为 0至 3 之间的消息。

image.png

写入消息(情形的如图 1-8 所示 ，所有的副本都成功 写入 了消息 3 和消息 4，整个分区的 HW 和 LEO 都变为 5，因此消费者可以消费到 offset为 4 的消息了 。

image.png

由此可见， Kafka 的复制机制既不是完全的同步复制，也不是单纯的异步复制。事实上， 同步复制要求所有能工作的 folower 副本都复制完，这条消息才会被确认为已成功提交，这种 复制方式极大地影响了性能。而在异步复制方式下， follower 副本异步地从 leader 副本中 复制数 据，数据只要被 leader 副本写入就被认为已经成功提交。在这种情况下，如果 follower 副本都 还没有复制完而落后于 leader 副本，突然 leader 副本着机，则会造成数据丢失。 Kafka 使用的这 种 ISR 的方式则有效地权衡了数据可靠性和性能之间的关系。

生产与消费

由 1.1 节的内容可知， 生产者将消息发送至 Kafka 的主题中， 或者更加确切地说应该是主 题的分区中，而消费者也是通过订阅主题从而消费消息的。 在演示生产与消费消息之前，需要 创建一个主题作为消息的载体。

Kafka提供了许多实用的脚本工具 ， 存放在$KAFKA HOME 的 bin 目录下，其中与主题有 关的就是 kafka-topics.sh 脚本，下面我们用它演示创建一个分区数为 4、副本因子为 3 的主题 topic-demo，示例如 下 :

[root@nodel kafka 2.11-2.0.0]# bin/kafka-topics.sh --zookeeper localhost: 2181/kafka --create --topic topic-demo --replication-factor 3 --partitions 4

Created topic "topic- demo” .

其中一zookeeper指定了 Kafka所连接的 ZooKeeper服务地址，--topic指定了所要创 建主题的名称， --replication-factor 指定了副本因子， --partitions 指定了分区个 数，一create 是创建主题的动作指令。

还可以通过一describe展示主题的更多具体信息， 示例如下:

[root@nodel kafka 2.11-2.0.0]# bin/kafka-topics .sh --zookeeper localhost: 2181/kafka --describe - t opic topic- demo

创建主题 topic-demo 之后我们再来检测 一 下 Kafka 集群 是否 可以正常地发送和消费消息 。 $KAFKA HOME/bin 目录下还提供了两个脚本 kafka-console-producer.sh 和 kafka-console­ consumer. sh，通过控制台收发消息。首先我们打开一个 shell终端，通过 kafka-console-consumer.sh 脚本来订阅 主题 topic-demo，示例如下:

[root@nodel kafka 2.11-2.0.0J# bin/kafka console co口sumer. sh --bootstrap- server localhost:9092 --topic topic- demo

其中一-bootstrap server 指定了连接的 Kafka集群地址，--top工c指定了消费者订阅 的主题 。 目前主题 topic-demo 尚未有任何消息存入，所以此脚 本还不能消费 任何消 息。

我们再打开一个 shell终端，然后使用 kafka-console-producer.sh脚本发送一条消息“Hello, Kafka!”至主题 topic-demo，示例如下:

[root@nodel kafka 2.11-2.0.0]# b工n/kafka-console-producer.sh --broker-list localhost: 9092 topic top工c-demo
>hello , Kafka! >

其中 一-broker-list 指定了连接的 Kafka集群地址， --topic 指定了发送消息时的主题。 示例中的第二行是通过人工键入的方式输入的，按下回车键后会跳到第三行，即“>”字符处。 此时原先执行 kafka-console-consumer.sh脚本的 shell终端中出现了刚刚输入的消息、 “Hello, Kafka!”， 示 例如下:

[root@nodel kafka 2.11-2.0.0]# bin/kafka-console-consumer.sh --bootstrap- server localhost:9092 --topic topic- demo
hello world

也可以通过输入一些其他自定义的消息来熟悉消息的收发及这两个脚本的用法 。 不过 这两个脚本一般用来做一些测试类的工作，在实际应用中，不会只是简单地使用这两个脚本来 做复杂的与业务逻辑相关的消息生产与消费的工作，具体的工作还需要通过编程的手段来实施

服务踹参数配置

在Kafka 安装与配置的说明中只是简单地表述了几个必要的服务端参数而没有对 其进行详细的介绍，井且Kafka服务端参数(brokerconfigs)也并非只有这几个。 Kafka服务端 还有很多参数配置，涉及使用、调优的各个方面，虽然这些参数在大多数情况下不需要更改， 但了解这些参数，以及在特殊应用需求的情况下进行有针对性的调优，可以更好地利用 Kafka 为我们工作。下面挑选一些重要的服务端参数来做细致的说明，这些参数都配置在 $KAFKA_HOME/config/server.properties 文件中。

1. zookeeper.connect

该参数指 明 broker 要连接的 ZooKeeper集群的服务地址(包含端口号)，没有默认值，且 此参数为必填工页。可以配置为 localhost:2181，如果 ZooKeeper集群中有多个节点，则可以用逗 号将每个节点隔开，类似于 localhost1 :2181,localhost2 :2181,localhost3: 2181 这种格式。最佳的实践方式是再加一个 chroot路径，这样既可以明确指明该 chroot路径下的节 点是为 Kafka 所用的， 也可以 实现多个 Kafka 集群复用一套 ZooKeeper 集群，这样可以节省更 多的硬件资源。包含 chroot 路径的配置类似 于 localhost1: 2181 , localhost2:2181, localhost3 : 2181/kafka 这种，如果不指定 chroot，那么默认使用 ZooKeeper 的根路径。

2. listeners

该参数指明 broker监听客户端连接的地址列表，即为客户端要连接 broker 的入口地址列表， 配置格式为 protocoll : //hostnamel:portl, protocol2://hostname2:port2 ，其 中 protocol 代表协议类型， Kafka 当前支持的协议类型有 PLAINTEXT、 SSL、 SASL_SSL 等， 如果未开启安全认证，则使用简单的 PLAINTEXT 即可。 hostname 代表主机名， p。此代表服务 端口，此参数的默认值为 null。比如此参数配置为 PLAINTEXT://198.162.0.2:9092，如 果有多个地址，则中间以逗号隔开。如果不指定主机名，则表示绑定默认网卡，注意有可能会 绑定到 127.0.0.1，这样无法对外提供服务，所以主机名最好不要为 空; 如果主机名是 0.0.0.0, 则表示绑定所有的网卡。与此参数关联的还有 advertised.listeners， 作用和 listeners 类似，默认值也为 null。不过 advertised.listeners 主要用于 IaaS (Infrastructure as a Service)环境，比如公 有云上的机器通常配备有多块网卡 ，即包含私网网卡和公网网卡，对于 这种情况而言，可以设置 advertised.listeners 参数绑定公网 IP 供外部客户端使用，而 配置 listeners 参数来绑定私 网 IP 地址供 broker 间通信使用 。

3. broker.id
   该参数用来指定 Kafka 集群中 broker 的唯一标识，默认值为 1。如果没有设置，那么 Kafka会自动生成一个 。这个参数还和 meta.properties 文件及服务端参数 broker.id.geηeration. enable 和 reserved.broker.max.id有关

4. log.dir 和 log.dirs
   Kafka 把所有的消息都保存在磁盘上，而这两个参数用来配置 Kafka 日志文件存放的根目 录。一般情况下， log . dir 用来配置单个根目录，而 log . dirs 用来配置多个根目录(以逗 号分隔〉，但是 Kafka 井没有对此做强制性限制，也就是说， log.dir 和 log.dirs 都可以 用来配置单个或多个根目录 。 log.dirs 的优先级比 log.dir 高，但是如果没有配置 log . dirs ，则会以 log . dir 配置为准。默认情况下只配置了 log . dir 参数，其默认值为 /tmp/kafka-logs。

5. message.max.bytes

该参数用来指定 broker所能接收消息的最大值，默认值为 1000012 (B)，约等于 976.6阻。 如果 Producer 发送的消息大于这个参数所设置的值，那么( Producer 〉就会报出 RecordTooLargeException 的 异常。如果需要修改这个参数，那么还要考虑 max.request . size(客户端参数)、 max.message.bytes (topic端参数)等参数的影响。为了避免修改此参数 而引起级联的影响，建议在修改此参数之前考虑分拆消息的可行性。