Java工程师的进阶之路-Kafka篇（一）

当今社会各种应用系统诸如商业、社交、搜索、浏览等像信息工厂一样不断的生产出各种信息，在大数据时代，我们面临如下几个挑战：

1. 如何收集这些巨大的信息;
2. 如何分析它;
3. 如何及时做到如上两点;

以上几个挑战形成了一个业务需求模型，即 生产者生产（produce）各种信息，消费者消费（consume）（处理分析）这些信息，而在生产者与消费者之间，需要一个沟通两者的桥梁-消息系统。从一个微观层面来说，这种需求也可理解为不同的系统之间如何传递消息。

Kafka 一个分布式消息系统应运而生：

1. Kafka-由 linked-in 开源；
2. kafka-即是解决上述这类问题的一个框架，它实现了生产者和消费者之间的无缝连接；
3. kafka-高产出的分布式消息系统(A high-throughput distributed messaging system)；

2.为何使用消息系统

• 解耦：

允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。

• 冗余：

消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。

• 扩展性：

因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。

• 灵活性 & 峰值处理能力：

在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。

• 可恢复性：

系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。

• 顺序保证：

在大多使用场景下，数据处理的顺

必看视频！获取2024年最新Java开发全套学习资料 备注Java

序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。（Kafka 保证一个Partition 内的消息的有序性）

• 缓冲：

有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况。

• 异步通信：

很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

3. Kafka 基本架构

3.1. 拓扑结构

3.2. 名词概念

• producer：消息生产者，发布消息到 kafka 集群的终端或服务。
• broker：kafka 集群中包含的服务器。
• topic： 每条发布到 kafka 集群的消息属于的类别，即 kafka 是面向 topic 的。
• partition：partition 是物理上的概念，每个 topic 包含一个或多个 partition。 kafka 分配的单位是 partition。
• consumer：从 kafka 集群中消费消息的终端或服务。
• consumer group：high-level consumer API 中，每个consumer 都属于一个 consumer group，每条消息只能被 consumer group 中的一个 Consumer 消费，但可以被多个 consumer group 消费。
• replica：partition 的副本，保障 partition 的高可用。
• leader：replica 中的一个角色， producer 和 consumer 只跟 leader 交互。
• follower：replica 中的一个角色，从 leader 中复制数据。
• controller：kafka集群中的其中一个服务器，用来进行 leader election 以及 各种 failover
• zookeeper：kafka 通过 zookeeper 来存储集群的 meta 信息。

4. Kafka 基本特性

• 高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒；
• 可扩展性：kafka集群支持热扩展；
• 持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失；
• 容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）；
• 高并发：支持数千个客户端同时读写；

4.1. 设计思想

• consumergroup：各个 consumer 可以组成一个组，每个消息只能被组中的一个 consumer
  消费，如果一个消息可以被多个 consumer 消费的话，那么这些 consumer 必须在不同的组。
• 消息状态：在 Kafka 中，消息的状态被保存在 consumer 中，broker 不会关心哪个消息被消费了被谁消费了，只记录一个offset 值（指向 partition 中下一个要被消费的消息位置），这就意味着如果 consumer 处理不好的话，broker上的一个消息可能会被消费多次。
• 消息持久化：Kafka 中会把消息持久化到本地文件系统中，并且保持极高的效率。
• 消息有效期：Kafka 会长久保留其中的消息，以便 consumer 可以多次消费，当然其中很多细节是可配置的。
• 批量发送：Kafka 支持以消息集合为单位进行批量发送，以提高 push 效率。
• push-and-pull: Kafka 中的 Producer 和 consumer 采用的是 push-and-pull 模式，即 Producer 只管向 broker push 消息，consumer 只管从 broker pull 消息，两者对消息的生产和消费是异步的。Kafka集群中 broker 之间的关系：不是主从关系，各个 broker 在集群中地位一样，我们可以随意的增加或删除任何一个 broker 节点。
• List item负载均衡方面： Kafka 提供了一个 metadata API 来管理 broker 之间的负载（对 Kafka 0.8.x 而言，对于 0.7.x 主要靠 zookeeper 来实现负载均衡）。
• 同步异步：Producer 采用异步 push 方式，极大提高 Kafka 系统的吞吐率（可以通过参数控制是采用同步还是异步方式）。
• 分区机制 partition：Kafka 的 broker 端支持消息分区，Producer可以决定把消息发到哪个分区，在一个分区中消息的顺序就是 Producer发送消息的顺序，一个主题中可以有多个分区，具体分区的数量是可配置的。分区的意义很重大，后面的内容会逐渐体现。
• 离线数据装载：Kafka 由于对可拓展的数据持久化的支持，它也非常适合向 Hadoop 或者数据仓库中进行数据装载。
• 插件支持：现在不少活跃的社区已经开发出不少插件来拓展 Kafka 的功能，如用来配合 Storm、Hadoop、flume 相关的插件。

4.2. 应用场景

1. 日志收集：一个公司可以用Kafka可以收集各种服务的 log，通过 kafka 以统一接口服务的方式开放给各种 consumer，例如
   hadoop、Hbase、Solr 等。
