kafka入门官方文档

一、入门. .............................................................................................1

1、简介. ...............................................................................................1 
2、Topics/logs. .................................................................................2
3、Distribution. ...............................................................................4
4、Producers. .....................................................................................5
5、Consumers. .....................................................................................5
二、使用场景. .....................................................................................6

1、Message. .........................................................................................6
2、Websit activity tracking. ...................................................... 6
3、Log Aggregation. .........................................................................6
三、设计原理. .....................................................................................7

1、持久性. ...........................................................................................7
2、性能. ...............................................................................................7
3、生产者. ...........................................................................................8
4、消费者. .........................................................................................10
5、消息传送机制. .............................................................................21
6、复制备份. .....................................................................................22
7、日志. .............................................................................................23
8、zookeeper. ...................................................................................25
四、主要配置. ...................................................................................29

1、Broker 配置. ................................................................................29
2、Consumer 主要配置. ....................................................................30
3、Producer 主要配置. ....................................................................30
五、 broker 集群的搭建. ................................................................31

1、单机环境的搭建部署. ...........................................................31

2、集群环境的搭建部署. ...........................................................32

一、入门

1、简介

Kafka 是 linkedin 用于日志处理的分布式消息队列，同时支持离线和在线日志处理。kafka 对消息保存时根据 Topic 进行归类，发送 消息者成为 Producer,消息接受者成为 Consumer,此外 kafka 集群有 多个 kafka 实例组成，每个实例(server)称为 broker。无论是 kafka 集群，还是 producer 和 consumer 都依赖于 zookeeper 来保证系统可 用性，为集群保存一些 meta 信息。

2、Topics/logs

一个 Topic 可以认为是一类消息，每个 topic 将被分成多个 partition(区),每个 partition 在存储层面是 append log 文件。任 何发布到此 partition 的消息都会被直接追加到 log 文件的尾部，每条消息在文件中的位置称为 offset（偏移量），offset 为一个 long 型数字，它是唯一标记一条消息。kafka 并没有提供其他额外的索引 机制来存储 offset，因为在 kafka 中几乎不允许对消息进行“随机 读写”。

在 kafka 中，即使消息被消费,消息仍然不会被立即删除。日志文 件将会根据 broker 中的配置要求,保留一定的时间之后删除;比如 log 文件保留 2 天,那么两天后,文件会被清除,无论其中的消息是否 被消费。kafka 通过这种简单的手段,来释放磁盘空间,以及减少消息 消费之后对文件内容改动的磁盘 IO 开支。

对于 consumer 而言,它需要保存消费消息的 offset,对于 offset的保存和使用 ,由 consumer 来控制;当 consumer 正常消费消息 时,offset 将会"线性"的向前驱动,即消息将依次顺序被消费。事实 上 consumer 可以使用任意顺序消费消息,它只需要将 offset 重置为 任意值。(offset 将会保存在 zookeeper 中,参见下文)

kafka集群几乎不需要维护任何 consumer和producer状态信息, 这些信息由 zookeeper 保存;因此 producer 和 consumer 的客户端实 现非常轻量级,它们可以随意离开,而不会对集群造成额外的影响。

partitions 的设计目的有多个。最根本原因是 kafka 基于文件 存储。通过分区,可以将日志内容分散到多个 server 上,来避免文件 尺寸达到单机磁盘的上限,每个 partiton 都会被当前 server(kafka 实例)保存;可以将一个 topic 切分多任意多个 partitions 来保存消 息。此外越多的 partitions 意味着可以容纳更多的 consumer,有效 提升并发消费的能力。(具体原理参见下文)。

3、Distribution

一个 Topic 的多个 partitions,被分布在 kafka 集群中的多个 server 上;每个 server(kafka 实例)负责 partitions 中消息的读写 操作;此外 kafka 还可以配置 partitions 需要备份的个数(replicas), 每个 partition 将会被备份到多台机器上,以提高可用性。

基于 replicated 方案,那么就意味着需要对多个备份进行调度; 每个 partition 都有一个 server 为"leader";leader 负责所有的读 写操作,如果 leader 失效,那么将会有其他 follower 来接管(成为新的 leader);follower 只是单调的和 leader 跟进,同步消息即可。由 此可见作为 leader 的 server 承载了全部的请求压力,因此从集群的 整体考虑,有多少个 partitions 就意味着有多少个"leader",kafka 会将"leader"均衡的分散在每个实例上,来确保整体的性能稳定。

