Kafka 概述 核心组件及特性

1.Kafka 简介

(1).Apache Kafka是一个开源消息系统，由Scala写成。是由Apache软件基金会开发的一个开源消息系统项目。

(2). Kafka最初是由LinkedIn开发，并于2011年初开源。2012年10月从Apache Incubator毕业。该项目的目标是为处理实时数据提供一个统一、高通量、低等待的平台。

(3). Kafka是一个分布式消息队列：生产者、消费者的功能。它提供了类似于JMS的特性，但是在设计实现上完全不同，此外它并不是JMS规范的实现。

(4).Kafka对消息保存时根据Topic进行归类，发送消息者称为Producer,消息接受者称为Consumer,此外kafka集群有多个kafka实例组成，每个实例(server)称为broker。

(5).无论是kafka集群，还是producer和consumer都依赖于zookeeper集群保存一些meta信息，来保证系统可用性

在讨论kafka 的特性之前，我们需要理解发布订阅消息的概念及其重要性。在这笔者简要说明一下，发布-订阅消息队列的特征是消息的sender(publisher)并不直接将data(message)发送给receiver， publisher 以某种方法对消息进行分类，而receiver (subscriber) 会订阅接收特定类别的消息。Pub/Sub 系统通常会有broker(消息被发布到的中心点)来进行实现，消息将被发送至broker。

2.Kafka 核心组件

参照下图来看下Kafka的几个核心组件，之后笔者会对这些组件进行详细的介绍

Topic：每一类消息的主题，Kafka将消息按照主题分类
Producer：发送消息者
Consumer：消费消息者（必须订阅后才可以消费，一个消费者可以消费1个或多个主题）
broker：发送的消息保存在一组服务器上，称之为Kafka集群，集群中的每一个Kafka就是一个blocker

Message 和 Batches

       Kafka 中最基本的数据单元是消息message，如果使用过数据库，那么可以把Kafka 中的消息理解成数据库里的一条记录。消息是由字符数组组成的，kafka 并不关系它内部是什么，索引消息的具体格式与Kafka 无关。消息可以有一个可选的key，这个key 也是个字符数组，与消息一样，对于kafka 也是透明的。key 用来确定消息写入分区时，进入哪一个分区。最简单的处理方式，就是把key 作为hash 串，拥有相同key 的消息，肯定会进入同一个分区。

       为了提高效率，Kafka 以批量的方式写入。一个batch 就是一组消息的集合，这一组的数据都会进入同一个topic 和partition（这个是根据producer 的配置来定的）。每一个消息都进行一次网络传输会很消耗性能，因此把消息收集到一起，再同时处理就高效的多了。当然，这样会引入更高的延迟以及吞吐量：batch 越大，同一时间处理的消息就越多。batch 通常都会进行压缩，这样在传输以及存储的时候效率都更高一些

Schemas
       对于Kafa 来说，消息本身是不透明的，这样就能对消息定义更多容易理解的内容。根据个人的需求不同，消息也会有不同的schema。比如JSON 或者
XML 都是对人来说很容易阅读的格式。然后他们在不同的模式版本中间缺乏一些处理的鲁棒性和可扩展性。一些Kafka 的开发者也倾向于使用ApacheAvro（最开始是用来为Hadoop 做序列化的），提供了紧凑的序列化格式，在发生变化时，也不需要重新生成代码，具有很强的数据类型和模式，具有很好的向前扩展与向后兼容的能力。

       Kafka 中数据是连续的，在数据在写入到同时也可能被读取消费，这样数据的格式就很重要了。如果数据的格式发生变化，消费的应用也需要做出适当的调整。如果事先定义好了数据存储的格式，那么读取数据的时候就不需要做特殊的处理了。