2. 消息系统：解耦和生产者和消费者、缓存消息等。
3. 用户活动跟踪：Kafka 经常被用来记录 web 用户或者 app
   用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到 kafka 的 topic 中，然后订阅者通过订阅这些
   topic 来做实时的监控分析，或者装载到 hadoop、数据仓库中做离线分析和挖掘。
4. 运营指标：Kafka 也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。
5. 流式处理：比如 spark streaming 和 storm

5.Push 模式 vs Pull 模式

5.1. 点对点模式

如上图所示，点对点模式通常是基于拉取或者轮询的消息传送模型，这个模型的特点是发送到队列的消息被一个且只有一个消费者进行处理。生产者将消息放入消息队列后，由消费者主动的去拉取消息进行消费。点对点模型的的优点是消费者拉取消息的频率可以由自己控制。但是消息队列是否有消息需要消费，在消费者端无法感知，所以在消费者端需要额外的线程去监控。

5.2. 发布订阅模式

如上图所示，发布订阅模式是一个基于消息送的消息传送模型，改模型可以有多种不同的订阅者。生产者将消息放入消息队列后，队列会将消息推送给订阅过该类消息的消费者（类似微信公众号）。由于是消费者被动接收推送，所以无需感知消息队列是否有待消费的消息！但是 consumer1、consumer2、consumer3 由于机器性能不一样，所以处理消息的能力也会不一样，但消息队列却无法感知消费者消费的速度！

所以推送的速度成了发布订阅模模式的一个问题！假设三个消费者处理速度分别是 8M/s、5M/s、2M/s，如果队列推送的速度为5M/s，则 consumer3 无法承受！如果队列推送的速度为 2M/s，则 consumer1、consumer2 会出现资源的极大浪费！

5.3. Kafka 的选择

作为一个消息系统，Kafka 遵循了传统的方式，选择由 Producer 向 broker push 消息并由 Consumer 从broker pull 消息。一些日志收集系统 (logging-centric system)，比如 Facebook 的 Scribe和 Cloudera 的 Flume，采用 push 模式。事实上，push 模式和 pull 模式各有优劣。

push 模式很难适应消费速率不同的消费者，因为消息发送速率是由 broker 决定的。push 模式的目标是尽可能以最快速度传递消息，但是这样很容易造成 Consumer 来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而 pull 模式则可以根据 Consumer 的消费能力以适当的速率消费消息。

对于 Kafka 而言，pull 模式更合适。pull 模式可简化 broker 的设计，Consumer 可自主控制消费消息的速率，同时 Consumer 可以自己控制消费方式——即可批量消费也可逐条消费，同时还能选择不同的提交方式从而实现不同的传输语义。

6. Kafka 工作流程

6.1. 发送数据

我们看上面的架构图中，producer 就是生产者，是数据的入口。注意看图中的红色箭头，Producer 在写入数据的时候永远的找 leader，不会直接将数据写入 follower！那 leader 怎么找呢？写入的流程又是什么样的呢？我们看下图：

• 先从集群获取分区的 leader；
• producer 将消息发送给 leader；
• Leader 将消息写入本地文件；
• followers 从l eader 拉取消息；
• followers 将消息写入本地后向 leader 发送 ACK 确认；
• leader 收到所有副本的 ACK 后向 producer 发送 ACK 确认；

6.1.1. 保证消息有序
需要注意的一点是，消息写入 leader 后，follower 是主动的去 leader 进行同步的！producer 采用 push 模式将数据发布到 broker，每条消息追加到分区中，顺序写入磁盘，所以保证同一分区内的数据是有序的！写入示意图如下：

6.1.2. 消息负载分区
上面说到数据会写入到不同的分区，那 kafka 为什么要做分区呢？相信大家应该也能猜到，分区的主要目的是：

• 方便扩展：因为一个 topic 可以有多个 partition，所以我们可以通过扩展机器去轻松的应对日益增长的数据量。

• 提高并发：以 partition 为读写单位，可以多个消费者同时消费数据，提高了消息的处理效率。

熟悉负载均衡的朋友应该知道，当我们向某个服务器发送请求的时候，服务端可能会对请求做一个负载，将流量分发到不同的服务器，那在 kafka 中，如果某个 topic 有多个 partition，producer 又怎么知道该将数据发往哪个 partition 呢？kafka 中有几个原则：

1. partition 在写入的时候可以指定需要写入的 partition，如果有指定，则写入对应的 partition；
2. 如果没有指定 partition，但是设置了数据的 key，则会根据 key 的值 hash 出一个 partition；
3. 如果既没指定 partition，又没有设置 key，则会轮询选出一个 partition；

6.1.3. 保证消息不丢

总结

面试建议是，一定要自信，敢于表达，面试的时候我们对知识的掌握有时候很难面面俱到，把自己的思路说出来，而不是直接告诉面试官自己不懂，这也是可以加分的。

以上就是蚂蚁技术四面和HR面试题目，以下最新总结的最全，范围包含最全MySQL、Spring、Redis、JVM等最全面试题和答案，仅用于参考

有时候很难面面俱到，把自己的思路说出来，而不是直接告诉面试官自己不懂，这也是可以加分的。

以上就是蚂蚁技术四面和HR面试题目，以下最新总结的最全，范围包含最全MySQL、Spring、Redis、JVM等最全面试题和答案，仅用于参考

[外链图片转存中…(img-IsyIIbWe-1716460044974)]