聊聊 Kafka： Kafka 的基础架构
一、我与快递小哥的故事
一个很正常的一个工作日，老周正在忙着啪啪啪的敲代码，办公司好像安静的只剩敲代码的声音。突然，我的电话铃声响起了，顿时打破了这种安静。
我：喂，哪位？ 快递小哥：我是顺丰快递的，你有个包裹，请问你现在在家吗？ 我：哦，我现在不在家，晚上你再帮我送过来吧。 快递小哥：要不我帮你放在菜鸟驿站吧？ 我：可以可以，谢谢了。
还好有菜鸟驿站，不然工作日加班到很晚才回家，晚上快递小哥又下班了，得等到周末我在家快递小哥才能帮我送了。如果没有菜鸟驿站的话，我们来看下快递小哥与我的交互图：
要是有菜鸟驿站的话，我们再来看下交互图：
上面故事中的菜鸟驿站就是消息队列，也就是我们本篇要讲的 Kafka；而快递小哥就是生产者，老周就是消费者。老周一直很忙没去菜鸟驿站取快递，就是消息积压。我给快递小哥发消息说，确认快递已经取到了，就是 ACK 机制。小伙伴们可能发现了菜鸟驿站的好处了，真香。
这里老周来总结几点消息队列的好处也就是使用场景：
应用解耦到了什么 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 发布订阅模式
发布订阅模式是一个基于消息送的消息传送模型，该模型可以有多种不同的订阅者。生产者将消息放入消息队列后，队列会将消息推送给订阅过该类消息的消费者。由于是消费者被动接收推送，所以无需感知消息队列是否有待消费的消息！但是 consumer1、consumer2、consumer3 由于机器性能不一样，所以处理消息的能力也会不一样，但消息队列却无法感知消费者消费的速度！所以推送的速度成了发布订阅模模式的一个问题！假设三个消费者处理速度分别是 8M/s、5M/s、2M/s，如果队列推送的速度为5M/s，则 consumer3 无法承受！如果队列推送的速度为 2M/s，则 consumer1、consumer2 会出现资源的极大浪费！
大部分的消息系统选用发布订阅模式。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 架构图
5.2 消息和批次
- Kafka 的数据单元称为消息。可以把消息看成是数据库里的一个“数据行”或一条“记录”。消息由字节数组组成。
- 消息有键，键也是一个字节数组。当消息以一种可控的方式写入不同的分区时，会用到键。
- 为了提高效率，消息被分批写入 Kafka。批次就是一组消息，这些消息属于同一个主题和分区。
- 把消息分成批次可以减少网络开销。批次越大，单位时间内处理的消息就越多，单个消息的传输时间就越长。批次数据会被压缩，这样可以提升数据的传输和存储能力，但是需要更多的计算处理。
5.3 模式
- 消息模式（schema）有许多可用的选项，以便于理解。如 JSON 和 XML，但是它们缺乏强类型处理能力。Kafka 的许多开发者喜欢使用 Apache Avro。Avro 提供了一种紧凑的序列化格式，模式和消息体分开。当模式发生变化时，不需要重新生成代码，它还支持强类型和模式进化，其版本既向前兼容，也向后兼容。
- 数据格式的一致性对 Kafka 很重要，因为它消除了消息读写操作之间的耦合性。
5.4 主题和分区
-
Kafka 的消息通过主题进行分类。主题可比是
数据库的表或者文件系统里的文件夹。主题可以被分为若干分区，一个主题通过分区分布于 Kafka 集群中，提供了横向扩展的能力。
5.5 生产者和消费者
-
生产者创建消息。消费者消费消息。
-
一个消息被发布到一个特定的主题上。
-
生产者在默认情况下把消息均衡地分布到主题的所有分区上：
-
直接指定消息的分区
-
根据消息的 key 散列取模得出分区
-
轮询指定分区
-
消费者通过偏移量来区分已经读过的消息，从而消费消息。
-
消费者是消费组的一部分。消费组保证每个分区只能被一个消费者使用，避免重复消费。
5.6 broker 和集群
- 一个独立的 Kafka 服务器称为 broker。
- broker 接收来自生产者的消息，为消息设置偏移量，并提交消息到磁盘保存。
- broker 为消费者提供服务，对读取分区的请求做出响应，返回已经提交到磁盘上的消息。
- 单个 broker 可以轻松处理数千个分区以及每秒百万级的消息量。
每个集群都有一个 broker 是集群控制器（自动从集群的活跃成员中选举出来）。控制器负责管理工作：
- 将分区分配给 broker
- 监控 broker
集群中一个分区属于一个 broker，该 broker 称为分区首领。 一个分区可以分配给多个 broker，此时会发生分区复制。 分区的复制提供了消息冗余， 高可用 。副本分区不负责处理消息的读写。
六、核心概念
6.1 Producer
生产者创建消息。
该角色将消息发布到 Kafka 的 topic 中。broker 接收到生产者发送的消息后，broker 将该消息追加到当前用于追加数据的 segment 文件中。
一般情况下，一个消息会被发布到一个特定的主题上。
- 默认情况下通过轮询把消息均衡地分布到主题的所有分区上。
- 在某些情况下，生产者会把消息直接写到指定的分区。这通常是通过消息键和分区器来实现的，分区器为键生成一个散列值，并将其映射到指定的分区上。这样可以保证包含同一个键的消息会被写到同一个分区上。
- 生产者也可以使用自定义的分区器，根据不同的业务规则将消息映射到分区。
6.2 Consumer
消费者读取消息。
- 消费者订阅一个或多个主题，并按照消息生成的顺序读取它们。
- 消费者通过检查消息的偏移量来区分已经读取过的消息。偏移量是另一种元数据，它是一个不断递增的整数值，在创建消息时，Kafka 会把它添加到消息里。在给定的分区里，每个消息的偏移量都是唯一的。消费者把每个分区最后读取的消息偏移量保存在 Zookeeper 或 Kafka上 ，如果消费者关闭或重启，它的读取状态不会丢失。
- 消费者是消费组的一部分。群组保证每个分区只能被一个消费者使用。
- 如果一个消费者失效，消费组里的其他消费者可以接管失效消费者的工作，再平衡，分区重新分配。
6.3 Broker一个独立的 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 被称为分区的首领。
6.4 Topic每条发布到 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.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。
