目录

一. 前言

二. 使用场景

三. 分布式的流平台

四. Kafka 的基本术语

4.1. 主题和日志 （Topic 和 Log）

4.2. 分布式（Distribution）

4.3. 异地数据同步技术（Geo-Replication）

4.4. 生产者（Producers）

4.5. 消费者（Consumers）

4.6. Kafka 的保证（Guarantees）

4.7. Kafka 作为一个消息系统

4.8. Kafka 作为一个存储系统

4.9. Kafka 的流处理

五. 总结

---

一. 前言

    Kafka 最初由 Linkedin 公司开发，是一个分布式、支持分区的（Partition）、多副本的（Replica），基于 Zookeeper 协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景，比如基于 Hadoop 的批处理系统、低延迟的实时系统、Storm/Spark 流式处理引擎，web/nginx 日志、访问日志，消息服务等等，用 scala 语言编写，Linkedin 于2010年贡献给了 Apache 基金会并成为顶级开源项目。

    Kafka 实际上算作是分布式的流处理平台，具备消息中间件的功能，在大数据领域作为流计算的平台，也会做消息分发。

    Kafka 具有高吞吐量、高横向扩容以及故障转移，支持幂等性、事务以及三种消息语义，并且具有消息持久化等特点。

二. 使用场景

    下面是一些关于 Apache Kafka 非常流行的使用场景。这些领域的概述，可查看英文博客《The Log: What every software engineer should...》。

1. 消息系统：Kafka 可以更好的替换传统的消息系统，消息系统被用于各种场景（解耦数据生产者，缓存未处理的消息等），与大多数消息系统比较，Kafka 有更好的吞吐量，内置分区、副本和故障转移，这有利于处理大规模的消息。

    根据我们的经验，消息往往用于较低的吞吐量，但需要低的端到端延迟，并需要提供强大的耐用性的保证。在这一领域的 Kafka 比得上传统的消息系统，如 ActiveMQ 或 RabbitMQ。

2. 行为追踪：Kafka 经常被用来记录 Web 用户或者 App 用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到 Kafka 的 Topic 中，然后订阅者通过订阅这些 Topic来做实时的监控分析，或者装载到 Hadoop、数据仓库中做离线分析和挖掘。

3. 运营指标：Kafka 也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。

4. 日志收集：许多人使用 Kafka 作为日志聚合解决方案的替代品。日志聚合通常从服务器中收集物理日志文件，并将它们放在中央位置（可能是文件服务器或 HDFS）进行处理。Kafka 抽象出文件的细节，并将日志或事件数据更清晰地抽象为消息流。这允许更低延迟的处理并更容易支持多个数据源和分布式数据消费。

5. 流处理：Kafka 中的消息处理一般包含多个阶段。其中原始输入数据是从 Kafka 主题消费的，然后汇总，丰富，或者以其他的方式处理转化为新主题。除了 Kafka Streams，还有 Apache Storm和 Apache Samza 可选择。

    例如，一个推荐新闻文章，文章内容可能从 articles 主题获取；然后进一步处理内容，得到一个处理后的新内容，最后推荐给用户。这种处理是基于单个主题的实时数据流。从 0.10.0.0 开始，轻量，但功能强大的流处理，就可以这样进行数据处理了。

6. 事件采集：事件采集是一种应用程序的设计风格，其中状态的变化根据时间的顺序记录下来，Kafka 支持这种非常大的存储日志数据的场景。

三. 分布式的流平台

Kafka 作为一个分布式的流平台，意味着必须具有三个关键能力：

1. 发布和订阅消息（流），在这方面，它类似于一个消息队列。
2. 以容错（故障转移）的方式存储消息（流）。
3. 在消息流发生时处理它们。

Kafka 主要应用于2大类应用：

1. 构建实时的流数据管道，可靠地获取系统和应用程序之间的数据。
2. 构建实时流的应用程序，对数据流进行转换或反应。

Kafka 的几个概念：

