关于后端:Kafka系列一Kafka入门

有的时候博客内容会有变动，首发博客是最新的，其余博客地址可能会未同步, 认准https://blog.zysicyj.top

首发博客地址

系列文章地址

Kafka 是什么？

一句话概括：Apache Kafka 是一款开源的音讯引擎零碎

什么是音讯引擎零碎？

音讯引擎零碎（Message Broker System）是一种中间件软件或服务，用于在分布式系统中进行异步消息传递。它提供了牢靠的音讯传输、音讯路由和音讯解决的性能，使不同的应用程序和组件可能通过发送和接管音讯进行通信。

音讯引擎零碎通常由以下几个外围组件组成：

1. 发布者（Publisher）：负责将音讯公布到音讯引擎零碎中。发布者将音讯发送到指定的主题（Topic）或队列（Queue）中。
2. 订阅者（Subscriber）：订阅者能够通过订阅特定的主题或队列来接管音讯。订阅者能够依照本人的需要抉择订阅的音讯类型和主题。
3. 主题 / 队列（Topic/Queue）：主题或队列是音讯的目的地，音讯发布者将音讯发送到特定的主题或队列，而订阅者能够从中接管相应的音讯。
4. 音讯路由（Message Routing）：音讯引擎零碎负责将音讯路由到正确的订阅者。它依据订阅者的订阅关系和音讯的标识（如主题、标签等）来确定音讯的路由形式。
5. 音讯长久化（Message Persistence）：音讯引擎零碎通常会将音讯长久化到存储介质中，以确保音讯的可靠性和持久性。这样即便在系统故障或重启后，音讯依然能够被正确地传递和解决。
6. 消息传递模式（Message Delivery
   Patterns）：音讯引擎零碎反对多种消息传递模式，如点对点模式（Point-to-Point）、公布 / 订阅模式（Publish/Subscribe）、申请 / 响应模式（Request/Response）等，以满足不同的通信需要。

音讯引擎零碎具备解耦性、可靠性和扩展性等长处，使得分布式系统中的不同组件可能进行异步通信，进步零碎的可靠性、可伸缩性和性能。常见的音讯引擎零碎包含 Apache
Kafka、RabbitMQ、ActiveMQ 等。

为什么要引入音讯引擎呢？间接 A 发送给 B 不好吗？

引入音讯引擎零碎的次要目标是解耦和进步零碎的可伸缩性、可靠性和性能。上面是一些应用音讯引擎零碎的长处：

1. 解耦性：通过引入音讯引擎零碎，发送者和接收者之间能够解耦。发送者只须要将音讯发送到音讯引擎中的特定主题或队列，而不须要间接晓得接收者的详细信息。接收者能够依据本人的需要抉择订阅相应的主题或队列来接管音讯。这种解耦能够使零碎的组件能够独立演变和扩大，防止了紧耦合的依赖关系。
2. 异步通信：音讯引擎零碎反对异步通信模式，发送者能够将音讯发送到音讯引擎中后立刻返回，而不须要期待接收者的响应。这种异步通信模式能够进步零碎的响应速度和并发解决能力，使得发送者和接收者能够独立地进行工作解决，进步零碎的整体性能和吞吐量。
3. 可靠性：音讯引擎零碎通常会将音讯长久化到存储介质中，以确保音讯的可靠性和持久性。即便在系统故障或重启后，音讯依然能够被复原和传递，防止了音讯的失落。此外，音讯引擎零碎还提供了音讯的确认机制和重试机制，确保音讯的牢靠传递。
4. 扩展性：应用音讯引擎零碎能够轻松地扩大零碎的规模和容量。通过减少音讯引擎的实例或减少音讯队列的分区，能够实现程度扩大，以解决更大的音讯流量和更高的并发申请。
5. 消息传递模式：音讯引擎零碎反对多种消息传递模式，如点对点模式、公布 / 订阅模式、申请 / 响应模式等。不同的模式实用于不同的业务场景，能够依据需要抉择适合的模式。

引入音讯引擎零碎能够提供更灵便、牢靠和高效的消息传递形式，使得零碎能够更好地适应简单的业务需要和分布式环境。它提供理解耦、异步通信、可靠性、可伸缩性和性能等劣势，使零碎设计更具弹性和可维护性。

常见的音讯传输模型有哪些呢

