聊聊 Kafka： Kafka 的基础架构

一、我与快递小哥的故事

一个很正常的一个工作日，老周正在忙着啪啪啪的敲代码，办公司好像安静的只剩敲代码的声音。突然，我的电话铃声响起了，顿时打破了这种安静。

我：喂，哪位？
快递小哥：我是顺丰快递的，你有个包裹，请问你现在在家吗？
我：哦，我现在不在家，晚上你再帮我送过来吧。
快递小哥：要不我帮你放在菜鸟驿站吧？
我：可以可以，谢谢了。

还好有菜鸟驿站，不然工作日加班到很晚才回家，晚上快递小哥又下班了，得等到周末我在家快递小哥才能帮我送了。如果没有菜鸟驿站的话，我们来看下快递小哥与我的交互图：

小伙伴们可能发现了菜鸟驿站的好处了，真香。

这里老周来总结几点消息队列的好处也就是使用场景：

• 应用解耦
  到了什么 618、双 11，快递小哥要忙疯了，他得每个电话打，然后询问客户在不在家，几点有时间，这样完全依赖收货人，那快递小哥估计要疯。有了菜鸟驿站，快递小哥直接把快递放在菜鸟驿站，然后通知收货人过去取就好了，这就让收货人与快递小哥实现了解耦。在软件行业的话，即应用解耦。

• 异步处理
  要是没有菜鸟驿站，快递小哥得在楼下等你下来拿快递，拿完了他才能走，这叫同步处理。有了菜鸟驿站，快递小哥把你的快递放在了菜鸟驿站，通知你去取，然后他继续干别的事情去了，这叫异步处理。异步处理明显提升了快递小哥的工作效率，在软件中，写异步代码同样能提升代码的执行效率。

• 流量削锋
  双十一老周买了很多东西，不同的店发的快递不一样，有顺丰、韵达、中通、申通，都在我周日上午十点这个时间段下去拿，搞得我下楼好频繁这个时间段，有了菜鸟驿站，我可以吃中午饭再下去顺便拿下快递，这就达到了十点那个时间段的流量削锋效果。

我与快递小哥的故事是真实发生的哈，正好我有个读者前段时间面试顺丰的时候被问到 Kafka 了，要我出 Kafka 的内容，所以有了灵感写了这篇文章。

二、Kafka 介绍

Kafka 是最初由 Linkedin 公司开发，是一个 分布式、分区的、多副本的、多生产者、多订阅者，基于zookeeper 协调的分布式消息系统。常见可以用于 web/nginx 日志、访问日志，消息服务等。

Linkedin 于 2010 年贡献给了 Apache 基金会并成为顶级开源项目。

2.1 基于zookeeper 协调

这里老周要提一下，Kafka 2.8.0 版本实现了 Raft 分布式一致性机制，意味着可以脱离 ZooKeeper 独立运行了。

ZooKeeper 在 Kafka 中扮演着重要的角色，用来存储 Kafka 的元数据。ZooKeeper 存储着 Partition 和 Broker 的元数据 ，同时也负责 Kafka Controller 的选举工作。

对于 Kafka 来讲，ZooKeeper 是一套外部系统，要想部署一套 Kafka 集群，就要同时部署、管理、监控 ZooKeeper。ZooKeeper 有自己的配置方式、管理工具，和 Kafka 完全不一样，所以，一起搞两套分布式系统，自然就提升了复杂度，也更容易出现问题。有时工作量还会加倍，例如要开启一些安全特性，Kafka 和 ZooKeeper 中都需要配置。除了复杂度，外部存储也会降低系统效率。

例如：

• Kafka 集群每次启动的时候，Controller 必须从 ZooKeeper 加载集群的状态信息。

• 选举出一个新的 Controller 之后也会比较麻烦，因为需要加载元数据，而此时元数据的量可能已经非常大了，这就产生了效率问题。