1．发送到 partitions 中的消息将会按照它接收的顺序追加到日志 中。

2．对于消费者而言,它们消费消息的顺序和日志中消息顺序一致。 

3．如果 Topic 的"replication factor"为 N,那么允许 N-1 个 kafka 实例失效。

4、Producers

Producer 将消息发布到指定的 Topic 中,同时 Producer 也能决 定将此消息归属于哪个 partition;比如基于"round-robin"方式或者 通过其他的一些算法等。

5、Consumers

本质上 kafka 只支持 Topic。每个 consumer 属于一个 consumer group;反过来说,每个 group 中可以有多个 consumer。发送到 Topic 的消息,只会被订阅此 Topic 的每个 group 中的一个 consumer 消费。

如果所有的 consumer 都具有相同的 group,这种情况和 queue 模 式很像;消息将会在 consumers 之间负载均衡。

如果所有的 consumer 都具有不同的 group,那这就是"发布-订阅"，消息将会广播给所有的消费者。

在 kafka 中,一个 partition 中的消息只会被 group 中的一个 consumer 消费;每个 group 中 consumer 消息消费互相独立;我们可以 认为一个 group 是一个"订阅"者,一个 Topic 中的每个 partions,只 会被一个"订阅者"中的一个 consumer 消费,不过一个 consumer 可以 消费多个 partitions 中的消息。kafka 只能保证一个 partition 中 的消息被某个 consumer 消费时,消息是顺序的。事实上,从 Topic 角 度来说,消息仍不是有序的。

kafka 的设计原理决定,对于一个 topic,同一个 group 中不能有 多于 partitions 个数的 consumer 同时消费,否则将意味着某些 consumer 将无法得到消息。

二、使用场景

1、Message

对 于 一 些 常 规 的 消 息 系 统 ,kafka 是 个 不 错 的 选 择;partitons/replication 和容错,可以使 kafka 具有良好的扩展性 和性能优势。不过 kafka 并没有提供 JMS 中的"事务性"、"消息确认 机制"、"消息分组"等企业级特性，kafka 只能作为"常规"的消息系 统,在一定程度上,尚未确保消息的发送与接收绝对可靠(比如,消息 重发,消息发送丢失等)。

2、Websit activity tracking

kafka 可以作为"网站活性跟踪"的最佳工具;可以将网页/用户操 作等信息发送到 kafka 中。并实时监控,或者离线统计分析等。

3、Log Aggregation

kafka 的特性决定它非常适合作为"日志收集中心";application 可以将操作日志"批量"、"异步"的发送到 kafka 集群中,而不是保存 在本地或者 DB 中;kafka 可以批量提交消息/压缩消息等,这对 producer 端而言,几乎感觉不到性能的开支。此时 consumer 端可以 使 hadoop 等其他系统化的存储和分析系统。

三、设计原理

kafka 的设计初衷是希望作为一个统一的信息收集平台,能够实时 的收集反馈信息,并需要能够支撑较大的数据量,且具备良好的容错 能力。

1、持久性 

kafka 使用文件存储消息,这就直接决定 kafka 在性能上严重依赖 文件系统的本身特性。且无论任何 OS 下,对文件系统本身的优化几乎 没有可能。文件缓存/直接内存映射等是常用的手段。因为 kafka 是 对日志文件进行 append 操作,因此磁盘检索的开支是较小的;同时为 了减少磁盘写入的次数,broker 会将消息暂时 buffer 起来,当消息的

个数(或尺寸)达到一定阀值时,再 flush 到磁盘,这样减少了磁盘 IO 调用的次数。

2、性能

需要考虑的影响性能点很多,除磁盘 IO 之外,我们还需要考虑网 络 IO,这直接关系到 kafka 的吞吐量问题。kafka 并没有提供太多高 超的技巧;对于 producer 端,可以将消息 buffer 起来,当消息的条数 达到一定阀值时,批量发送给 broker;对于 consumer 端也是一样,批 量 fetch 多条消息。不过消息量的大小可以通过配置文件来指定。对 于 kafka broker 端,似乎有个 sendfile 系统调用可以潜在的提升网 络 IO 的性能:将文件的数据映射到系统内存中,socket 直接读取相应 的 内 存 区 域 即 可 , 而 无 需 进 程 再 次 copy 和 交 换 。 其 实 对 于 producer/consumer/broker 三者而言,CPU 的开支应该都不大,因此 启用消息压缩机制是一个良好的策略;压缩需要消耗少量的 CPU 资源, 不过对于 kafka 而言,网络 IO 更应该需要考虑。可以将任何在网络上 传输的消息都经过压缩。kafka 支持 gzip/snappy 等多种压缩方式。