1. Kafka 作为一个集群运行在一个或多个服务器上。
2. Kafka 集群存储的消息是以 Topic 为类别记录的。
3. 每个消息（也叫记录 Record）是由一个 key，一个 value 和时间戳构成。

Kafka 有四个核心 API：

1. 应用程序使用 Producer API 发布消息到一个或多个 Topic（主题）中。
2. 应用程序使用 Consumer API 来订阅一个或多个 Topic，并处理产生的消息。
3. 应用程序使用 Streams API 充当一个流处理器，从一个或多个 Topic 消费输入流，并生产一个输出流到一个或多个输出 Topic，有效地将输入流转换到输出流。
4. Connector API 可构建或运行可重用的生产者或消费者，将 Topic 连接到现有的应用程序或数据系统。例如，连接到关系数据库的连接器可以捕获表的每个变更。

    Client 和 Server 之间的通讯，是通过一条简单、高性能并且和开发语言无关的 TCP 协议。并且该协议保持与老版本的兼容。Kafka 提供了Java Client（客户端）。除了Java 客户端外，还有非常多的其它编程语言的客户端。

四. Kafka 的基本术语

先通过一张图我们来捋一捋相关的概念及之间的关系：

1. Producer：发布消息的对象称之为主题生产者（Kafka topic producer）。

2. Consumer：订阅消息并处理发布的消息的对象称之为主题消费者（Consumers）。

3. Topic：Kafka 将消息分门别类，每一类的消息称之为一个主题（Topic）。

4. Partition：Topic 的分区，每个 Topic 可以有多个分区，分区的作用是做负载，提高 Kafka 的吞吐量。同一个 Topic 在不同的分区的数据是不重复的，Partition 的表现形式就是一个一个的文件夹。

5. Replication：每一个分区都有多个副本，副本的作用是做备胎。当主分区（Leader）故障的时候会选择一个备胎（Follower）上位，成为 Leader。在 Kafka 中默认副本的最大数量是10个，且副本的数量不能大于 Broker 的数量，follower 和 leader 绝对是在不同的机器，同一机器对同一个分区也只可能存放一个副本（包括自己）。

6. Message：每一条发送的消息主体。

7. Consumer Group：我们可以将多个消费者组成一个消费者组，在 Kafka 的设计中同一个分区的数据只能被消费者组中的某一个消费者消费。同一个消费者组的消费者可以消费同一个 Topic 的不同分区的数据，这也是为了提高 Kafka 的吞吐量。

8. Broker：已发布的消息保存在一组服务器中，称之为 Kafka 集群。集群中的每一个节点服务器都是一个代理（Broker）。 消费者可以订阅一个或多个主题（Topic），并从 Broker 拉数据，从而消费这些已发布的消息。

4.1. 主题和日志 （Topic 和 Log）

    Topic 是发布的消息的类别名，一个 Topic 可以有零个，一个或多个消费者订阅该主题的消息。对于每个 Topic，Kafka 集群都会维护一个分区 Log，就像下图中所示：

    每一个分区都是一个顺序的、不可变的消息队列，并且可以持续的添加。分区中的消息都被分了一个序列号，称之为偏移量（offset），在每个分区中此偏移量都是唯一的。

    Kafka 集群保持所有的消息，直到它们过期（无论消息是否被消费）。实际上消费者所持有的仅有的元数据就是这个 offset（偏移量），也就是说 offset 由消费者来控制：正常情况下，当消费者消费消息的时候，偏移量也线性的的增加。但是实际偏移量由消费者控制，消费者可以将偏移量重置为更早的位置，重新读取消息。可以看到这种设计对消费者来说操作自如，一个消费者的操作不会影响其它消费者对此 Log 的处理。

再说说分区。Kafka 中采用分区的设计有几个目的：

1. 一是可以处理更多的消息，不受单台服务器的限制。Topic 拥有多个分区意味着它可以不受限的处理更多的数据。
2. 第二，分区可以作为并行处理的单元，稍后会谈到这一点。

