文章内容是学习过程中的知识总结，如有纰漏，欢迎指正

---

前言

先来看一张图，下面这张图就是 kafka 生产与消费的核心架构模型！

如下图，一个kafka架构包括若干个Producer（服务器日志、业务数据、web前端产生的page view等），若干个Broker（kafka支持水平扩展，一般broker数量越多集群的吞吐量越大），若干个consumer group，一个Zookeeper集群（kafka通过Zookeeper管理集群配置、选举leader、consumer group发生变化时进行rebalance）

---

以下是本篇文章正文内容

1. 核心概念

下面我们结合上面的图来介绍以下Kafka中的核心概念

1.1 Producer

生产者（Producer）顾名思义，生产者就是产生消息的组件，它的主要工作就是源源不断地生产出消息，然后发送给消息队列。

生产者可以向消息队列发送各种类型的消息，如狭义的字符串消息，也可以发送二进制消息，生产者是消息队列的数据来源，只有通过生产者持续不断地 向消息队列发送消息，消息队列才能不断地处理消息。

1.2 broker

broker代表了Kafka的实体服务

在消息队列领域中，它指的其实就是消息队列产品本身，比如说在Kafka这个领域下，Broker 其实就是指的就是一个 Kafka Server，换句话说，我们可以部署一台 Kafka Server 看作是一个Broker， 就是这样简单，那么从流程上来说，生产者就会将消息发送给 Broker, 然后消费者再从 Broker 中拉取消息。

1.3 consumer

消费者的概念也是比较容易理解的，所谓消费者，值得是不断消费（获取）消息的组件它获取消息的来源就是消息队列（即 Kafka 本身）

换句话说 生产者不断地向消息队列发送消息，而消费者则不断地从消息队列中获取消息，这里面的消息队列（Kafka）则充当了一个中介的角色，连接了生产者与 消费者这两大功能组件，正是从这个意义上来说，借助于消息队列，我们实现了生产系统与消费者系统之间的解耦，使得原本需要两个系统之间紧密联系的两个系统各自针对Kafka进行编程，这可以使得生产系统完全不需要了解消费者系统的各种信息 ，这正是消息队列所提供的一种绝佳的好处，极大降低了 系统之间的耦合关系。

1.4 zookeeper

ZooKeeper用于管理和协调Kafka的Broker

ZooKeeper服务主要用于通知生产者和消费者Kafka系统中存在任何新代理或Kafka系统中代理失败。 根据Zookeeper接收到关于代理的存在或失败的通知，然后生产者和消费者采取决定并开始与某些其他代理协调他们的任务。

1.5 controller

控制器是集群中的概念，每个集群中会选择出一个 Broker 担任控制器的角色，控制器是 Kafka 集群的中心

在Kafka中该协调者称之为控制器(Controller)，其实该控制器并没有什么特殊之处，它本身也是一个普通的Broker，只不过需要负责一些额外的工作(追踪集群中的其他Broker，并在合适的时候处理新加入的和失败的Broker节点、Rebalance分区、分配新的leader分区等)，值得注意的是：Kafka集群中始终只有一个Controller Broker。

1.6 Cluster

集群指的是由多个 Broker 所共同构成的一个整体，对外提供统一的服务，这类于我们在部署系统时都会采用集群的方式来进行。

借助于集群的方式，Kafka 消息队列系统可以实现高可用和容错性，即一台 Borker 挂掉了也不影响真个消息系统的正确运行，集群中的各个 Borker是通过心跳 （Hearbeat）的方式来检测其他机器是否还存活。

2. 逻辑组件

2.1 Topic

是Kafka下消息的类别，类似于RabbitMQ中的Exchange的概念

Kaka中的消息以主题为单位进行归类，生产者负责将消息发送到特定的主题(发送到 Kafka集群中的每条消息都要指定一个主题)，而消费者负责订阅主题并进行消费，（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处）。

2.2 Partition

是Kafka下数据存储的基本单元，这个是物理上的概念

同一个topic的数据，会被分散的存储到多个partition中，这些partition可以在同一台机器上，也可以是在多台机器上，这种方式在大多数分布式存储中都可以见到，比如MongoDB、Elasticsearch的分片技术，其优势在于：有利于水平扩展，避免单台机器在磁盘空间和性能上的限制，同时可以通过复制来增加数据冗余性，提高容灾能力，为了做到均匀分布，通常partition的数量通常是Broker Server数量的整数倍

2.3 Replication

每一个分区都有多个副本，副本的作用是做备胎，主分区（Leader）会将数据同步到从分区（Follower）

当主分区（Leader）故障的时候会选择一个备胎（Follower）上位，成为 Leader，在kafka中默认副本的最大数量是10个，且副本的数量不能大于Broker的数量，follower和leader绝对是在不同的机器，同一机器对同一个分区也只可能存放一个副本

2.4 leader & follower

在Kafka中，每个topic都可以配置多个分区以及多个副本

每个分区都有一个leader以及0个或者多个follower，在创建topic时，Kafka会将每个分区的leader均匀地分配在每个broker上，我们正常使用kafka是感觉不到leader、follower的存在的。

但其实，所有的读写操作都是由leader处理，而所有的follower都复制leader的日志数据文件，如果leader出现故障时，follower就会被选举为leader。