所以，ZooKeeper 带来的复杂度、系统效率这两个问题已经成为 Kafka 的痛点，Kafka 团队一直在努力去除对 ZooKeeper 的依赖。Kafka 2.8.0 这个版本终于实现了。

使用 Raft 模式之后，元数据、配置信息都会保存在 @metadata 这个 Topic 中，自动在集群中复制。这样 Kafka 就会简单轻巧很多。

但需要注意的是，Zookeeper-less Kafka 还属于早期版本，并不完善，所以，现在不要应用在线上产品环境中。

2.2 主要应用场景

• 日志收集系统

• 消息系统

2.3 Kafka 主要设计目标

• 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能。

• 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输。

• 支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition传输。

• 同时支持离线数据处理和实时数据处理

• 支持在线水平扩展

2.4 两种主要的消息传递模式

2.4.1 点对点模式

2.4.2 发布订阅模式

大部分的消息系统选用发布订阅模式。Kafka 就是一种发布订阅模式。

2.5 Kafka 四个核心 API

• Producer API：允许应用程序将记录流发布到一个或多个 Kafka 主题。

• Consumer API：允许应用程序订阅一个或多个主题并处理为其生成的记录流。

• Streams API：允许应用程序充当流处理器，使用一个或多个主题的输入流，并生成一个或多个输出主题的输出流，从而有效地将输入流转换为输出流。

• Connector API：允许构建和运行将 Kafka 主题连接到现有应用程序或数据系统的可重用生产者或使用者。例如，关系数据库的连接器可能会捕获对表的所有更改。

三、Kafka 的优势

• 高吞吐量：单机每秒处理几十上百万的消息量。即使存储了许多的消息，它也保持稳定的性能。

• 高性能：单节点支持上千个客户端，并保证零停机和零数据丢失。

• 持久化数据存储：将消息持久化到磁盘。通过将数据持久化到硬盘以及防止数据丢失。（零拷贝、 顺序读，顺序写、利用的页缓存）

• 分布式系统，易于向外扩展。所有的 Producer、Broker 和 Consumer 都会有多个，均为分布式的。
  无需停机即可扩展机器。多个 Producer、Consumer 可能是不同的应用。

• 可靠性：Kafka 是分布式、分区、复制和容错的。

• 客户端状态维护：消息被处理的状态是在 Consumer 端维护，而不是由 server 端维护。当失败时能自动平衡。

• 支持 online 和 offline 的场景

• 支持多种客户端语言。Kafka 支持 Java、.NET、PHP、Python 等多种语言。

四、Kafka 的应用场景

4.1 日志收集

Kafka 可以收集各种服务的 Log，通过 Kafka 以统一接口服务的方式开放给各种 Consumer。

4.2 消息系统

解耦生产者和消费者、缓存消息等。

4.3 用户活动跟踪

• Kafka 经常被用来记录 Web 用户或者 App 用户的各种活动，如浏览网页、搜索、点击等活动。

• 这些活动信息被各个服务器发布到 Kafka 的 Topic 中，然后消费者通过订阅这些 Topic 来做实时的监控分析，亦可保存到数据库。

4.4 运营指标

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

4.5 流式处理

比如 Spark Streaming 和 Storm。

五、基础架构

5.1 Kafka 架构图

• Kafka 的数据单元称为消息。可以把消息看成是数据库里的一个“数据行”或一条“记录”。消息由字节数组组成。

• 消息有键，键也是一个字节数组。当消息以一种可控的方式写入不同的分区时，会用到键。

• 为了提高效率，消息被分批写入 Kafka。批次就是一组消息，这些消息属于同一个主题和分区。

• 把消息分成批次可以减少网络开销。批次越大，单位时间内处理的消息就越多，单个消息的传输时间就越长。批次数据会被压缩，这样可以提升数据的传输和存储能力，但是需要更多的计算处理。

5.3 模式