4.2. 分布式（Distribution）

    Log 的分区被分布到集群中的多个服务器上。每个服务器处理它分到的分区。 根据配置每个分区还可以复制到其它服务器作为备份容错。 每个分区有一个 leader，零或多个 follower。Leader处理此分区的所有的读写请求，而 follower 被动的复制数据。如果 leader 宕机，其它的一个follower 会被推举为新的 leader。一台服务器可能同时是一个分区的 leader，另一个分区的follower。这样可以平衡负载，避免所有的请求都只让一台或者某几台服务器处理。

4.3. 异地数据同步技术（Geo-Replication）

    Kafka MirrorMaker 为群集提供 geo-replication 支持。借助 MirrorMaker，消息可以跨多个数据中心或云区域进行复制。 您可以在 active/passive 场景中用于备份和恢复，或者在 active/passive方案中将数据置于更接近用户的位置，或数据本地化。

4.4. 生产者（Producers）

    生产者往某个 Topic 上发布消息。生产者也负责选择发布到 Topic 上的哪一个分区。最简单的方式是从分区列表中轮流选择。也可以根据某种算法依照权重选择分区。生产者负责如何选择分区的算法。

4.5. 消费者（Consumers）

    通常来讲，消息模型可以分为两种， 队列（Queue）和发布-订阅式（Pub/Sub）。 队列的处理方式是一组消费者从服务器读取消息，一条消息只有其中的一个消费者来处理。在发布-订阅模型中，消息被广播给所有的消费者，接收到消息的消费者都可以处理此消息。

    Kafka 为这两种模型提供了单一的消费者抽象模型： 消费者组（Consumer Group）。消费者用一个消费者组名标记自己。 一个发布在 Topic 上消息被分发给此消费者组中的一个消费者。假如所有的消费者都在一个组中，那么这就变成了 Queue 模型。假如所有的消费者都在不同的组中，那么就完全变成了发布-订阅模型。更通用的，我们可以创建一些消费者组作为逻辑上的订阅者。每个组包含数目不等的消费者，一个组内多个消费者可以用来扩展性能和容错。正如下图所示：

    正如传统的消息系统一样，Kafka 保证消息的顺序不变。传统的队列模型保持消息，并且保证它们的先后顺序不变。但是，尽管服务器保证了消息的顺序，消息还是异步的发送给各个消费者，消费者收到消息的先后顺序不能保证了。这也意味着并行消费将不能保证消息的先后顺序。

    用过传统的消息系统的同学肯定清楚，消息的顺序处理很让人头痛。如果只让一个消费者处理消息，又违背了并行处理的初衷。在这一点上 Kafka 做的更好，尽管并没有完全解决上述问题。Kafka 采用了一种分而治之的策略：分区。 因为 Topic 分区中消息只能由消费者组中的唯一一个消费者处理，所以消息肯定是按照先后顺序进行处理的。但是它也仅仅是保证 Topic 的一个分区顺序处理，不能保证跨分区的消息先后处理顺序。所以，如果你想要顺序的处理 Topic 的所有消息，那就只提供一个分区。

4.6. Kafka 的保证（Guarantees）

1. 生产者发送到一个特定的 Topic 的分区上，消息将会按照它们发送的顺序依次加入，也就是说，如果一个消息 M1 和 M2 使用相同的 Producer 发送，M1 先发送，那么 M1 将比 M2 的 offset 低，并且优先的出现在日志中。

2. 消费者收到的消息也是此顺序。

3. 如果一个 Topic 配置了复制因子（Replication Factor）为 N， 那么可以允许 N-1 服务器宕机而不丢失任何已经提交（committed）的消息。

有关这些保证的更多详细信息，请关注后续文章。

4.7. Kafka 作为一个消息系统

Kafka的流与传统企业消息系统相比：

    传统的消息有两种模式：队列和发布订阅。 在队列模式中，消费者池从服务器读取消息（每个消息只被其中一个读取）; 发布订阅模式：消息广播给所有的消费者。这两种模式都有优缺点，队列的优点是允许多个消费者瓜分处理数据，这样可以扩展处理。但是，队列不像多个订阅者，一旦消息者进程读取后故障了，那么消息就丢了。而发布和订阅允许你广播数据到多个消费者，由于每个订阅者都订阅了消息，所以没办法缩放处理。

