Kafka是什么？

一句话概括：「Apache Kafka 是一款开源的消息引擎系统」

什么是消息引擎系统？

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

消息引擎系统通常由以下几个核心组件组成：

发布者（Publisher）：负责将消息发布到消息引擎系统中。发布者将消息发送到指定的主题（Topic）或队列（Queue）中。
订阅者（Subscriber）：订阅者可以通过订阅特定的主题或队列来接收消息。订阅者可以按照自己的需求选择订阅的消息类型和主题。
主题/队列（Topic/Queue）：主题或队列是消息的目的地，消息发布者将消息发送到特定的主题或队列，而订阅者可以从中接收相应的消息。
消息路由（Message Routing）：消息引擎系统负责将消息路由到正确的订阅者。它根据订阅者的订阅关系和消息的标识（如主题、标签等）来确定消息的路由方式。
消息持久化（Message Persistence）：消息引擎系统通常会将消息持久化到存储介质中，以确保消息的可靠性和持久性。这样即使在系统故障或重启后，消息仍然可以被正确地传递和处理。
消息传递模式（Message Delivery Patterns）：消息引擎系统支持多种消息传递模式，如点对点模式（Point-to-Point）、发布/订阅模式（Publish/Subscribe）、请求/响应模式（Request/Response）等，以满足不同的通信需求。

消息引擎系统具有解耦性、可靠性和扩展性等优点，使得分布式系统中的不同组件能够进行异步通信，提高系统的可靠性、可伸缩性和性能。常见的消息引擎系统包括Apache Kafka、RabbitMQ、ActiveMQ等。

为什么要引入消息引擎呢？直接A发送给B不好吗？

引入消息引擎系统的主要目的是解耦和提高系统的可伸缩性、可靠性和性能。下面是一些使用消息引擎系统的优点：

「解耦性」：通过引入消息引擎系统，发送者和接收者之间可以解耦。发送者只需要将消息发送到消息引擎中的特定主题或队列，而不需要直接知道接收者的详细信息。接收者可以根据自己的需求选择订阅相应的主题或队列来接收消息。这种解耦可以使系统的组件可以独立演化和扩展，避免了紧耦合的依赖关系。
「异步通信」：消息引擎系统支持异步通信模式，发送者可以将消息发送到消息引擎中后立即返回，而不需要等待接收者的响应。这种异步通信模式可以提高系统的响应速度和并发处理能力，使得发送者和接收者可以独立地进行任务处理，提高系统的整体性能和吞吐量。
「可靠性」：消息引擎系统通常会将消息持久化到存储介质中，以确保消息的可靠性和持久性。即使在系统故障或重启后，消息仍然可以被恢复和传递，避免了消息的丢失。此外，消息引擎系统还提供了消息的确认机制和重试机制，确保消息的可靠传递。
「扩展性」：使用消息引擎系统可以轻松地扩展系统的规模和容量。通过增加消息引擎的实例或增加消息队列的分区，可以实现水平扩展，以处理更大的消息流量和更高的并发请求。
「消息传递模式」：消息引擎系统支持多种消息传递模式，如点对点模式、发布/订阅模式、请求/响应模式等。不同的模式适用于不同的业务场景，可以根据需求选择合适的模式。

引入消息引擎系统可以提供更灵活、可靠和高效的消息传递方式，使得系统可以更好地适应复杂的业务需求和分布式环境。它提供了解耦、异步通信、可靠性、可伸缩性和性能等优势，使系统设计更具弹性和可维护性。

常见的消息传输模型有哪些呢

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