在计算机系统中，常见的音讯传输模型有以下几种：

1. 点对点模型（Point-to-Point Model）：在点对点模型中，音讯的发送者将音讯发送到特定的接收者。每个音讯只被一个接收者接管，相似于一对一的通信。这种模型通常应用队列或消息中间件来实现，例如 JMS（Java
   Message Service）中的点对点模型。
2. 公布 / 订阅模型（Publish/Subscribe
   Model）：在公布 / 订阅模型中，音讯的发送者（发布者）将音讯公布到一个主题（Topic），多个接收者（订阅者）能够订阅该主题，接管公布的音讯。这种模型通常用于播送音讯给多个接收者，相似于一对多的通信。常见的实现包含音讯队列、消息中间件、事件总线等。
3. 申请 / 响应模型（Request/Response
   Model）：在申请 / 响应模型中，客户端发送申请音讯给服务端，服务端解决申请并发送响应音讯给客户端。这种模型通常用于客户端向服务端申请数据或执行操作，并期待服务端返回响应。常见的实现包含 HTTP 协定、RPC（Remote
   Procedure Call）等。
4. 公布 / 订阅加申请 / 响应模型：这种模型联合了公布 / 订阅模型和申请 / 响应模型的个性。音讯的发送者能够公布音讯到一个主题，多个接收者能够订阅该主题并接管音讯。同时，某些接收者还能够向发送者发送申请音讯，并期待发送者的响应音讯。这种模型通常用于实现简单的分布式系统和消息传递模式。

这些音讯传输模型能够依据具体的需要和场景进行抉择和组合，以实现灵便、牢靠的音讯传输和通信。不同的模型实用于不同的利用场景，需依据具体的业务需要来抉择适合的模型。

那么，kafka 反对哪些音讯传输模型？

Kafka 是一个分布式流解决平台，它反对以下几种常见的音讯传输模型：

1. 公布 / 订阅模型（Publish/Subscribe
   Model）：Kafka 的外围个性就是基于公布 / 订阅模型的音讯传输。生产者（发布者）将音讯公布到一个主题（Topic），多个消费者（订阅者）能够订阅该主题，以并行形式生产音讯。Kafka 应用消息日志来长久化音讯，保障音讯的持久性和可靠性。
2. 队列模型（Queue Model）：只管 Kafka 次要是基于公布 / 订阅模型，但也能够通过应用单个消费者组来实现相似队列模型的行为。在这种状况下，每个主题的每个分区只能由一个消费者生产，确保音讯按程序进行解决。
3. 申请 / 响应模型（Request/Response
   Model）：只管 Kafka 次要是用于流式解决，但也能够应用申请 / 响应模式。客户端能够向 Kafka 发送申请音讯，并期待 Kafka 返回响应音讯。这种模型通常用于须要以申请 / 响应形式与 Kafka 进行交互的利用场景。
4. 批量解决模型（Batch Processing Model）：Kafka 反对从生产者端进行音讯批量发送，以及从消费者端进行音讯批量生产。这种模型能够更无效地利用网络和 IO 资源，进步音讯的吞吐量和性能。

Kafka 的灵活性和可扩展性使其实用于许多不同的利用场景，包含实时数据流解决、音讯队列、日志收集和剖析等。依据具体的需要，能够抉择适合的模型来构建基于 Kafka 的音讯传输零碎。

不同模型对应的应用场景是什么呢

1. 点对点模型（Point-to-Point Model）：

   • 实用场景：单个音讯只能被一个接收者解决的场景。例如，工作散发零碎、异步申请 - 响应零碎等。

2. 公布 / 订阅模型（Publish/Subscribe Model）：

   • 实用场景：须要将音讯播送给多个订阅者的场景。例如，实时数据推送、事件告诉、日志订阅等。

3. 申请 / 响应模型（Request/Response Model）：

   • 实用场景：须要进行申请和响应的场景。例如，客户端与服务器之间的申请 - 响应交互、RPC（近程过程调用）等。

4. 队列模型（Queue Model）：

   • 实用场景：须要确保音讯按程序解决的场景，每个音讯只能被一个接收者解决。例如，工作队列、工作流零碎等。

5. 扇出 / 扇入模型（Fan-Out/Fan-In Model）：

   • 实用场景：须要将音讯复制给多个不同的接收者的场景。例如，日志记录和剖析零碎、音讯播送等。