Topics 和 Partitions

       消息都是以主题Topic 的方式组织在一起，Topic 也可以理解成传统数据库里的表，或者文件系统里的一个目录。一个主题由broker 上的一个或者多个Partition 分区组成。在Kafka 中数据是以Log 的方式存储，一个partition 就是一个单独的Log。消息通过追加的方式写入日志文件，读取的时候则是从头开始按照顺序读取。注意，一个主题通常都是由多个分区组成的，每个分区内部保证消息的顺序行，分区之间是不保证顺序的。如果你想要kafka 中的数据按照时间的先后顺序进行存储，那么可以设置分区数为1。如下图所示，一个主题由4 个分区组成，数据都以追加的方式写入这四个文件。分区的方式为Kafka 提供了良好的扩展性，每个分区都可以放在独立的服务器上，这样就相当于主题可以在多个机器间水平扩展，相对于单独的服务器，性能更好。

       在Kafka 这种数据系统中经常会提起stream 流这个词，通常流被认为是一个主题中的数据，而忽略分区的概念。这就意味着数据流就是从producer 到consumer。在很多框架中，比如kafka stream,apache samza,storm 在操作实时数据的时候，都是这样理解数据流的。这种操作的模式跟离线系统处理数据的方式不同，如hadoop，是在某一个固定的时间处理一批的数据。

Producer 和 Consumer

Kafka 中主要有两种使用者：Producer 和consumer。

       Producer 用来创建消息。在发布订阅系统中，他们也被叫做Publisher 发布者或writer 写作者。通常情况下，消息都会进入特定的主题。默认情况下，生产者不关心消息到底进入哪个分区，它会自动在多个分区间负载均衡。也有的时候，消息会进入特定的一个分区中。一般都是通过消息的key 使用哈希的方式确定它进入哪一个分区。这就意味着如果所有的消息都给定相同的key，那么他们最终会进入同一个分区。生产者也可以使用自定义的分区器，这样消息可以进入
特定的分区。

       Consumer 读取消息。在发布订阅系统中，也叫做subscriber 订阅者或者reader 阅读者。消费者订阅一个或者多个主题，然后按照顺序读取主题中的数据。消费者需要记录已经读取到消息的位置，这个位置也被叫做offset。每个消息在给定的分区中只有唯一固定的offset。通过存储最后消费的Offset，消费者应用在重启或者停止之后，还可以继续从之前的位置读取。保存的机制可以是zookeeper,或者kafka 自己。

       消费者是以consumer group 消费者组的方式工作，由一个或者多个消费者组成一个组，共同消费一个topic。每个分区在同一时间只能由group 中的一个消费者读取，在下图中，有一个由三个消费者组成的grouop，有一个消费者读取主题中的两个分区，另外两个分别读取一个分区。某个消费者读取某个分区，也可以叫做某个消费者是某个分区的拥有者。在这种情况下，消费者可以通过水平扩展的方式同时读取大量的消息。另外，如果一个消费者失败了，那么其他的group 成员会自动负载均衡读取之前失败的消费者读取的分区。

Brokers 和 Clusters

       单独的kafka 服务器也叫做broker，Broker 从生产者那里获取消息，分配offset，然后提交存储到磁盘年。他也会提供消费者，让消费者读取分区上的消息，并把存储的消息传给消费者。依赖于一些精简资源，单独的broker 也可以轻松的支持每秒数千个分区和百万级的消息。

       Kafka 的broker 支持集群模式，在Broker 组成的集群中，有一个节点也被叫做控制器（是在活跃的节点中自动选择的）。这个controller 控制器负责管理整个集群的操作，包括分区的分配、失败节点的检测等。一个partition 只能出现在一个broker 节点上，并且这个Broker 也被叫做分区的leader。一个分区可以分配多个Broker，这样可以做到多个机器之间备份的效果。这种多机备份在其中一个broker 失败的时候，可以自动选举出其他的broker 提供服务。然而，producer 和consumer 都必须连接leader 才能正常工作。

       Kafka 的一个重要特性就是支持数据的过期删除，数据可以在Broker 上保留一段时间。Kafka 的broker 支持针对topic 设置保存的机制，可以按照大小配置也可以按照时间配置。一旦达到其中的一个限制，可能是时间过期也可能是大小超过配置的数值，那么这部分的数据都会被清除掉。每个topic 都可以配置它自己的过期配置，因此消息可以按照业务的需要进行持久化保留。比如，一个数据追踪分析的topic 可以保留几天时间，一些应用的指标信息则只需要保存几个