3、生产者

负载均衡: producer 将会和 Topic 下所有 partition leader 保 持 socket 连接;消息由 producer 直接通过 socket 发送到 broker,中 间不会经过任何"路由层"。事实上,消息被路由到哪个 partition 上, 由 producer 客户端决定。比如可以采用"random""key-hash""轮询"

等,如果一个 topic 中有多个 partitions,那么在 producer 端实现" 消息均衡分发"是必要的。

其中 partition leader 的位置(host:port)注册在 zookeeper 中,producer 作为 zookeeper 的 client,已经注册了 watch 用来监听 partition leader 的变更事件。

异步发送：将多条消息暂且在客户端 buffer 起来，并将他们批量 的发送到 broker，小数据 IO 太多，会拖慢整体的网络延迟，批量延 迟发送事实上提升了网络效率。不过这也有一定的隐患，比如说当 producer 失效时，那些尚未发送的消息将会丢失。

利用 Java 进行编程，需要引入相关 jar 包，具体如下：

4、消费者 

consumer 端向 broker 发送"fetch"请求,并告知其获取消息的 offset;此后 consumer 将会获得一定条数的消息;consumer 端也可以 重置 offset 来重新消费消息。

在 kafka 中,producers 将消息推送给 broker 端，consumer 在和 broker 建立连接之后,主动去 pull(或者说 fetch)消息;这中模式有 些优点,首先 consumer 端可以根据自己的消费能力适时的去 fetch 消 息并处理,且可以控制消息消费的进度(offset);此外,消费者可以良 好的控制消息消费的数量,batch fetch。

在 kafka 中,partition 中的消息只有一个 consumer 在消费,且 不存在消息状态的控制,也没有复杂的消息确认机制,可见 kafka broker 端是相当轻量级的。当消息被 consumer 接收之后,consumer 可以在本地保存最后消息的 offset,并间歇性的向 zookeeper 注册 offset。由此可见,consumer 客户端也很轻量级。

6、复制备份 

kafka 将每个 partition 数据复制到多个 server 上,任何一个 partition 有一个 leader 和多个 follower(可以没有);备份的个数可 以通过 broker 配置文件来设定。leader 处理所有的 read-write 请 求,follower 需要和 leader 保持同步。Follower 和 consumer 一样, 消费消息并保存在本地日志中;leader 负责跟踪所有的 follower 状 态,如果 follower"落后"太多或者失效,leader 将会把它从 replicas 同步列表中删除。当所有的 follower 都将一条消息保存成功,此消息 才被认为是"committed",那么此时 consumer 才能消费它。即使只有 一个 replicas 实例存活,仍然可以保证消息的正常发送和接收,只要 zookeeper 集群存活即可。(不同于其他分布式存储,比如 hbase 需要 "多数派"存活才行)

当 leader 失效时,需在 followers 中选取出新的 leader,可能此 时 follower 落 后 于 leader, 因 此 需 要 选 择 一 个 "up-to-date" 的 follower。选择 follower时需要兼顾一个问题,就是新leader server 上所已经承载的 partition leader 的个数,如果一个 server 上有过 多的 partition leader,意味着此 server 将承受着更多的 IO 压力。 在选举新 leader,需要考虑到"负载均衡"。

7、日志

如果一个 topic 的名称为"my_topic",它有 2 个 partitions,那 么日志将会保存在 my_topic_0 和 my_topic_1 两个目录中;日志文件中保存了一序列"log entries"(日志条目),每个 log entry 格式为"4 个字节的数字 N 表示消息的长度" + "N 个字节的消息内容";每个日 志都有一个 offset 来唯一的标记一条消息,offset 的值为 8 个字节 的 数 字 , 表 示 此 消 息 在 此 partition 中 所 处 的 起 始 位 置 。 每 个 partition 在物理存储层面,有多个 log file 组成(称为 segment)。 segment file 的 命 名 为 " 最 小 offset".kafka 。 例 如 "00000000000.kafka";其中"最小 offset"表示此 segment 中起始消 息的 offset。