「点对点模型」（Point-to-Point Model）：在点对点模型中，消息的发送者将消息发送到特定的接收者。每个消息只被一个接收者接收，类似于一对一的通信。这种模型通常使用队列或消息中间件来实现，例如JMS（Java Message Service）中的点对点模型。
「发布/订阅模型」（Publish/Subscribe Model）：在发布/订阅模型中，消息的发送者（发布者）将消息发布到一个主题（Topic），多个接收者（订阅者）可以订阅该主题，接收发布的消息。这种模型通常用于广播消息给多个接收者，类似于一对多的通信。常见的实现包括消息队列、消息中间件、事件总线等。
「请求/响应模型」（Request/Response Model）：在请求/响应模型中，客户端发送请求消息给服务端，服务端处理请求并发送响应消息给客户端。这种模型通常用于客户端向服务端请求数据或执行操作，并等待服务端返回响应。常见的实现包括HTTP协议、RPC（Remote Procedure Call）等。
「发布/订阅加请求/响应模型」：这种模型结合了发布/订阅模型和请求/响应模型的特性。消息的发送者可以发布消息到一个主题，多个接收者可以订阅该主题并接收消息。同时，某些接收者还可以向发送者发送请求消息，并等待发送者的响应消息。这种模型通常用于实现复杂的分布式系统和消息传递模式。

这些消息传输模型可以根据具体的需求和场景进行选择和组合，以实现灵活、可靠的消息传输和通信。不同的模型适用于不同的应用场景，需根据具体的业务需求来选择合适的模型。

那么，kafka支持哪些消息传输模型？

Kafka是一个分布式流处理平台，它支持以下几种常见的消息传输模型：

「发布/订阅模型」（Publish/Subscribe Model）：Kafka的核心特性就是基于发布/订阅模型的消息传输。生产者（发布者）将消息发布到一个主题（Topic），多个消费者（订阅者）可以订阅该主题，以并行方式消费消息。Kafka使用消息日志来持久化消息，保证消息的持久性和可靠性。
「队列模型」（Queue Model）：尽管Kafka主要是基于发布/订阅模型，但也可以通过使用单个消费者组来实现类似队列模型的行为。在这种情况下，每个主题的每个分区只能由一个消费者消费，确保消息按顺序进行处理。
「请求/响应模型」（Request/Response Model）：尽管Kafka主要是用于流式处理，但也可以使用请求/响应模式。客户端可以向Kafka发送请求消息，并等待Kafka返回响应消息。这种模型通常用于需要以请求/响应方式与Kafka进行交互的应用场景。
「批量处理模型」（Batch Processing Model）：Kafka支持从生产者端进行消息批量发送，以及从消费者端进行消息批量消费。这种模型可以更有效地利用网络和IO资源，提高消息的吞吐量和性能。

Kafka的灵活性和可扩展性使其适用于许多不同的应用场景，包括实时数据流处理、消息队列、日志收集和分析等。根据具体的需求，可以选择合适的模型来构建基于Kafka的消息传输系统。

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

「点对点模型」（Point-to-Point Model）：
- 适用场景：单个消息只能被一个接收者处理的场景。例如，任务分发系统、异步请求-响应系统等。
「发布/订阅模型」（Publish/Subscribe Model）：
- 适用场景：需要将消息广播给多个订阅者的场景。例如，实时数据推送、事件通知、日志订阅等。
「请求/响应模型」（Request/Response Model）：
- 适用场景：需要进行请求和响应的场景。例如，客户端与服务器之间的请求-响应交互、RPC（远程过程调用）等。
「队列模型」（Queue Model）：
- 适用场景：需要确保消息按顺序处理的场景，每个消息只能被一个接收者处理。例如，任务队列、工作流系统等。
「扇出/扇入模型」（Fan-Out/Fan-In Model）：
- 适用场景：需要将消息复制给多个不同的接收者的场景。例如，日志记录和分析系统、消息广播等。
「请求/异步响应模型」（Request/Async Response Model）：
- 适用场景：需要异步处理请求并返回响应的场景。例如，长时间运行的任务、异步通知等。
「分布式事务模型」（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）在功能和设计上有一些不同，因此它们在对外提供服务方面有所不同。