6. 申请 / 异步响应模型（Request/Async Response Model）：

   • 实用场景：须要异步解决申请并返回响应的场景。例如，长时间运行的工作、异步告诉等。

7. 分布式事务模型（Distributed Transaction Model）：

   • 实用场景：须要保障多个分布式系统之间的事务一致性的场景。例如，分布式订单解决、分布式领取零碎等。

Kafka 术语阐明

• 音讯：Record。Kafka 是音讯引擎嘛，这里的音讯就是指 Kafka 解决的次要对象。
• 主题：Topic。主题是承载音讯的逻辑容器，在理论应用中多用来辨别具体的业务。
• 分区：Partition。一个有序不变的音讯序列。每个主题下能够有多个分区。
• 音讯位移：Offset。示意分区中每条音讯的地位信息，是一个枯燥递增且不变的值。
• 正本：Replica。Kafka 中同一条音讯可能被拷贝到多个中央以提供数据冗余，这些中央就是所谓的正本。正本还分为领导者正本和追随者正本，各自有不同的角色划分。正本是在分区层级下的，即每个分区可配置多个正本实现高可用。
• 生产者：Producer。向主题公布新音讯的应用程序。
• 消费者：Consumer。从主题订阅新音讯的应用程序。消费者位移：
• Consumer Offset。表征消费者生产进度，每个消费者都有本人的消费者位移。消费者组：
• Consumer Group。多个消费者实例独特组成的一个组，同时生产多个分区以实现高吞吐。
• 重均衡：Rebalance。消费者组内某个消费者实例挂掉后，其余消费者实例主动重新分配订阅主题分区的过程。Rebalance 是 Kafka
  消费者端实现高可用的重要伎俩。

咱们要留神的几个点

Kafka 的正本并不像 MySQL 那样对外提供服务

Kafka 的正本（Replicas）和 MySQL 的正本（Replicas）在性能和设计上有一些不同，因而它们在对外提供服务方面有所不同。

1. 数据复制目标不同：Kafka 的正本是为了提供数据冗余和高可用性而设计的，它们用于备份主题的分区数据，以避免数据失落。正本之间的数据同步和复制是 Kafka 集群的外围机制。而 MySQL 的正本则是为了提供数据的冗余备份和读取负载平衡而设计的，正本之间通过复制和同步来保证数据的一致性和可用性。
2. 数据读写形式不同：Kafka 的正本只用于读取数据，不间接对外提供写入服务。生产者将音讯写入主题的分区，而后 Kafka 集群负责将音讯复制到正本中，以提供冗余和容错能力。消费者能够从任意正本中读取数据，实现高可用性和负载平衡。而 MySQL 的正本是通过主从复制实现数据的读写拆散，主节点负责写入操作，从节点负责读取操作。
3. 数据一致性要求不同：Kafka 的正本之间的数据同步是异步进行的，即主题的分区数据在写入主节点后，可能会有一些提早才被复制到正本。这种异步复制形式能够进步 Kafka 的吞吐量和性能，但可能导致正本之间存在肯定的数据提早。而 MySQL 的正本之间的数据同步是同步进行的，确保数据在主节点写入后立刻被复制到所有正本，以保证数据的一致性和可用性。

Kafka 只是一个音讯引擎吗？

Kafka 通常被形容为一个分布式流解决平台，而不仅仅是一个音讯引擎。只管 Kafka 的外围性能是音讯引擎，它提供了高性能、牢靠的分布式消息传递，但 Kafka 还具备其余重要的个性和性能，使其成为一个全面的分布式流解决平台。

如果你通读全篇文字但只能记住一句话，我心愿你记住的就是这句。再强调一遍，Kafka 是音讯引擎零碎，也是分布式流解决平台。

Kafka 发展史

Kafka 的设计历史能够追溯到 2010 年，过后由 LinkedIn 的工程师 Jay Kreps、Neha Narkhede 和 Jun Rao 共同开发和推出。

1. 起初的需要：在 LinkedIn，存在一个须要解决大规模数据流的问题。传统的音讯队列零碎无奈满足其高吞吐量和低提早的需要。因而，Jay
   Kreps、Neha Narkhede 和 Jun Rao 决定自行开发一种新的解决方案。
