Kafka基本介绍

最新推荐文章于 2024-08-25 23:59:28 发布

托塔天王李

最新推荐文章于 2024-08-25 23:59:28 发布

阅读量964

点赞数

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

本文链接：https://blog.csdn.net/qq_40861391/article/details/107676499

版权

Kafka 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

Kafka介绍

Kafka是分布式发布-订阅消息系统。它最初由LinkedIn公司开发，之后成为Apache项目的一部分。Kafka是一个分布式的，可划分的，冗余备份的持久性的日志服务。它主要用于处理活跃的流式数据。

Kafka架构

在这里插入图片描述
整个架构中有三个角色：

生产者（Producer）：消息和数据的生产者
代理（Broker）:已发布的消息保存在一组服务器中，称之为Kafka集群。集群中的每一个服务器都是一个代理（Broker）
消费者（Consumer)：消息和数据的消费者

Kafka概念介绍

1. Broker

broker 指一个 kafka 服务器
多个 broker 依靠 Zookeeper 集群进行服务的协调管理
生产者发送消息给 Kafka 服务器
消费者从 Kafka 服务器读取消息

2. Topic

topic 只是一个逻辑概念，代表了一类消息，可以使用 topic 来区分实际业务，比如业务A使用一个 topic ，业务B使用另外一个 topic。
topic 可以被多个消费者订阅
每条消息属于且仅属于一个 topic
Producer 发布数据时，必须指定将该消息发布到哪个 topic
Consumer 订阅消息时，也必须指定订阅哪个 topic 的信息
一个 Topic 包含一个或多个 Partition

3. Partition

partition 是不可修改的有序消息序列，也可以说是有序的消息日志
partition 的引入是为了提升系统的吞吐量，因此在创建 Kafka topic 的时候可以根据集群实际配置设置具体的 partition 数，实现整体性能的最大化。
物理上每个 partition 对应的是一个目录，目录名为 topic 名称 + 有序序号，例如名为test的topic下创建了三个 partition，三个分区在 /tmp/kafka-logs 下的目录名分别为 test-01、test-02、test-03。
一个 topic 下的多个 partition 可以分布在多台 broker 上，也可以在一台 broker 上。
每个 partition 都有一个为 leader，负责读写，其余的相对备份机为 follower，follower 同步 leader 数据，负责 leader 死了之后的接管。n 个 leader 均衡的分散在每个 broker 上。
每个 partition 包含多个 segment 文件，segment 是消息存储的真实文件，会不断生成新的。

4. offset（位移）

topic partition 下的每条消息都被分配一个位移值。实际上 Kafka 消费者端也有位移（ offset ）的概念，但一定要注意这两个 offset 属于不同的概念，如图：

在这里插入图片描述

5. replica（副本）

副本复制机制
partition 可以有多个副本，否则一旦保存 partition 的broker挂掉了，其上保存的消息也就都丢失了。
副本分为领导者副本（ leader replica ）和追随者副本（ follower replica ）。follower replica 是不能提供服务给客户端的，也就是说不负责响应客户端发来的消息写入和消息消费请求。它只是被动地向领导者副本（ leader replica ）获取数据，而一旦 leader replica 所在的broker 岩机， Kafka 会从剩余的 replica 中选举出新的 leader 续提供服务。

6. leader 和 follower

如前所述， Kafka replica 分为两个角色：领导者（ leader ）和追随者（ follower ).。和传统主备系统（比如MySQL ）不同的是，在这类 leader-follower 系统中通常只有 leader 对外提供服务， follower 是被动地追随 leader 的状态，保持与 leader 的同步。 follower 存在的唯一价值就是充当 leader 的候补：一旦 leader 挂掉立即就会有一个追随者被选举成为新的 leader 接替它的工作。

7. ISR

ISR 全称是 in-sync replica ，翻译过来就是与 leader replica 保持同步的 replica 集合。前面讲了一个 partition 可以配置 N 个 replica ，那么这是否就意味着该 partition 可以容忍 N-1 个 replica 失效而不丢失数据呢？答案是“否”！
　　Kafka partition 动态维护 replica 集合。该集合中的所有 replica 保存的消息日志都与leader replica 保持同步状态。只有这个集合中的 replica 才能被选举为 leader ，也只有该集合中所有 replica 都接收到了同一条消息， Kafka 才会将该消息置于“己提交”状态，即认为这条消息发送成功。回到刚才的问题， Kafka 承诺只要这个集合中至少存在一个 replica ，那些“己提交”状态的消息就不会丢失一一记住这句话的两个关键点：（1）ISR 中至少存在一个“活着的” replica；（2）”已提交“的消息。Kafka 对于没有提交成功的消息不做任何交付保证，它只保证在 ISR 存活的情况下“己提交”的消息不会丢失。
　　正常情况下， partition 的所有 replica （含 leader replica ）都应该与 leader replica 保持同步，即所有 replica 都在 ISR 中。因为各种各样的原因，一小部分 replica 开始落后于 leaderreplica 的进度。当滞后一定程度时， Kafka 会将这些 replica “踢”出 ISR 。相反地，当这些 replica 重新“追上”了 leader 进度时那么 Kafka 会将它们加回到 ISR 中。这一切都是自动维护的，不需要用户进行人工干预，因而在保证了消息交付语义的同时还简化了用户的操作成本。

8. Producers(生产者)

生产者往某个Topic上发布消息。生产者也负责选择发布到Topic上的哪一个分区。最简单的方式从分区列表中轮流选择。也可以根据某种算法依照权重选择分区。开发者负责如何选择分区的算法。

9. Consumers(消费者)

通常来讲，消息模型可以分为两种，队列和发布-订阅式。队列的处理方式是一组消费者从服务器读取消息，一条消息只有其中的一个消费者来处理。在发布-订阅模型中，消息被广播给所有的消费者，接收到消息的消费者都可以处理此消息。Kafka为这两种模型提供了单一的消费者抽象模型：消费者组（consumer group）。消费者用一个消费者组名标记自己。一个发布在Topic上消息被分发给此消费者组中的一个消费者。假如所有的消费者都在一个组中，那么这就变成了queue模型。假如所有的消费者都在不同的组中，那么就完全变成了发布-订阅模型。更通用的，我们可以创建一些消费者组作为逻辑上的订阅者。每个组包含数目不等的消费者，一个组内多个消费者可以用来扩展性能和容错。正如下图所示：
在这里插入图片描述
2个kafka集群托管4个分区（P0-P3），2个消费者组，消费组A有2个消费者实例，消费组B有4个。
正像传统的消息系统一样，Kafka保证消息的顺序不变。再详细扯几句。传统的队列模型保持消息，并且保证它们的先后顺序不变。但是，尽管服务器保证了消息的顺序，消息还是异步的发送给各个消费者，消费者收到消息的先后顺序不能保证了。这也意味着并行消费将不能保证消息的先后顺序。用过传统的消息系统的同学肯定清楚，消息的顺序处理很让人头痛。如果只让一个消费者处理消息，又违背了并行处理的初衷。在这一点上Kafka做的更好，尽管并没有完全解决上述问题。 Kafka采用了一种分而治之的策略：分区。因为Topic分区中消息只能由消费者组中的唯一一个消费者处理，所以消息肯定是按照先后顺序进行处理的。但是它也仅仅是保证Topic的一个分区顺序处理，不能保证跨分区的消息先后处理顺序。所以，如果你想要顺序的处理Topic的所有消息，那就只提供一个分区。

Kafka优点

1. 解耦

在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。

2. 冗余（副本）

有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。