• 消息模式（schema）有许多可用的选项，以便于理解。如 JSON 和 XML，但是它们缺乏强类型处理能力。Kafka 的许多开发者喜欢使用 Apache Avro。Avro 提供了一种紧凑的序列化格式，模式和消息体分开。当模式发生变化时，不需要重新生成代码，它还支持强类型和模式进化，其版本既向前兼容，也向后兼容。

• 数据格式的一致性对 Kafka 很重要，因为它消除了消息读写操作之间的耦合性。

5.4 主题和分区

• Kafka 的消息通过主题进行分类。主题可比是数据库的表或者文件系统里的文件夹。

  主题可以被分为若干分区，一个主题通过分区分布于 Kafka 集群中，提供了横向扩展的能力。
  

5.5 生产者和消费者

• 生产者创建消息。消费者消费消息。

• 一个消息被发布到一个特定的主题上。

• 生产者在默认情况下把消息均衡地分布到主题的所有分区上：

• 直接指定消息的分区

• 根据消息的 key 散列取模得出分区

• 轮询指定分区

• 消费者通过偏移量来区分已经读过的消息，从而消费消息。

• 消费者是消费组的一部分。消费组保证每个分区只能被一个消费者使用，避免重复消费。

• 一个独立的 Kafka 服务器称为 broker。

• broker 接收来自生产者的消息，为消息设置偏移量，并提交消息到磁盘保存。

• broker 为消费者提供服务，对读取分区的请求做出响应，返回已经提交到磁盘上的消息。

• 单个 broker 可以轻松处理数千个分区以及每秒百万级的消息量。

控制器负责管理工作：

• 将分区分配给 broker

• 监控 broker

集群中一个分区属于一个 broker，该 broker 称为分区首领。
一个分区可以分配给多个 broker，此时会发生分区复制。
分区的复制提供了消息冗余， 高可用 。副本分区不负责处理消息的读写。

六、核心概念

6.1 Producer

生产者创建消息。

该角色将消息发布到 Kafka 的 topic 中。broker 接收到生产者发送的消息后，broker 将该消息追加到当前用于追加数据的 segment 文件中。

一般情况下，一个消息会被发布到一个特定的主题上。

• 默认情况下通过轮询把消息均衡地分布到主题的所有分区上。

• 在某些情况下，生产者会把消息直接写到指定的分区。这通常是通过消息键和分区器来实现的，分区器为键生成一个散列值，并将其映射到指定的分区上。这样可以保证包含同一个键的消息会被写到同一个分区上。

• 生产者也可以使用自定义的分区器，根据不同的业务规则将消息映射到分区。

6.2 Consumer

消费者读取消息。

• 消费者订阅一个或多个主题，并按照消息生成的顺序读取它们。

• 消费者通过检查消息的偏移量来区分已经读取过的消息。偏移量是另一种元数据，它是一个不断递增的整数值，在创建消息时，Kafka 会把它添加到消息里。在给定的分区里，每个消息的偏移量都是唯一的。消费者把每个分区最后读取的消息偏移量保存在 Zookeeper 或 Kafka上 ，如果消费者关闭或重启，它的读取状态不会丢失。

• 消费者是消费组的一部分。群组保证每个分区只能被一个消费者使用。

• 如果一个消费者失效，消费组里的其他消费者可以接管失效消费者的工作，再平衡，分区重新分配。

一个独立的 Kafka 服务器被称为 broker。

broker 为消费者提供服务，对读取分区的请求作出响应，返回已经提交到磁盘上的消息。

• 如果某 topic 有 N 个 partition，集群有 N 个 broker，那么每个 broker 存储该 topic 的一个 partition。

• 如果某 topic 有 N 个 partition，集群有 (N+M) 个 broker，那么其中有 N 个 broker 存储该 topic 的一个partition，剩下的 M 个 broker 不存储该 topic 的 partition 数据。