其中每个 partiton 中所持有的 segments 列表信息会存储在 zookeeper 中。

当 segment 文件尺寸达到一定阀值时(可以通过配置文件设定, 默认 1G),将会创建一个新的文件;当 buffer 中消息的条数达到阀值 时将会触发日志信息 flush 到日志文件中,同时如果"距离最近一次 flush 的时间差"达到阀值时,也会触发 flush 到日志文件。如果 broker 失效,极有可能会丢失那些尚未 flush 到文件的消息。因为 server 意外实现,仍然会导致 log 文件格式的破坏(文件尾部),那么 就要求当 server 启东是需要检测最后一个 segment 的文件结构是否 合法并进行必要的修复。

获取消息时,需要指定 offset 和最大 chunk 尺寸,offset 用来表示消息的起始位置,chunk size 用来表示最大获取消息的总长度(间接的表示消息的条数)。根据 offset,可以找到此消息所在 segment 文件,然后根据 segment 的最小 offset 取差值,得到它在 file 中的相 对位置,直接读取输出即可。

日志文件的删除策略非常简单:启动一个后台线程定期扫描 log file 列表,把保存时间超过阀值的文件直接删除(根据文件的创建时间)。为了避免删除文件时仍然有 read 操作(consumer 消费),采取 copy-on-write 方式。

8、zookeeper

kafka 使用 zookeeper 来存储一些 meta 信息,并使用了 zookeeper watch 机制来发现 meta 信息的变更并作出相应的动作(比如 consumer 失效,触发负载均衡等)

v  Broker node registry: 当一个 kafka broker 启动后,首先会 向 zookeeper 注册自己的节点信息(临时 znode),同时当 broker 和 zookeeper 断开连接时,此 znode 也会被删除。

格式: /brokers/ids/[0。。。N]，其中[0。。N]表示 broker id,每 个 broker 的配置文件中都需要指定一个数字类型的 id(全局不可重 复),znode 的值为此 broker 的 host:port 信息。

v Broker Topic Registry: 当 一 个 broker 启 动 时 , 会 向 zookeeper 注册自己持有的 topic 和 partitions 信息,仍然是一个临 时 znode。

格式: /brokers/topics/[topic]/partitions/[0。。。N] 其中 [0。。N]表示 partition 索引号。

v Consumer and Consumer group: 每个 consumer 客户端被创建 时,会向 zookeeper 注册自己的信息;此作用主要是为了"负载均衡"。

一个 group 中的多个 consumer 可以交错的消费一个 topic 的所 有 partitions;简而言之,保证此 topic 的所有 partitions 都能被此 group 所消费,且消费时为了性能考虑,让 partition 相对均衡的分散 到每个 consumer 上。

v Consumer id Registry: 每 个 consumer 都 有 一 个 唯 一 的 ID(host:uuid,可以通过配置文件指定,也可以由系统生成),此 id 用 来标记消费者信息。

格式: /consumers/[group_id]/ids/[consumer_id]

仍 然 是 一 个 临 时 的 znode, 此 节 点 的 值 为{"topic_name":#streams。。。},即表示此 consumer 目前所消费的 topic + partitions 列表。

¾ Consumer offset Tracking: 用来跟踪每个 consumer 目前所 消费的 partition 中最大的 offset。

格式:

/consumers/[group_id]/offsets/[topic]/[broker_id-partition_ id]-->offset_value

此 znode 为持久节点,可以看出 offset 跟 group_id 有关,以表明 当 group 中一个消费者失效,其他 consumer 可以继续消费。

¾ Partition Owner registry: 用 来 标 记 partition 被 哪 个 consumer 消费。临时 znode。

格式:

/consumers/[group_id]/owners/[topic]/[broker_id-partition_i

d]-->consumer_node_id

当 consumer 启动时,所触发的操作:

9首先进行"Consumer id Registry";

9然后在"Consumer id Registry"节点下注册一个 watch 用来监听 当前 group 中其他 consumer 的"leave"和"join";只要此 znode path下节点列表变更,都会触发此 group下consumer的负载均衡。 (比如一个 consumer 失效,那么其他 consumer 接管 partitions)。

9在"Broker id registry"节点下,注册一个 watch 用来监听 broker 的存活情况;如果 broker 列表变更,将会触发所有的 groups 下的consumer 重新 balance。