Kafka 中消费者组有两个概念：

• 队列：消费者组（Consumer Group）允许同名的消费者组成员瓜分处理。
• 发布订阅：允许你广播消息给多个消费者组（不同名）。

Kafka 的每个 Topic 都具有这两种模式。

Kafka 有比传统的消息系统更强的顺序保证：

    传统的消息系统按顺序保存数据，如果多个消费者从队列消费，则服务器按存储的顺序发送消息。尽管服务器按顺序发送，但是消息会异步传递到消费者，因此消息可能乱序到达消费者。这意味着消息存在并行消费的情况，顺序就无法保证。消息系统常常通过仅设1个消费者来解决这个问题，但是这意味着没用到并行处理。

    Kafka 做得更好。通过并行 Topic 的 Partition —— Kafka 提供了顺序保证和负载均衡。每个Partition 仅由同一个消费者组中的一个消费者消费到。并确保消费者是该 Partition 的唯一消费者，并按顺序消费数据。每个 Topic 有多个分区，则需要对多个消费者做负载均衡，但请注意，相同的消费者组中不能有比分区更多的消费者，否则多出的消费者一直处于空等待，不会收到消息。

4.8. Kafka 作为一个存储系统

    所有发布消息到消息队列和消费分离的系统，实际上都充当了一个存储系统（发布的消息先存储起来）。Kafka 比别的系统的优势是它是一个非常高性能的存储系统。

    写入到 Kafka 的数据将写到磁盘并复制到集群中保证容错性。并允许生产者等待消息应答，直到消息完全写入。

    Kafka 的磁盘结构：无论你服务器上有50KB 或50TB，执行是相同的。

    Client 来控制读取数据的位置。你还可以认为 Kafka 是一种专用于高性能、低延迟、提交日志存储、复制和传播特殊用途的分布式文件系统。

4.9. Kafka 的流处理

    仅仅读、写和存储是不够的，Kafka 的目标是实时的流处理。在 Kafka 中，流处理持续获取输入Topic 的数据，进行处理加工，然后写入输出 Topic。

    例如，一个零售 APP，接收销售和出货的输入流，统计数量或调整价格后输出。可以直接使用Producer API 和 Consumer API 进行简单的处理。对于复杂的转换，Kafka 提供了更强大的Streams API。可构建聚合计算或连接流到一起的复杂应用程序。

    助于解决此类应用面临的硬性问题：处理无序的数据，代码更改的再处理，执行状态计算等。

    Streams API 在 Kafka 中的核心：使用 Producer API 和 Consumer API 作为输入，利用 Kafka做状态存储，使用相同的组机制在 Stream 处理器实例之间进行容错保障。

五. 总结

    消息传递、存储和流处理的组合看似反常，但对于 Kafka 作为流式处理平台的作用至关重要。

1. 像 HDFS 这样的分布式文件系统允许存储静态文件来进行批处理。这样系统可以有效地存储和处理来自过去的历史数据。

2. 传统企业的消息系统允许在你订阅之后处理未来的消息，在未来数据到达时处理它。

Kafka 结合了这两种能力，这种组合对于 Kafka 作为流处理应用和流数据管道平台是至关重要的。

    批处理以及消息驱动应用程序的流处理的概念：通过组合存储和低延迟订阅，流处理应用可以用相同的方式对待过去和未来的数据。它是一个单一的应用程序，它可以处理历史的存储数据，当它处理到最后一个消息时，它进入等待未来的数据到达，而不是结束。

    同样，对于流数据管道（pipeline），订阅实时事件的组合使得可以将 Kafka 用于非常低延迟的管道。但是，可靠地存储数据的能力使得它可以将其用于必须保证传递的关键数据，或与仅定期加载数据或长时间维护的离线系统集成在一起。流处理可以在数据到达时转换它。