一、概述

Kafka 是一个消息系统，原本开发自 LinkedIn，用作 LinkedIn 的活动流数据（Activity Stream）和运营数据处理管道（Pipeline）的基础。现在它已被多家公司作为多种类型的数据管道和消息系统使用。

• 活动流数据 是几乎所有站点在对其网站使用情况做报表时都要用到的数据中最常规的部分。活动数据包括页面访问量（Page View）、被查看内容方面的信息以及搜索情况等内容。这种数据通常的处理方式是先把各种活动以日志的形式写入某种文件，然后周期性地对这些文件进行统计分析。
• 运营数据 指的是服务器的性能数据（CPU、IO 使用率、请求时间、服务日志等等数据)，总的来说，运营数据的统计方法种类繁多。

Kafka通常用于应用中的两种广播类型：

• 在系统和应用间建立实时的数据管道，能够可信赖的获取数据。
• 建立实时的流应用，可以处理或者响应数据流。

由此可见，kafka给自身的定位并不只是一个消息系统，而是通过发布订阅消息这种机制实现了流平台。

作为一个分布式流平台，通过需要具备以下三个关键能力：

1. 发布订阅记录流，和消息队列或者企业新消息系统类似。
2. 以可容错、持久的方式保存记录流
3. 当记录流产生时就进行处理

Kafka和大多数消息系统一样，搭建好kafka集群后，生产者向特定的topic生产消息，而消费者通过订阅topic，能够准实时的拉取到该topic新消息，进行消费。如下图：

screenshot

kafka主要有以下特性：

• 消息持久化
• 高吞吐量
• 可扩展性

尤其是高吞吐量，是他的最大卖点。kafka之所以能够实现高吞吐量，是基于他自身优良的设计，及集群的可扩展性。

Kafka应用场景

• 消息系统
• 日志系统
• 流处理

二、基本术语

1. Broker：Kafka 集群包含一个或多个服务器，这种服务器被称为 broker。

2. Topic：每条发布到 Kafka 集群的消息都有一个类别（主题），这个类别被称为 Topic。（物理上不同 Topic 的消息分开存储，逻辑上一个 Topic 的消息虽然保存于一个或多个 broker 上，但用户只需指定消息的 Topic 即可生产或消费数据而不必关心数据存于何处）。
   kafka中消息订阅和发送都是基于某个topic。比如有个topic叫做NBA赛事信息，那么producer会把NBA赛事信息的消息发送到此topic下面。所有订阅此topic的consumer将会拉取到此topic下的消息。Topic就像一个特定主题的收件箱，producer往里丢，consumer取走。

3. Partition：Partition 是物理上的概念，每个 Topic 包含一个或多个 Partition。

4. Producer：负责发布消息到 Kafka broker。

5. Consumer：消息消费者，向 Kafka broker 读取消息的客户端。

6. Consumer Group：每个 Consumer 属于一个特定的 Consumer Group（可为每个 Consumer 指定 group name，若不指定 group name 则属于默认的 group）。

三、主题（Topic）和日志（Log）

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

screenshot

四、Consumer与topic关系以及机制

Kafka和其它消息系统有一个不一样的设计，在consumer之上加了一层group。同一个group的consumer可以并行消费同一个topic的消息，但是同group的consumer，不会重复消费。这就好比多个consumer组成了一个团队，一起干活，当然干活的速度就上来了。group中的consumer是如何配合协调的，其实和topic的分区相关联，后面我们会详细论述。

如果同一个topic需要被多次消费，可以通过设立多个consumer group来实现。每个group分别消费，互不影响。

• 如果所有的consumer都具有相同的group，这种情况和JMS queue模式很像，消息将会在consumers之间负载均衡。
• 如果所有的consumer都具有不同的group，那这就是"发布-订阅"，消息将会广播给所有的消费者。

在kafka中，一个partition中的消息只会被group中的一个consumer消费(同一时刻)，每个group中consumer消息消费互相独立，我们可以认为一个group是一个"订阅"者。一个Topic中的每个partions只会被一个"订阅者"中的一个consumer消费，不过一个consumer可以同时消费多个partitions中的消息。

kafka只能保证一个partition中的消息被某个consumer消费时是顺序的。事实上，从Topic角度来说,，当有多个partitions时，消息仍不是全局有序的。

通常情况下，一个group中会包含多个consumer，这样不仅可以提高topic中消息的并发消费能力，而且还能提高"故障容错"性。如果group中的某个consumer失效，那么其消费的partitions将会有其他consumer自动接管。kafka的设计原理决定对于一个topic，同一个group中不能有多于partitions个数的consumer同时消费，否则将意味着某些consumer将无法得到消息。

---

参考文章如下：
作者：稀有气体
来源：CSDN
原文：https://blog.csdn.net/liyiming2017/article/details/82790040