kafka学习笔记（一）简介

最新推荐文章于 2023-11-10 14:47:10 发布

每天进步一奈奈

最新推荐文章于 2023-11-10 14:47:10 发布

阅读量822

点赞数 2

分类专栏： kafka 文章标签： kafka

本文链接：https://blog.csdn.net/haogenmin/article/details/108780318

版权

kafka 专栏收录该内容

10 篇文章 3 订阅

订阅专栏

这是对我找到的学习资料的整理，非手打

参考：

https://kafka.apachecn.org/intro.html

https://blog.csdn.net/weixin_39468305/article/details/106346280

Geo-Replication(地域复制)

Kafka是什么

Kafka是Apache旗下的一款分布式流处理平台，Kafka是一种高吞吐量、持久性、分布式的发布订阅的消息队列系统。它可以处理消费者规模的网站中的所有动作流数据。

流处理平台有以下三种特性:

可以让你发布和订阅流式的记录。这一方面与消息队列或者企业消息系统类似。
可以储存流式的记录，并且有较好的容错性。
可以在流式记录产生时就进行处理。

Kafka适合什么样的场景?

它可以用于两大类别的应用:

构造实时流数据管道，它可以在系统或应用之间可靠地获取数据。 (相当于message queue)
构建实时流式应用程序，对这些流数据进行转换或者影响。 (就是流处理，通过kafka stream topic和topic之间内部进行变化)

一些概念:

Kafka作为一个集群，运行在一台或者多台服务器上.
Kafka 通过 topic 对存储的流数据进行分类。
每条记录中包含一个key，一个value和一个timestamp（时间戳）。

消息系统分类

Peer-to-Peer (Queue)

简单来说就是生产者（Producer）发送消息到队列，消费者（Consumer）从队列中取出消息。这种模型的特点就是一条消息只会被一个消费者接收，一但有消费者消费了这条消息，其他消费者就没办法重复消费了。

名词解释：
Producer=生产者
Queue=队列
Consumer=消费者

消息生产者Producer生产消息到Queue，然后Consumer从Queue中取出并且消费消息。
消息被消费后，Queue将不再存储消息，其它所有Consumer不可能消费到已经被其它Consumer消费过的消息。
Queue支持存在多个Producer，但是对一条消息而言，只会有一个Consumer可以消费，其它Consumer则不能再次消费。
Consumer不存在时，消息则由Queue一直保存，直到有Consumer把它消费。

Publish/Subscribe（Topic）发布-订阅消息系统

发布订阅的模型也比较好理解，首先消费者需要订阅这个队列（主题），生产者只要发送一条消息到队列中，所有已订阅该队列的的消费者都能接收到该消息，未订阅的用户则无法接收。就像我们的微信关注微信公众号一样，只有关注了的用户才会收到公众号推送的消息。这里生产者也可以很多个。

Kafka原理详解插图(1)

名词解释：
Publisher=发布者
Topic=主题
Subscriber=订阅者

Publish/Subscribe模式工作原理：

消息发布者Publisher将消息发布到主题Topic中，同时有多个消息消费者Subscriber消费该消息。
和PTP方式不同，发布到Topic的消息会被所有订阅者消费。
当发布者发布消息，不管是否有订阅者，都不会报错信息。
一定要先有消息发布者，后有消息订阅者。

Kafka所采用的就是发布/订阅模式，被称为一种高吞吐量、持久性、分布式的发布订阅的消息队列系统。

Kafka原理

Kafka的三大特点

Kafka的几个名词

producer：生产者。
consumer：消费者。
topic: 消息以topic为类别记录,Kafka将消息种子(Feed)分门别类,每一类的消息称之为一个主题(Topic)。
broker：以集群的方式运行,可以由一个或多个服务组成，每个服务叫做一个broker;消费者可以订阅一个或多个主题(topic),并从Broker拉数据,从而消费这些已发布的消息。
message：每个消息（也叫作record记录,也被称为消息）是由一个key，一个value和时间戳构成。

Kafka的四个核心API

在Kafka中，客户端和服务器使用一个简单、高性能、支持多语言的 TCP 协议.此协议版本化并且向下兼容老版本，我们为Kafka提供了Java客户端，也支持许多其他语言的客户端。

Kafka有四个核心的API:

The Producer API 允许一个应用程序发布一串流式的数据到一个或者多个Kafka topic。
The Consumer API 允许一个应用程序订阅一个或多个 topic ，并且对发布给他们的流式数据进行处理。
The Streams API 允许一个应用程序作为一个流处理器，消费一个或者多个topic产生的输入流，然后生产一个输出流到一个或多个topic中去，在输入输出流中进行有效的转换。
The Connector API 允许构建并运行可重用的生产者或者消费者，将Kafka topics连接到已存在的应用程序或者数据系统。比如，连接到一个关系型数据库，捕捉表（table）的所有变更内容。