小时。topic 支持日志数据的压缩，这样kafka 仅仅会保留最后一条日志生成的key。这在修改日志类型的时候会非常有用。

Multiple Cluster

随着Kafka 部署环境的演变，有时候需要利用多集群的优势。使用多集群的原因如下：
1 不同类型数据的分离
2 安全隔离
3 多数据中心（灾备）

       在使用多数据中心的时候，需要很清楚的理解消息是如何在她们之间传递的。一般情况下，用户可以在多个对外提供服务的网址，产生一些前端数据，然后利
用kafka 把他们统一的汇总到一起，进行分析监控告警。这种备份的机制一般都是应用于单个集群，而不是多集群。

       Kafka 项目提供了一个叫做mirro maker 的工具，它支持多机房的数据传输。它其实就是一个基于queu 连接的consumer 和producer。消息从kafka 中消费，然后传输给另一个集群的kafka。如下图所示，就是使用mirror maker 的一个例子，消息在两个集群的本地聚合，然后再传输给另一个集群进行分析。由于kafka 设计的精简，可以在多机房中实现这种简单的管道处理机制。

3.Kafka 特性（优点）

• 多个生产者

       无论kafka 多个生产者的客户端正在使用很多topic 还是同一个topic ，Kafka 都能够无缝处理好这些生产者。这使得kafka 成为一个从多个前端系统聚合数据,然后提供一致的数据格式的理想系统. 例如, 一个通过多个微服务向用户提供内容的站点, 可以为统计page view 而只设立一个topic, 所有的服务将pageview 以统一的格式写入这个topic. 消费程序能够以统一的数据格式来接收page view 数据, 而不需要去协调多个生产者流.

• 多个消费者

       除了多个生产者之外，kafka 也被设计为多个消费者去读取任意的单个消息流而不相互影响；而其他的很多消息队列系统，一旦一个消息被一个客户端消费，那么这个消息就不能被其他客户端消费，这是kafka 与其他队列不同的地方；同时多个kafka 消费者也可以选择作为一个组的一部分，来分担一个消息流，确保这整个组，这个消息只被消费一次.

• 基于硬盘的消息保存

       Kafka 不仅能够处理多个消费者，而且能够持久的保存消息这也意味着消费者不一定需要实时的处理数据。消息将按照持久化配置规则存储在硬盘上。这个可以根据每个topic 进行设置，允许根据不同的消费者的需求不同 设置不同消息流的保存时间不同， 持久化保存意味着一旦消费者来不及消费或者突然出现流量高峰, 而不会有丢失数据的风险.同样也意味着消息可以由consumer 来负责管理, 比如消费消息掉线了一段时间,不需要担心消息会在producer 上累积或者消息丢失, consumer 能够从上次停止的地方继续消费.

• 可扩展性

       Kafka 最开始设计的时候就把灵活扩展考虑到里面，使其能够处理任意数量的数据；用户刚开始可以用一台进行验证其相关的理念，然后将其扩展成小的三台broker 的开发集群，随着数据的增加，甚至扩展为数十台，上百台规模的大集群。扩展可以在集群正常运行的时候进行，对于整个系统的运作没有影响；这也就意味着，对于很多台broker 的集群，如果一台broker 有故障，不影响为client 提供服务.集群如果要同时容忍更多的故障的话, 可以配置更高的replication factors.

• 高性能

       上面的这些特性使得Apache Kafka 成为一个能够在高负载的情况下表现出优越性能的发布-订阅消息系统。Producer, consumer 和broker 都能在大数据流的情况下轻松的扩展. 扩展过程能够在依然提供从生产到消费亚秒级服务的情况下完成.