leader和follower的理解

• Kafka中的leader负责处理读写操作，而follower只负责副本数据的同步
• 如果leader出现故障，其他follower会被重新选举为leader
• follower像一个consumer一样，拉取leader对应分区的数据，并保存到日志数据文件中

3. 消费模型

消息由生产者发送到kafka集群后，会被消费者消费，一般来说我们的消费模型有两种：推送模型(psuh)和拉取模型(pull)

首先明确一下推拉模式到底是在讨论消息队列的哪一个步骤，一般而言我们在谈论推拉模式的时候指的是 Comsumer 和 Broker 之间的交互。

默认的认为 Producer 与 Broker 之间就是推的方式，即 Producer 将消息推送给 Broker，而不是 Broker 主动去拉取消息。

3.1 推模式

推模式指的是消息从 Broker 推向 Consumer，即 Consumer 被动的接收消息，由 Broker 来主导消息的发送

优点

我们来想一下推模式有什么好处？

• 消息实时性高， Broker 接受完消息之后可以立马推送给 Consumer
• 对于消费者使用来说更简单，简单啊就等着，反正有消息来了就会推过来。

缺点

• 推送速率难以适应消费速率，推模式的目标就是以最快的速度推送消息，当生产者往 Broker 发送消息的速率大于消费者消费消息的速率时，随着时间增长就会把消费者撑死，因为根本消费不过来啊
• 并且不同的消费者的消费速率还不一样，身为 Broker 很难平衡每个消费者的推送速率，如果要实现自适应的推送速率那就需要在推送的时候消费者告诉 Broker ，我不行了你推慢点吧，然后 Broker 需要维护每个消费者的状态进行推送速率的变更。

3.2 拉模式

拉模式指的是 Consumer 主动向 Broker 请求拉取消息，即 Broker 被动的发送消息给 Consumer

优点

• 拉模式主动权就在消费者身上了，消费者可以根据自身的情况来发起拉取消息的请求，假设当前消费者觉得自己消费不过来了，它可以根据一定的策略停止拉取，或者间隔拉取都行。
• 拉模式下 Broker 就相对轻松了，它只管存生产者发来的消息，至于消费的时候自然由消费者主动发起，来一个请求就给它消息呗，从哪开始拿消息，拿多少消费者都告诉它，它就是一个没有感情的工具人，消费者要是没来取也不关它的事。
• 拉模式可以更合适的进行消息的批量发送，基于推模式可以来一个消息就推送，也可以缓存一些消息之后再推送，但是推送的时候其实不知道消费者到底能不能一次性处理这么多消息，而拉模式就更加合理，它可以参考消费者请求的信息来决定缓存多少消息之后批量发送。

缺点

• 消息延迟，毕竟是消费者去拉取消息，但是消费者怎么知道消息到了呢？所以它只能不断地拉取，但是又不能很频繁地请求，太频繁了就变成消费者在攻击 Broker 了，因此需要降低请求的频率，比如隔个 2 秒请求一次，你看着消息就很有可能延迟 2 秒了。
• 消息忙请求，忙请求就是比如消息隔了几个小时才有，那么在几个小时之内消费者的请求都是无效的，在做无用功。

3.3 Kafka是什么模式

RocketMQ 和 Kafka 都选择了拉模式，当然业界也有基于推模式的消息队列如 ActiveMQ

长轮询模式

像 Kafka 在拉请求中有参数，可以使得消费者请求在 “长轮询” 中阻塞等待。

简单的说就是消费者去 Broker 拉消息，定义了一个超时时间，也就是说消费者去请求消息，如果有的话马上返回消息，如果没有的话消费者等着直到超时，然后再次发起拉消息请求。

并且 Broker 也得配合，如果消费者请求过来，有消息肯定马上返回，没有消息那就建立一个延迟操作，等条件满足了再返回

4. Kafka应用场景

Apache Kafka能够支撑海量数据的数据传递，在离线和实时的消息处理业务系统中，Kafka都有广泛的应用

4.1 消息处理

kafka更好的替换传统的消息系统，消息系统被用于各种场景，与大多数消息系统比较kafka有更好的吞吐量内置分区，副本和故障转移，这有利于处理大规模的消息。

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

4.2 网站活动追踪

kafka原本的使用场景是用户的活动追踪，网站的活动（网页游览，搜索或其他用户的操作信息）发布到不同的话题中心，这些消息可实时处理实时监测也可加载到Hadoop或离线处理数据仓库。

4.3 指标分析

kafka也常常用于监测数据，分布式应用程序生成的统计数据集中聚合。

4.4 日志聚合

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

4.5 流处理

kafka中消息处理一般包含多个阶段，其中原始输入数据是从kafka主题消费的，然后汇总，丰富，或者以其他的方式处理转化为新主题，例如，一个推荐新闻文章，文章内容可能从“articles”主题获取；然后进一步处理内容，得到一个处理后的新内容，最后推荐给用户。这种处理是基于单个主题的实时数据流。从0.10.0.0开始，轻量，但功能强大的流处理，就可以这样进行数据处理了，除了Kafka Streams还有ApacheStorm和Apache Samza可选择。

4.6 事件采集

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