Kafka架构

Producer：消息和数据的生产者，主要负责生产Push消息到指定Broker的Topic中。
Broker：Kafka节点就是被称为Broker，Broker主要负责创建Topic，存储Producer所发布的消息，记录消息处理的过程，现是将消息保存到内存中，然后持久化到磁盘。
Topic：同一个Topic的消息可以分布在一个或多个Broker上，一个Topic包含一个或者多个Partition分区，数据被存储在多个Partition中。
replication-factor：复制因子；这个名词在上图中从未出现，在我们下一章节创建Topic时会指定该选项，意思为创建当前的Topic是否需要副本，如果在创建Topic时将此值设置为1的话，代表整个Topic在Kafka中只有一份，该复制因子数量建议与Broker节点数量一致。
Partition：分区；在这里被称为Topic物理上的分组，一个Topic在Broker中被分为1个或者多个Partition，也可以说为每个Topic包含一个或多个Partition，分区在创建Topic的时候可以指定。分区才是真正存储数据的单元。
Consumer：消息和数据的消费者，主要负责主动到已订阅的Topic中拉取消息并消费，为什么Consumer不能像Producer一样的由Broker去push数据呢？因为Broker不知道Consumer能够消费多少，如果push消息数据量过多，会造成消息阻塞，而由Consumer去主动pull数据的话，Consumer可以根据自己的处理情况去pull消息数据，消费完多少消息再次去取。这样就不会造成Consumer本身已经拿到的数据成为阻塞状态。
ZooKeeper：ZooKeeper负责维护整个Kafka集群的状态，存储Kafka各个节点的信息及状态，实现Kafka集群的高可用，协调Kafka的工作内容。

我们可以看到上图，Broker和Consumer有使用到ZooKeeper，而Producer并没有使用到ZooKeeper，因为Kafka从0.8版本开始，Producer并不需要根据ZooKeeper来获取集群状态，而是在配置中指定多个Broker节点进行发送消息，同时跟指定的Broker建立连接，来从该Broker中获取集群的状态信息，这是Producer可以知道集群中有多少个Broker是否在存活状态，每个Broker上的Topic有多少个Partition，Prodocuer会讲这些元信息存储到Producuer的内存中。如果Producoer像集群中的一台Broker节点发送信息超时等故障，Producer会主动刷新该内存中的元信息，以获取当前Broker集群中的最新状态，转而把信息发送给当前可用的Broker，当然Prodocuer也可以在配置中指定周期性的去刷新Broker的元信息以更新到内存中。

注意：只有Broker和ZooKeeper才是服务，而Producer和Consumer只是Kafka的SDK

主题和日志

让我们首先深入了解下Kafka的核心概念:提供一串流式的记录— topic 。

Topic 就是数据主题，是数据记录发布的地方,可以用来区分业务系统。Kafka中的Topics总是多订阅者模式，一个topic可以拥有一个或者多个消费者来订阅它的数据。

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

每个分区都是有序且顺序不可变的记录集，并且不断地追加到结构化的commit log文件。分区中的每一个记录都会分配一个id号来表示顺序，我们称之为offset，offset用来唯一的标识分区中每一条记录，每个分区的数据是不同的，但是每个分区可以有副本。

Kafka 集群保留所有发布的记录—无论他们是否已被消费—并通过一个可配置的参数——保留期限来控制. 举个例子，如果保留策略设置为2天，一条记录发布后两天内，可以随时被消费，两天过后这条记录会被抛弃并释放磁盘空间。Kafka的性能和数据大小无关，所以长时间存储数据没有什么问题.

Kafka原理详解插图(5)

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

这些细节说明Kafka 消费者是非常廉价的—消费者的增加和减少，对集群或者其他消费者没有多大的影响。比如，你可以使用命令行工具，对一些topic内容执行 tail操作，并不会影响已存在的消费者消费数据。

日志中的 partition（分区）有以下几个用途。第一，当日志大小超过了单台服务器的限制，允许日志进行扩展。每个单独的分区都必须受限于主机的文件限制，不过一个主题可能有多个分区，因此可以处理无限量的数据。第二，可以作为并行的单元集。

分区

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

每个分区都有一台 server 作为 “leader”，零台或者多台server作为 follwers 。leader server 处理一切对 partition （分区）的读写请求，而follwers只需被动的同步leader上的数据。当leader宕机了，followers 中的一台服务器会自动成为新的 leader。每台 server 都会成为某些分区的 leader 和某些分区的 follower，因此集群的负载是平衡的。

每个partition对应于一个文件夹，该文件夹下存储该partition的数据和索引文件。

比如上面TEST_HGM是我们定义的主题，这个主题有三个分区，复制因子是二。