• 如果某 topic 有 N 个 partition，集群中 broker 数目少于 N 个，那么一个 broker 存储该 topic 的一个或多个 partition。在实际生产环境中，尽量避免这种情况的发生，这种情况容易导致 Kafka 集群数据不均衡。

broker 是集群的组成部分。每个集群都有一个 broker  同时充当了集群控制器的角色（自动从集群的活跃成员中选举出来）。

控制器负责管理工作，包括将分区分配给 broker 和监控 broker。

在集群中，一个分区从属于一个 broker，该 broker 被称为分区的首领。

每条发布到 Kafka 集群的消息都有一个类别，这个类别被称为 Topic。

物理上不同 Topic 的消息分开存储。

主题就好比数据库的表，尤其是分库分表之后的逻辑表。

6.5 Partition

• 主题可以被分为若干个分区，一个分区就是一个提交日志。

• 消息以追加的方式写入分区，然后以先入先出的顺序读取。

• 无法在整个主题范围内保证消息的顺序，但可以保证消息在单个分区内的顺序。

• Kafka 通过分区来实现数据冗余和伸缩性。

• 在需要严格保证消息的消费顺序的场景下，需要将 partition 数目设为1。

6.6 Replicas

Kafka 使用主题来组织数据，每个主题被分为若干个分区，每个分区有多个副本。那些副本被保存在broker 上，每个broker 可以保存成百上千个属于不同主题和分区的副本。

副本有以下两种类型：

• 首领副本
      每个分区都有一个首领副本。为了保证一致性，所有生产者请求和消费者请求都会经过这个副本。

• 跟随者副本
      首领以外的副本都是跟随者副本。跟随者副本不处理来自客户端的请求，它们唯一的任务就是从首领那里复制消息，保持与首领一致的状态。如果首领发生崩溃，其中的一个跟随者会被提升为新首领。

6.7 Offset

6.7.1 生产者 Offset

消息写入的时候，每一个分区都有一个 offset，这个 offset 就是生产者的 offset，同时也是这个分区的最新最大的 offset。

有些时候没有指定某一个分区的 offset，这个工作 kafka 帮我们完成。

6.7.2 消费者 Offset

这是某一个分区的 offset 情况，生产者写入的 offset 是最新最大的值是12，而当 Consumer A 进行消费时，从 0 开始消费，一直消费到了 9，消费者的 offset 就记录在 9，Consumer B 就纪录在了 11。等下一次他们再来消费时，他们可以选择接着上一次的位置消费，当然也可以选择从头消费，或者跳到最近的记录并从“现在”开始消费。

6.8、副本

Kafka 通过副本保证高可用。副本分为首领副本(Leader)和跟随者副本(Follower)。

跟随者副本包括同步副本和不同步副本，在发生首领副本切换的时候，只有同步副本可以切换为首领副本。

6.8.1 AR

分区中的所有副本统称为AR（Assigned Repllicas）

AR=ISR+OSR

6.8.2 ISR

所有与leader副本保持一定程度同步的副本（包括Leader）组成ISR（In-Sync Replicas），ISR 集合是 AR 集合中的一个子集。消息会先发送到 leader 副本，然后 follower 副本才能从 leader 副本中拉取消息进行同步，同步期间内 follower 副本相对于 leader 副本而言会有一定程度的滞后。前面所说的“一定程度”是指可以忍受的滞后范围，这个范围可以通过参数进行配置。

6.8.3 OSR

与leader副本同步滞后过多的副本（不包括leader）副本，组成OSR(Out-Sync Relipcas)。在正常情况下，所有的 follower 副本都应该与 leader 副本保持一定程度的同步，即 AR=ISR,OSR 集合为空。

6.8.4 HW

HW 是High Watermak的缩写， 俗称高水位，它表示了一个特定消息的偏移量（offset），消费者只能拉取到这个offset之前的消息。

6.8.5 LEO

LEO 是Log End Offset的缩写，它表示了当前日志文件中下一条待写入消息的 offset。