2. 我的项目开始：2010 年，Kafka 我的项目正式启动。最后的指标是构建一个高性能的分布式提交日志零碎，用于 LinkedIn 外部的数据管道和实时流式解决。
3. 公布开源：2011 年，LinkedIn 将 Kafka 作为开源我的项目公布，成为 Apache 软件基金会的孵化我的项目。这使得更多的公司和开发者开始参加和奉献 Kafka 的倒退。
4. Kafka 0.8 版本：2012 年，公布了 Kafka 的第一个重要版本 0.8。该版本引入了新的存储层设计，应用分段日志（Segmented
   Log）来进步吞吐量和可靠性。此外，0.8 版本还引入了新的音讯生产模型（Consumer Model），反对多个消费者组和音讯的长久化存储。
5. Kafka 0.9 版本：2015 年，公布了 Kafka 的 0.9 版本。这是一个重要的里程碑，引入了 Kafka 的新的消费者 API，加强了安全性和可靠性。此外，0.9 版本还引入了 Kafka
   Connect 和 Kafka Streams，使 Kafka 成为一个全面的流解决平台。
6. Kafka 1.0 版本：2017 年，公布了 Kafka 的 1.0 版本。这是一个重要的稳固版本，引入了许多改良和性能优化。1.0 版本还引入了幂等写入和事务反对等重要性能，使 Kafka 成为更牢靠和全面的分布式流解决平台。

自那时以来，Kafka 继续倒退和改良，一直减少新的性能和个性。它曾经成为一个宽泛应用的分布式流解决平台，被许多公司和组织用于构建实时数据管道、事件驱动应用程序和大规模数据处理。

言归正传，Kafka 在设计之初就旨在提供三个方面的个性：

• 提供一套 API 实现生产者和消费者；
• 升高网络传输和磁盘存储开销；
• 实现高伸缩性架构。

后续的文章中，咱们将陆续探讨 Kafka 是如何做到以上三点的。

Kafka 生态

Kafka 有哪些版本？

1. Apache Kafka：这是 Kafka 的官网发行版，由 Apache 软件基金会进行保护和治理。Apache Kafka 是一个开源我的项目，提供了稳固的版本和官网反对。
2. Confluent Platform：Confluent 是一家专一于 Kafka 的公司，他们提供了 Confluent Platform 作为 Kafka 的一个企业级发行版。Confluent
   Platform 在 Apache Kafka 的根底上扩大了一些企业级性能和工具，包含集成的 Schema Registry、Kafka Connect、KSQL 等。
3. Cloudera Distribution Including Apache Kafka（CDH）。CDH 是 Cloudera 提供的一个发行版，它基于 Apache
   Kafka，并与 Cloudera 生态系统中的其余工具和框架集成。CDH 提供了一套集成的工具和治理界面，帮忙用户更不便地部署、治理和监控 Kafka 集群。

Apache Kafka

对 Apache Kafka 而言，它当初仍然是开发人数最多、版本迭代速度最快的 Kafka。在 2018 年度 Apache 基金会邮件列表开发者数量最多的
Top 5 排行榜中，Kafka 社区邮件组排名第二位。如果你应用 Apache Kafka 碰到任何问题并提交问题到社区，社区都会比拟及时地响应你。这对于咱们
Kafka 一般使用者来说无疑是十分敌对的。

然而 Apache Kafka 的劣势在于它仅仅提供最最根底的组件，特地是对于后面提到的 Kafka Connect 而言，社区版 Kafka
只提供一种连接器，即读写磁盘文件的连接器，而没有与其余内部零碎交互的连接器，在理论应用过程中须要自行编写代码实现，这是它的一个劣势。另外
Apache Kafka 没有提供任何监控框架或工具。显然在线上环境不加监控必定是不可行的，你必然须要借助第三方的监控框架实现对 Kafka
的监控。好消息是目前有一些开源的监控框架能够帮忙用于监控 Kafka（比方 Kafka manager）。

Confluent Kafka

上面来看 Confluent Kafka。Confluent Kafka 目前分为免费版和企业版两种。前者和 Apache Kafka 十分相像，除了惯例的组件之外，免费版还蕴含
Schema 注册核心和 REST proxy 两大性能。前者是帮忙你集中管理 Kafka 音讯格局以实现数据前向 / 后向兼容；后者用凋谢 HTTP
接口的形式容许你通过网络拜访 Kafka 的各种性能，这两个都是 Apache Kafka 所没有的。