第一张图那个TEST_HGM-1 和TEST_HGM-2是在第二台主机上面，这台主机是分区二的leader，分区1的备份。分区文件内容如下，数据文件，索引文件等。

每个partition内部保证消息的顺序。但是分区之间是不保证顺序的。如果想要让某一类数据按顺序处理，一般我们需要按表+主键来分区。保证同一主键的数据发送到同一个分区中。如果你想要 kafka 中的所有数据都按照时间的先后顺序进行存储，那么可以设置分区数为 1。

注意：每个Partition分区都有一个"leader"(领导者)服务器，是每个Partition分区，例如我们以上的拓扑结构中，Topic1是包含两个分区的Partition1和Partition2，这两个分区的内容是不同的，目的就是上面说的，第一可以不受限的处理更多的数据。第二，分区可以作为并行处理的单元。然后Partition1和Partition2各有两个备份在别的主机上，这两个分区每个都有三份，各自的三份之间的内容是完全相同的，其中一个是leader(领导者)，剩余两个是followers(追随者)。这样做是为了高可用。上面说的共享意思是，每个topic的不同分区只有leader是处理请求的，此时这个topic的leader是被所有服务器节点共享的，客户端对集群中这个topic的特定分区的leader的请求，都会转到leader所在的服务节点上。

我们上面讲的leader和follower仅仅是每个Partition分区的领导者和追随者，并不是我们之前学习到的整个集群的主节点和备节点，希望大家不要混淆。

Geo-Replication(地域复制)

Kafka Mirrormaker为集群提供地域复制支持，使用MirrorMaker，可以跨多个机房或云端来复制数据，可以在主动/被动方案中使用它进行备份和恢复；在主动方案中，可以使数据更接近用户，或支持数据位置要求。

Producers(生产者)

生产者可以将数据发布到所选择的topic（主题）中。生产者负责将记录分配到topic的哪一个 partition（分区）中。可以使用循环的方式来简单地实现负载均衡，也可以根据某些语义分区函数(例如：记录中的key)来完成。

Producer分为Sync Producer 和 Aync Producer。

Sync Producer同步的生产者，即一定要某条消息成功才会发送下一条。所以它是低吞吐率、一般不会出现数据丢失。
Aync Producer异步的生产者，有个队列的概念，是直接发送到队列里面，批量发送。高吞吐率、可能有数据丢失的。

Consumers(消费者)

消费者使用一个 消费组 名称来进行标识，发布到topic中的每条记录被分配给订阅消费组中的一个消费者实例.消费者实例可以分布在多个进程中或者多个机器上。

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

如果所有的消费者实例在不同的消费组中，每条消息记录会广播到所有的消费者进程.

如图，这个 Kafka 集群有两台 server 的，四个分区(p0-p3)和两个消费者组。消费组A有两个消费者，消费组B有四个消费者。

通常情况下，每个 topic 都会有一些消费组，一个消费组对应一个"逻辑订阅者"。一个消费组由许多消费者实例组成，便于扩展和容错。这就是发布和订阅的概念，只不过订阅者是一组消费者而不是单个的进程。

在Kafka中实现消费的方式是将日志中的分区划分到每一个消费者实例上，以便在任何时间，每个实例都是分区唯一的消费者。维护消费组中的消费关系由Kafka协议动态处理。如果新的实例加入组，他们将从组中其他成员处接管一些 partition 分区;如果一个实例消失，拥有的分区将被分发到剩余的实例。

Kafka 只保证分区内的记录是有序的，而不保证主题中不同分区的顺序。每个 partition 分区按照key值排序足以满足大多数应用程序的需求。但如果你需要总记录在所有记录的上面，可使用仅有一个分区的主题来实现，这意味着每个消费者组只有一个消费者进程。

Consumer Group

我们开始处有讲到消息系统分类：P-T-P模式和发布/订阅模式，也有说到我们的Kafka采用的就是发布订阅模式，即一个消息产生者产生消息到Topic中，所有的消费者都可以消费到该条消息，采用异步模型；而P-T-P则是一个消息生产者生产的消息发不到Queue中，只能被一个消息消费者所消费，采用同步模型
其实发布订阅模式也可以实现P-T-P的模式，即将多个消费者加入一个消费者组中，例如有三个消费者组，每个组中有3个消息消费者实例，也就是共有9个消费者实例，如果当Topic中有消息要接收的时候，三个消费者组都会去接收消息，但是每个人都接收一条消息，然后消费者组再将这条消息发送给本组内的一个消费者实例，而不是所有消费者实例，到最后也就是只有三个消费者实例得到了这条消息，当然我们也可以将这些消费者只加入一个消费者组，这样就只有一个消费者能够获得到消息了。

Zookeeper