「数据复制目的不同」：Kafka的副本是为了提供数据冗余和高可用性而设计的，它们用于备份主题的分区数据，以防止数据丢失。副本之间的数据同步和复制是Kafka集群的核心机制。而MySQL的副本则是为了提供数据的冗余备份和读取负载均衡而设计的，副本之间通过复制和同步来保证数据的一致性和可用性。
「数据读写方式不同」：Kafka的副本只用于读取数据，不直接对外提供写入服务。生产者将消息写入主题的分区，然后Kafka集群负责将消息复制到副本中，以提供冗余和容错能力。消费者可以从任意副本中读取数据，实现高可用性和负载均衡。而MySQL的副本是通过主从复制实现数据的读写分离，主节点负责写入操作，从节点负责读取操作。
「数据一致性要求不同」：Kafka的副本之间的数据同步是异步进行的，即主题的分区数据在写入主节点后，可能会有一些延迟才被复制到副本。这种异步复制方式可以提高Kafka的吞吐量和性能，但可能导致副本之间存在一定的数据延迟。而MySQL的副本之间的数据同步是同步进行的，确保数据在主节点写入后立即被复制到所有副本，以保证数据的一致性和可用性。

Kafka只是一个消息引擎吗？

Kafka通常被描述为一个分布式流处理平台，而不仅仅是一个消息引擎。尽管Kafka的核心功能是消息引擎，它提供了高性能、可靠的分布式消息传递，但Kafka还具备其他重要的特性和功能，使其成为一个全面的分布式流处理平台。

如果你通读全篇文字但只能记住一句话，我希望你记住的就是这句。「再强调一遍，Kafka 是消息引擎系统，也是分布式流处理平台。」

Kafka发展史

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

「起初的需求」：在LinkedIn，存在一个需要处理大规模数据流的问题。传统的消息队列系统无法满足其高吞吐量和低延迟的需求。因此，Jay Kreps、Neha Narkhede和Jun Rao决定自行开发一种新的解决方案。
「项目开始」：2010年，Kafka项目正式启动。最初的目标是构建一个高性能的分布式提交日志系统，用于LinkedIn内部的数据管道和实时流式处理。
「发布开源」：2011年，LinkedIn将Kafka作为开源项目发布，成为Apache软件基金会的孵化项目。这使得更多的公司和开发者开始参与和贡献Kafka的发展。
「Kafka 0.8版本」：2012年，发布了Kafka的第一个重要版本0.8。该版本引入了新的存储层设计，使用分段日志（Segmented Log）来提高吞吐量和可靠性。此外，0.8版本还引入了新的消息消费模型（Consumer Model），支持多个消费者组和消息的持久化存储。
「Kafka 0.9版本」：2015年，发布了Kafka的0.9版本。这是一个重要的里程碑，引入了Kafka的新的消费者API，增强了安全性和可靠性。此外，0.9版本还引入了Kafka Connect和Kafka Streams，使Kafka成为一个全面的流处理平台。
「Kafka 1.0版本」：2017年，发布了Kafka的1.0版本。这是一个重要的稳定版本，引入了许多改进和性能优化。1.0版本还引入了幂等写入和事务支持等重要功能，使Kafka成为更可靠和全面的分布式流处理平台。

自那时以来，Kafka持续发展和改进，不断增加新的功能和特性。它已经成为一个广泛使用的分布式流处理平台，被许多公司和组织用于构建实时数据管道、事件驱动应用程序和大规模数据处理。

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

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

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

Kafka生态

Kafka有哪些版本？

「Apache Kafka」：这是Kafka的官方发行版，由Apache软件基金会进行维护和管理。Apache Kafka是一个开源项目，提供了稳定的版本和官方支持。
「Confluent Platform」：Confluent是一家专注于Kafka的公司，他们提供了Confluent Platform作为Kafka的一个企业级发行版。Confluent Platform在Apache Kafka的基础上扩展了一些企业级功能和工具，包括集成的Schema Registry、Kafka Connect、KSQL等。
「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版本演进

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