除此之外，免费版蕴含了更多的连接器，它们都是 Confluent
公司开发并认证过的，你能够收费应用它们。至于企业版，它提供的性能就更多了。在我看来，最有用的当属跨数据中心备份和集群监控两大性能了。多个数据中心之间数据的同步以及对集群的监控从来是
Kafka 的痛点，Confluent Kafka 企业版提供了弱小的解决方案帮忙你“干掉”它们。

不过 Confluent Kafka 的一大缺点在于，Confluent 公司临时没有倒退国内业务的打算，相干的材料以及技术支持都很欠缺，很多国内
Confluent Kafka 使用者甚至无奈找到对应的中文文档，因而目前 Confluent Kafka 在国内的普及率是比拟低的。

一言以蔽之，如果你须要用到 Kafka 的一些高级个性，那么举荐你应用 Confluent Kafka。

CDH/HDP Kafka

最初说说大数据云公司公布的 Kafka（CDH/HDP Kafka）。这些大数据平台人造集成了 Apache Kafka，通过便捷化的界面操作将 Kafka
的装置、运维、治理、监控全副对立在控制台中。如果你是这些平台的用户肯定感觉十分不便，因为所有的操作都能够在前端 UI
界面上实现，而不用去执行简单的 Kafka 命令。另外这些平台提供的监控界面也十分敌对，你通常不须要进行任何配置就能无效地监控
Kafka。

然而凡事无利就有弊，这样做的后果是间接升高了你对 Kafka 集群的掌控水平。毕竟你对上层的 Kafka 集群无所不知，你怎么能做到成竹在胸呢？这种
Kafka 的另一个弊病在于它的滞后性。因为它有本人的公布周期，因而是否能及时地蕴含最新版本的 Kafka 就成为了一个问题。比方 CDH
6.1.0 版本公布时 Apache Kafka 曾经演进到了 2.1.0 版本，但 CDH 中的 Kafka 仍然是 2.0.0 版本，显然那些在 Kafka 2.1.0 中修复的
Bug 只能等到 CDH 下次版本更新时才有可能被真正修复。

** 简略来说，如果你须要疾速地搭建音讯引擎零碎，或者你须要搭建的是多框架形成的数据平台且 Kafka 只是其中一个组件，那么我举荐你应用这些大数据云公司提供的
Kafka。**

最初说一说 Kafka 版本演进

1. Kafka 0.8.x 系列：这是 Kafka 的初始版本系列。它引入了 Kafka 的基本功能，如高吞吐量、持久性、分布式消息传递等。在这个系列中，Kafka 引入了生产者和消费者 API，以及根本的音讯存储和复制机制。
2. Kafka 0.9.x 系列：这个版本系列引入了一些重要的改良和新个性。其中最显著的是引入了 Kafka Connect 和 Kafka Streams。Kafka
   Connect 提供了可插拔的连接器，用于将 Kafka 与内部系统集成。Kafka Streams 是一个用于构建实时流解决应用程序的库。
3. Kafka 0.10.x 系列：这个版本系列引入了一些重要的改良和新个性。其中包含了 Exactly-Once 语义的反对，这是通过引入事务 API 来实现的。此外，Kafka
   0.10.x 还引入了 Kafka Mirror Maker，用于在不同的 Kafka 集群之间进行数据复制和同步。
4. Kafka 0.11.x 系列：这个版本系列引入了一些重要的改良和新个性。其中包含了 Kafka Streams 的重大改良，如窗口操作和 KTable。此外，Kafka
   0.11.x 还引入了 Kafka Admin Client，用于治理和配置 Kafka 集群。
5. Kafka 1.0.x 系列：这个版本系列是 Kafka 的一个重要里程碑。它引入了许多重要的改良和新个性，包含 Kafka
   Streams 的重大改良、更好的安全性反对、更好的监控和管理工具等。
6. Kafka 2.0.x 系列：这个版本系列引入了一些重要的改良和新个性。其中包含了 KIP-98，引入了 Exactly-Once 语义的加强反对。此外，Kafka
   2.0.x 还引入了 KRaft，这是一种新的复制协定，用于提供更弱小的数据一致性保障。

本文由 mdnice 多平台公布