zookeeper目前在kafka中扮演着举重轻重的角色和作用~是kafka不可缺少的一个组件。目前，Apache Kafka 使用 Apache ZooKeeper 来存储它的元数据，比如brokers信息、分区的位置和主题的配置等数据就是存储在 ZooKeeper 集群中。

在 2019 年社区提出了一个计划，以打破这种依赖关系，并将元数据管理引入 Kafka 本身。因为拥有两个系统会导致大量的重复。

在之前的设计中，我们至少需要运行三个额外的 Java 进程，有时甚至更多。事实上，我们经常看到具有与 Kafka 节点一样多的 ZooKeeper 节点的 Kafka 集群！此外，ZooKeeper 中的数据还需要缓存在 Kafka 控制器上，这导致了双重缓存。

更糟糕的是，在外部存储元数据限制了 Kafka 的可伸缩性。当 Kafka 集群启动时，或者一个新的控制器被选中时，控制器必须从 ZooKeeper 加载集群的完整状态。随着元数据数量的增加，加载过程需要的时间也会增加，这限制了 Kafka 可以存储的分区数量。

最后，将元数据存储在外部会增加控制器的内存状态与外部状态不同步的可能性。

因此，未来，Kafka 的元数据将存储在 Kafka 本身中，而不是存储在 ZooKeeper 之类的外部系统中。可以持续关注kafka社区动态哦！

kafka原理总结

通常来讲，消息模型可以分为两种：队列和发布-订阅式。队列的处理方式是一组消费者从服务器读取消息，一条消息只有其中的一个消费者来处理。在发布-订阅模型中，消息被广播给所有的消费者，接收到消息的消费者都可以处理此消息。Kafka为这两种模型提供了单一的消费者抽象模型：消费者组(consumer group)。消费者用一个消费者组名标记自己。

一个发布在Topic上消息被分发给此消费者组中的一个消费者。假如所有的消费者都在一个组中，那么这就变成了queue模型。假如所有的消费者都在不同的组中，那么就完全变成了发布-订阅模型。更通用的，我们可以创建一些消费者组作为逻辑上的订阅者。每个组包含数目不等的消费者，一个组内多个消费者可以用来扩展性能和容错。

并且，kafka能够保证生产者发送到一个特定的Topic的分区上，消息将会按照它们发送的顺序依次加入，也就是说，如果一个消息M1和M2使用相同的producer发送，M1先发送，那么M1将比M2的offset低，并且优先的出现在日志中。消费者收到的消息也是此顺序。如果一个Topic配置了复制因子（replication facto）为N,那么可以允许N-1服务器宕机而不丢失任何已经提交（committed）的消息。此特性说明kafka有比传统的消息系统更强的顺序保证。但是，相同的消费者组中不能有比分区更多的消费者，否则多出的消费者一直处于空等待，不会收到消息。

Kafka 作为消息系统

Kafka streams的概念与传统的企业消息系统相比如何？

传统的消息系统有两个模块: 队列和发布-订阅。在队列中，消费者池从server读取数据，每条记录被池子中的一个消费者消费; 在发布订阅中，记录被广播到所有的消费者。两者均有优缺点。队列的优点在于它允许你将处理数据的过程分给多个消费者实例，使你可以扩展处理过程。不好的是，队列不是多订阅者模式的—一旦一个进程读取了数据，数据就会被丢弃。而发布-订阅系统允许你广播数据到多个进程，但是无法进行扩展处理，因为每条消息都会发送给所有的订阅者。

消费组在Kafka有两层概念。在队列中，消费组允许你将处理过程分发给一系列进程(消费组中的成员)。在发布订阅中，Kafka允许你将消息广播给多个消费组。

Kafka的优势在于每个topic都有以下特性—可以扩展处理并且允许多订阅者模式—不需要只选择其中一个.

Kafka相比于传统消息队列还具有更严格的顺序保证

传统队列在服务器上保存有序的记录，如果多个消费者消费队列中的数据，服务器将按照存储顺序输出记录。虽然服务器按顺序输出记录，但是记录被异步传递给消费者，因此记录可能会无序的到达不同的消费者。这意味着在并行消耗的情况下，记录的顺序是丢失的。因此消息系统通常使用“唯一消费者”的概念，即只让一个进程从队列中消费，但这就意味着不能够并行地处理数据。

Kafka 设计的更好。topic中的partition是一个并行的概念。 Kafka能够为一个消费者池提供顺序保证和负载平衡，是通过将topic中的partition分配给消费者组中的消费者来实现的，以便每个分区由消费组中的一个消费者消耗。通过这样，我们能够确保消费者是该分区的唯一读者，并按顺序消费数据。众多分区保证了多个消费者实例间的负载均衡。但请注意，消费者组中的消费者实例个数不能超过分区的数量。