Kafka事务流由基础到实践

事件源，最终一致性，微服务，CQRS等等，这些越多越多的概念被现代开发者所熟悉。从细粒度的服务组装到复杂的以业务为中心的应用架构，这其中最重要的一块就是以中间件为基础的业务脱藕。本文我们介绍中间件基础构建块——事务流。其主导者是Apache Kafka，事实上的事务流平台标准，还会介绍Kafka的一个Web界面工具Kafdrop。

概述

事务流平台属于更广泛的面向消息的中间件(MoM)类，与传统的消息队列和主题类似，但是由于日志结构的不变性，它提供了更强大的时间保证和大幅度性能提高。简而言之，由于事务流的写操作只限于顺序追加，所以更加高效。

传统消息队列(MQ)中的消息往往是任意排序的，并且通常彼此独立，而流中的事务(或记录)往往是按时间顺序或因果关系排序的。而且，事务流会保留其记录，而MQ一旦读取了一条消息，就会丢弃它。因此，事务流往往更适合事件驱动的体系结构，包括事件源，最终一致性和CQRS等(当然，也包括FIFO消息队列，但是FIFO队列和成熟的事务流平台之间的差异非常大，而不仅限于订购)。

事务流平台是MoM领域中相对较新的范例。与数百种MQ风格的消息代理相比较，只有少数几种主流可用。与已建立的标准(例如AMQP，MQTT，XMPP和JMS)相比，事务流空间中还没有与之等效的标准。

事务流平台是当前持续研究和实验的活跃领域。但是，事务流平台不仅仅是一个商用产品，或者复杂的学术问题。它可以广泛应用于消息传递和事务场景，可用于例行性替换消息队列的传统使用场景。

架构概述

下图简要概述了Kafka组件体系结构。此处限于篇幅，我们不详细介绍Kafka内部工作原理。

kafka组成

Kafka是一个分布式系统，包含如下几个关键组件：

Broker(代理)节点：负责批量I/O操作和集群内的持续持久化。代理附加日志文件，这些文件中包含由集群托管的主题分区。可以在多个代理之间复制分区，以实现水平可伸缩性和增加的持久性，这些复制的分区被称为副本。有一个代理节点为控制节点(控制者)，其他副本受其管理(追随者)。一个代理节点会被选举为集群控制器，负责分区状态的内部管理，还负责仲裁给定分区的领导者跟随者角色。

ZooKeeper节点：在后台Kafka需要一种方法来管理集群中总体控制器状态。如果控制器出于某种原因退出，则有一个协议可以从剩余的代理集中选出另一个控制器。ZooKeeper很大程度上实现了控制器选举，心跳等的实际机制。ZooKeeper还充当各种配置存储库，维护集群元数据，领导者和跟随者状态，配额，用户信息，ACL和其他内部管理项目。由于底层的选举和共识协议，ZooKeeper节点的数量必须为奇数。

生产者：负责将消息发布到Kafka主题的客户端应用程序。由于Kafka具有日志结构的性质，并且能够在多消费者生态系统之间共享主题，因此只有生产者才能修改底层日志文件中的数据。实际I/O由代理节点代表生产者客户端执行。可以将任意数量生产者消息发布到同一Kafka主题，并选择用于保存记录的分区。

消费者：从主题读取消息的客户端应用程序。任意数量的消费者都可以从同一主题中阅读内容;但是，根据消费者的配置和分组，存在一些规则来管理消费者之间的记录分配。

分区，记录、偏移量和主题

分区是记录的完全有序序列，每一个分区对应一个append日志，这是Kafka的基础。每一条记录具有一个ID：64位整数偏移量和毫秒级的时间签。它可能会存在一个键和一个值。两者都是字节数组，并且都是可选的。术语"完全排序"仅表示对于任何给定的生产者，记录将按照应用程序发出的顺序进行写入。如果记录P在Q之前发布，则P将在分区中的Q之前。(假设P和Q共享一个分区。)此外，所有消费者将以相同的顺序读取它们。对于每个可能的消费者，将始终在Q之前读取P。在大多数用例中，这种订购保证至关重要。通常，已发布的记录将与某些现实事务相对应，并且保留这​​些事务的时间表通常是必不可少的。

记录的偏移量是分区中一条记录的唯一标识分。偏移量是稀疏地址空间中严格单调递增的整数，每个记录偏移量始终高于其上一个记录偏移量，并且相邻偏移量之间可能存在可变的间隙。如果启用了压缩或作为事务的结果，则必然会存在间隙，所以偏移量也有可能不是连续的。

应用程序不应尝试从字面上解释偏移量，也不应该猜测下一个偏移量是多少。但是，可以根据偏移量推断任何记录的相对顺序，按记录的偏移量对记录进行排序。

下图显示了内部分区的结构：

第一个偏移量(也称为low-water mark，低水位标记)是要显示给消费者的第一个消息。由于Kafka的保留期限制，因此不一定是第一个发布的消息。可以根据时间和/或分区大小来修剪记录。当有这种情况发生时，低水位线似乎会后移，早于低水位线的记录将被截断。

主题是分区的逻辑组成。一个主题可以具有一个或多个分区，而一个分区只能有一个主题或者一个主题的部分。主题是Kafka的基础，允许并行和负载平衡。前面我们说过分区显示总顺序。由于主题内的分区是相互独立的，因此称该主题具有部分顺序。简而言之，这意味着某些记录可以互相排序，而相对于某些其他记录则不可排序。总顺序和部分顺序的概念虽然听起来有些学术化，但在构建性能事务流管道中非常重要。它使我们能够在可能的地方并行处理记录，同时在必须的地方保持顺序。稍后，我们将探讨记录顺序，消费者并行性和主题大小的概念。

实例：消息发布

实践是检验真理的唯一标准，我将理论付诸实践，通过实例说明概念。我们将启动一对Docker容器，一个用Kafka容器，另一个为Kafdrop容器。我们使用Docker Compose方式启用容器。

在选定目录中创建一个docker-compose.yaml文件，内容如下：

为了方便起见，我们用obsidiandynamics/kafka镜像，它会将Kafka和ZooKeeper巧妙地打包在一个镜像中。然后通过docker-compose up启动容器。启动成功后，可以通过浏览器中访问localhost:9000，就能看到Kafdrop登陆界面。

实例中是一个单代理集群，还没有任何主题。我们可以使用Kafka的命令行工具创建一个主题并发布一些消息。我们可以使用docker exec工具对kafka容器进行操作方便地调用内置的CLI工具：

docker exec -it kafka-kafdrop_kafka_1 bash

上面的命令将让我么进入容器的shell命令行界面。工具位于/opt/kafka/bin目录中，cd进入该目录：

创建一个名为streams-intro的主题，其中包含3个分区：

切换回Kafdrop界面，现在我们就能在列表中看到新主创建的主题。

接着，我们可以使用kafka-console-producer工具发布消息：

注意：kafka-topics使用--bootstrap-server参数来配置Kafka代理列表，而kafka-console-producer则使用--broker-list。

记录由换行符分隔。键和值部分由冒号分隔，如key.separator属性所指示。本例下，我们可以输入下内容：

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!