Kafka 系列学习笔记（一）介绍

之前在学习 fabric 有关内容的时候，就了解到在 fabric 中的 orderer 节点中是需要借助 kafka 进行消息序列排序的，而且在现在，很多做架构的都在使用 kafka 。今天有时间来看一下，看一看到底 kafka 有多强大。

基本概念

首先我们要了解的是 kafak 的一些基本概念，在官方文档中，他提及到三点：

kafka 作为一个集群，是运行在一台或者多台服务器上的。
kafka 通过 topic 对存储的流数据进行分类。
每条记录当中都包含一个 key，一个 value 和一个 timestamp。

核心 API

[外链图片转存失败(img-pLb4XQOz-1564196555545)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1564189338856.png)]

在 kafka 当中有主要四个 API，我们分别来说一下：

The Producer API 允许一个 App 发布一串流式的数据到一个或者多个 kafka topic 中；
The Consumer API 允许一个 App 订阅一个或者多个 topic，并且对发布给他们的流式数据进行处理；
The Streams API 允许一个 App 作为一个 流处理器 消费一个或者多个 topic 产生的输入流，然后产生一个输出流到一个或多个 topic 中去，在输入输出流中进行有效的转换。
The Connector API 允许构建并运行可重用的生产者和消费者，将 kafka topics 连接到已存在的 App 或者 Ddata System 中，比如可以连接到一个 key-value DataBase中，然后就可以捕捉表中所有变更的内容。

在这里面，我们应该始终记得，topic 是始终存在于 kafka cluster 中的。

在 kafka 中，客户端和服务器均使用的是一个简单、高性能、支持多语言的 TCP协议。而且， kafka 提供了多种语言的客户端，对于 Go 语言，kafka 也提供了很多的参考。

Topic 和日志

现在我们来说一下 kafka 的核心概念： topic

Topic 就是数据的主题，是数据记录以及发布的地方，可以用来区分业务系统。kafka 中的 Topics 总是多订阅者模式，也就是说一个 topic 可以拥有一个或者多个消费者来订阅它的数据。这一点在前面的主要特征和 API 中都有提到过。

对于每一个 topic，kafka 都会维持一个分区日志，如下图所示：

[外链图片转存失败(img-1Pw0j5ff-1564196555546)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1564192910763.png)]

每个分区都是有序的，并且顺序不可变（感觉和区块链中的交易很像），而且还会不断地追加到结构化的 commit log 文件中。分区的每一个记录都会分配一个 id 号来表示顺序，称之为 offset，这个 offset 用来标识分区中的每一条记录。

kafka 在集群中保留所有发布的记录，并通过一个可以配置的参数来控制其保留的期限。也就说，如果我们将时间参数设置为2天，那么我们在这两天内可以随时消费这几条数据，但一旦过了两天之后，这条记录则会被丢弃并且释放磁盘空间。而 kafka 本身是和数据大小无关的，因此 kafka 对于数据存储的时间是没有什么明确限制的。

事实上，在每一个消费者中唯一保存的元数据是 offset 量，也就是消费在日志中的位置。而这个偏移量是由消费者所控制的：通常在读取记录后，消费者会以线性的方式增加偏移量，但是实际上，由于这个位置由消费者控制，所以消费者可以采用任何顺序来消费记录。例如，一个消费者可以重置到一个旧的偏移量，从而重新处理过去的数据；也可以跳过最近的记录，从"现在"开始消费。

而这一点也同样说明消费者的增加和减少是对集群或者其他消费者来说没有太大影响的。比如，你可以使用命令行工具，对一些 topic 内容执行 tail 操作，并不会影响已存在的消费者消费数据。

在日志当中还有一个 partition ，这个 partition 有以下几个用途：

第一，当日志大小超过了单台服务器的限制时，就会允许日志进行扩展。但每个单独的分区又受限于主机的文件限制，不过一个主题可能会有多个分区，因此可以处理无限量的数据。
第二，partition 可以作为并行的单元集来这行，这也是我们下一点要说到的。

分布式

日志在经过分区后是分布在 Kafka 集群的服务器上的。每个服务器在处理数据和请求时，都会共享这些分区。而每一个分区都会在已配置的服务器上进行备份，以确保容错性。

在每个分区中都有一台 server 作为整个分区的 leader，而与 leader 相对应的 follower 的个数是从 $0~m$ 间任取的。 leader 负责处理对 partition 的读写请求，而 followers 只需要被动的同步 leader 上的数据即可。当 leader 发生故障，followers 中的一台服务器将会自动成为新的 leader。而对于 leader 和 follower 的选择来说，每一台 server 的成为 server 和 follower 的可能性是相等的，因此集群的负载是平衡的。

生产者与消费者

生产者可以将数据发布到所选择的 topic 当中。而消费者则使用一个 消费组 名称来进行标识，发布到 topic 中的每条记录将被分配给订阅消费组中的消费者。而消费者可以分布在多个进程中或者多个机器上。

如果所有的消费者实例在同一消费组中，消息记录会负载平衡到每一个消费者实例。

但如果所有的消费者是存在于不同的消费组中的，每条消息记录将会广播到所有的消费者进程。

[外链图片转存失败(img-puJh5MKJ-1564196555546)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1564195257944.png)]

在这里要声明一点的是，前面所提到的订阅者的概念，并不是针对某一个消费者而言的，更通俗的说，这个订阅者是针对整个消费组而言的。

在 Kafka 中实现消费的方式是将日志中的分区划分到每一个消费者实例上，这样以便在任何时间，每个实例都是分区唯一的消费者。维护消费组中的消费关系由 Kafka 协议动态处理。如果新的实例加入组，他们将从组中其他成员处接管一些 partition 分区;如果一个实例消失，拥有的分区将被分发到剩余的实例。但同时还要注意，Kafka 只保证分区内的记录是有序的，而不保证主题中不同分区的顺序。

保证

kafka 整体将给予以下几点保证：

生产者发送到特定 topic partition 的消息将按照发送的顺序处理。
一个消费者实例按照日志中的顺序查看记录。
对于具有 N 个副本的主题，我们最多容忍 N-1 个服务器故障，从而保证不会丢失任何提交到日志中的记录.

kafka 作为存储系统

许多消息队列可以发布消息，除了消费消息之外还可以充当中间数据的存储系统。那么 Kafka 作为一个优秀的存储系统有什么不同呢? 数据写入 Kafka 后被写到磁盘，并且进行备份以便容错。直到完全备份，Kafka 才让生产者认为完成写入，即使写入失败 Kafka 也会确保继续写入。而且 Kafka 使用磁盘结构，具有很好的扩展性— 50kb 和 50TB 的数据在 server 上表现是一致的。

正如官方文档所述：kafka 可以存储大量数据，并且可通过客户端控制它读取数据的位置，您可认为 Kafka 是一种高性能、低延迟、具备日志存储、备份和传播功能的分布式文件系统。