Kafka详解

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

文章目录

• 前言
• 一、Kafka详解
• • [什么是 Producer、Consumer、Broker、Topic、 Partition？](#什么是 Producer、Consumer、Broker、Topic、 Partition？)
  • 高性能，高扩展性，高可用
  • 高扩展性
  • [kafka 的应用场景](#kafka 的应用场景)
  • [1.5 部署kafka集群](#1.5 部署kafka集群)
• 总结

---

前言

一、Kafka详解

1.1 Kafka定义

Kafka（传统）分布式的基于发布/订阅模式的消息队列（Message Queue） ，应用于大数据实时处理 领域。

（发布/订阅：消息的发布者不会将消息直接发布给特定的订阅者，而是将发布的消息分为不同的类别，订阅者只接收感兴趣的消息。）

Kafka最新定义：Kafka是一个开源的分布式事件流平台（Event Streaming Platform），被数千家公司用于高性能的数据管道、流分析、数据集成和关键任务应用。

Kafka是一个分布式的基于发布/订阅模式的消息队列（MQ，Message Queue），主要应用于大数据实时处理领域。

3.2 Kafka简介

Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于Zookeeper协调的分布式消息中间件系统。它的最大的特性就是可以实时的处理大量数据以满足各种需求场景，比如基于hadoop的批处理系统、低延迟的实时系统、Spark/Flink流式处理引擎，nginx访问日志，消息服务等等。用scala语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。

3.3 Kafka的特性

高吞吐量、低延迟

Kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒。每个topic可以分多个Partition，Consumer Group对Partition进行消费操作，提高负载均衡能力和消费能力。

可扩展性

kafka集群支持热扩展。

持久性、可靠性

消息被持久化到本地磁盘，并且支持数据备份防止数据丢失。

容错性

允许集群中节点失败（多副本情况下，若副本数量为n，则允许n-1个节点失败）。

高并发

支持数千个客户端同时读写。

3.4 Kafka系统架构（重点）

3.4.1 Broker服务器

一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。

3.4.2 Topic主题

可以理解为一个队列，生产者和消费者面向的都是一个topic。类似于数据库的表名或者ES的index。物理上不同topic的消息分开存储。

3.4.3 Partition分区

为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，一个topic可以分割为一个或多个partition，每个partition是一个有序的队列。Kafka只保证partition内的记录是有序的，而不保证topic中不同partition的顺序。

每个topic至少有一个partition，当生产者产生数据的时候，会根据分配策略选择分区，然后将消息追加到指定的分区的队列末尾。

① Partation数据路由规则：

指定了patition，则直接使用；

未指定patition但指定key（相当于消息中某个属性），通过对key的value进行hash取模，选出一个patition；

patition和key都未指定，使用轮询选出一个patition。

每条消息都会有一个自增的编号，用于标识消息的偏移量，标识顺序从0开始。

每个partition中的数据使用多个segment文件存储。

如果topic有多个partition，消费数据时就不能保证数据的顺序。严格保证消息的消费顺序的场景下（例如商品秒杀、抢红包），需要将partition数目设为1。

broker存储topic的数据。如果某topic有N个partition，集群有N个broker，那么每个broker存储该topic的一个partition。

如果某topic有N个partition，集群有(N+M)个broker，那么其中有N个broker存储topic的一个partition，剩下的M个broker不存储该topic的partition数据。

如果某topic有N个partition，集群中broker数目少于N个，那么一个broker存储该topic的一个或多个partition。在实际生产环境中，尽量避免这种情况的发生，这种情况容易导致Kafka集群数据不均衡。

② 分区的原因

方便在集群中扩展，每个Partition可以通过调整以适应它所在的机器，而一个topic又可以有多个Partition组成，因此整个集群就可以适应任意大小的数据了；

可以提高并发，因为可以以Partition为单位读写了。

（1）Replica副本：为保证集群中的某个节点发生故障时，该节点上的partition数据不丢失，且kafka仍然能够继续工作，kafka提供了副本机制，一个topic的每个分区都有若干个副本，一个leader和若干个follower。

（2）Leader：每个partition有多个副本，其中有且仅有一个作为Leader，Leader是当前负责数据的读写的partition。

（3）Follower：Follower跟随Leader，所有写请求都通过Leader路由，数据变更会广播给所有Follower，Follower与Leader保持数据同步。Follower只负责备份，不负责数据的读写。

如果Leader故障，则从Follower中选举出一个新的Leader。

当Follower挂掉、卡住或者同步太慢，Leader会把这个Follower从ISR（Leader维护的一个和Leader保持同步的Follower集合）列表中删除，重新创建一个Follower。

3.4.4 Producer生产者

生产者即数据的发布者，该角色将消息push发布到Kafka的topic中。

broker接收到生产者发送的消息后，broker将该消息追加到当前用于追加数据的segment文件中。

生产者发送的消息，存储到一个partition中，生产者也可以指定数据存储的partition。

3.4.5 Consumer消费者

消费者可以从broker中pull拉取数据。消费者可以消费多个topic中的数据。

3.4.6 Consumer Group（CG）消费者组

消费者组，由多个consumer组成。

所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。可为每个消费者指定组名，若不指定组名则属于默认的组。

将多个消费者集中到一起去处理某一个Topic的数据，可以更快的提高数据的消费能力。

消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费，防止数据被重复读取。

消费者组之间互不影响。

3.4.7 Offset偏移量

可以唯一的标识一条消息。

偏移量决定读取数据的位置，不会有线程安全的问题，消费者通过偏移量来决定下次读取的消息（即消费位置）。

消息被消费之后，并不被马上删除，这样多个业务就可以重复使用Kafka的消息。

某一个业务也可以通过修改偏移量达到重新读取消息的目的，偏移量由用户控制。

消息最终还是会被删除的，默认生命周期为1周（7*24小时）。

3.4.8 Zookeeper

Kafka通过Zookeeper来存储集群的meta信息。

由于consumer在消费过程中可能会出现断电宕机等故障，consumer恢复后，需要从故障前的位置的继续消费，所以consumer需要实时记录自己消费到了哪个offset，以便故障恢复后继续消费。

Kafka 0.9版本之前，consumer默认将offset保存在Zookeeper中；从0.9版本开始，consumer默认将offset保存在Kafka一个内置的topic中，该topic为__consumer_offsets。

也就是说，zookeeper的作用就是，生产者push数据到kafka集群，就必须要找到kafka集群的节点在哪里，这些都是通过zookeeper去寻找的。消费者消费哪一条数据，也需要zookeeper的支持，从zookeeper获得offset，offset记录上一次消费的数据消费到哪里，这样就可以接着下一条数据进行消费。

在这里插入图片描述

3.4.9 简易版Kafka架构

Partition：分区

Consumer：消费者

brokers：服务器

producer：生产者

topic·消息主题，可以理解为一个队列，生产者和消费者面向的都是一个topic

Replica 副本:有多个副本，可以实现高可用副本中有两个角色：

Leader(负责读写)

Follower(复制备份)

offset 偏移量，记录消费者的位置，以及消费者数据的位置

Kafka基础架构

1、为方便扩展，并提高吞吐量，一个topic分为多个partition

2、配合分区的设计，提出消费者组的概念，组内每个消费者并行消费

3、为提高可用性，为每个partition增加若干副本，类似NameNode HA

4、ZK中记录谁是leader，Kafka2.8.0 以后也可以配置不采用ZK.

Producer：消息生产者，就是向Kafka broker 发消息的客户端。

Consumer：消息消费者，向Kafka broker 取消息的客户端。

Consumer Group（CG）：消费者组，由多个consumer组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。

Broker：一台Kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。

Topic： 可以理解为一个队列，生产者和消费者面向的都是一个topic。

Partition： 为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，一个topic可以分为多个partition，每个partition是一个有序的队列。

Replica：副本。一个topic的每个分区都有若干个副本，一个Leader和若干个Follower。

Leader：每个分区多个副本的 "主"，生产者发送数据的对象，以及消费者消费数据的对象都是Leader。

Follower：每个分区多个副本中的 "从"，实时从 Leader 中同步数据，保持和 Leader 数据的同步。Leader 发生故障时，某个Follower会成为新的 Leader。

Kafka 是一个分布式流式处理平台。

什么是 Producer、Consumer、Broker、Topic、 Partition？

Kafka 将生产者发布的消息发送到 Topic（主题）中，需要这些消息的消费者可以订阅这些 Topic（主题）。Kafka 比较重要的几个概念：

Producer（生产者）: 产生消息的一方。

Consumer（消费者）: 消费消息的一方。

Broker（代理）: 可以看作是一个独立的 Kafka 实例。多个 Kafka Broker 组成一个 Kafka Cluster。

Topic（主题）: Producer 将消息发送到特定的主题，Consumer 通过订阅特定的 Topic(主题)来消费消息。

Partition（分区）: Partition 属于 Topic 的一部分。一个 Topic 可以有多个 Partition ，并且同一 Topic 下的 Partition 可以分布在不同的 Broker 上，这也就表明一个 Topic 可以横跨多个 Broker 。

offset：（记录消息位置）

偏移量，记录消费者的位置，以及消费者数据的位置

单独的进程消息队列

（来不及处理的消息会堆积在内存里，如果 B 服务更新重启，这些消息就都丢了。

so将队列挪出来，变成一个单独的进程。就算 B 服务重启，也不会影响到了队列里的消息。）

Producer：消息生产者，就是向Kafka broker 发消息的客户端。
Consumer：消息消费者，向Kafka broker 取消息的客户端。

高性能，高扩展性，高可用

高性能：加消费者，加生产者，提升消息队列的吞吐量

B 服务由于性能较差，消息队列里会不断堆积数据，为了提升性能，我们可以扩展更多的消费者, 这样消费速度就上去了，相对的我们就可以增加更多生产者，提升消息队列的吞吐量。

同时争抢同一个消息队列，抢不到的一方就得等待

对消息进行分类，每一类是一个 topic，然后根据 topic 新增队列的数量，生产者将数据按 topic 投递到不同的队列中，消费者则根据需要订阅不同的 topic。这就大大降低了 topic 队列的压力。

**Topic主题： 可以理解为一个队列

Producer 将消息发送到特定的主题，Consumer 通过订阅特定的 Topic(主题)来消费消息

单个 topic 的消息还是可能过多，我们可以将单个队列，拆成好几段，每段就是一个 partition 分区，每个消费者负责一个 partition

Partition

Partition 属于 Topic 的一部分。为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，一个topic可以分为多个partition，每个partition是一个有序的队列。

高扩展性

Broker（代理） :

可以看作是一个独立的 Kafka 实例。多个 Kafka Broker 组成一个 Kafka Cluster。

partition 变多，如果 partition 都在同一台机器上的话，就会导致单机 cpu 和内存过高，影响整体系统性能。

申请更多的机器，将 partition 分散部署在多台机器上，这每一台机器，就代表一个 broker。我们可以通过增加 broker 缓解机器 cpu 过高带来的性能问题

partition 多加几个副本，也就是 replicas，将它们分为 Leader 和 Follower。Leader 负责应付生产者和消费者的读写请求，而 Follower 只管同步 Leader 的消息。

Replica ：副本。一个topic的每个分区都有若干个副本，一个Leader和若干个Follower。
Leader ：每个分区多个副本的 "主"，生产者发送数据的对象，以及消费者消费数据的对象都是Leader。
Follower：每个分区多个副本中的 "从"，实时从 Leader 中同步数据，保持和 Leader 数据的同步。Leader 发生故障时，某个Follower会成为新的 Leader。

Leader 和 Follower 分散到不同的 broker 上，这样 Leader 所在的 broker 挂了，也不会影响到 Follower 所在的 broker, 并且还能从 Follower 中选举出一个新的 Leader partition 顶上。这样就保证了消息队列的高可用。

定期和 broker 通信，获取 整个 kafka 集群的状态，以此判断 某些 broker 是不是跪了，某些消费组消费到哪了

kafka 的应用场景

消息队列是架构中最常见的中间件之一，使用场景之多，堪称万金油！

比如上游流量忽高忽低，想要削峰填谷，提升 cpu/gpu 利用率，用它。

又比如系统过大，消息流向盘根错节，想要拆解组件，降低系统耦合，还是用它。

再比如秒杀活动，请求激增，想要保护服务的同时又尽量不影响用户，还得用它。

1.5 部署kafka集群

安装

cd /opt/
tar zxvf kafka_2.13-2.7.1.tgz
mv kafka_2.13-2.7.1 /usr/local/kafka

# 修改配置文件
cd /usr/local/kafka/config/
cp server.properties{,.bak}

vim server.properties
broker.id=0    # 21行，broker的全局唯一编号，每个broker不能重复，因此要在其他机器上配置 broker.id=1、broker.id=2
listeners=PLAINTEXT://192.168.10.18:9092    # 31行，指定监听的IP和端口，如果修改每个broker的IP需区分开来，也可保持默认配置不用修改192.168.10.21:9092，192.168.10.22:9092
num.network.threads=3    # 42行，broker 处理网络请求的线程数量，一般情况下不需要去修改
num.io.threads=8         # 45行，用来处理磁盘IO的线程数量，数值应该大于硬盘数
socket.send.buffer.bytes=102400       # 48行，发送套接字的缓冲区大小
socket.receive.buffer.bytes=102400    # 51行，接收套接字的缓冲区大小
socket.request.max.bytes=104857600    # 54行，请求套接字的缓冲区大小
log.dirs=/usr/local/kafka/logs        # 60行，kafka运行日志存放的路径，也是数据存放的路径
num.partitions=1    # 65行，topic在当前broker上的默认分区个数，会被topic创建时的指定参数覆盖
num.recovery.threads.per.data.dir=1    # 69行，用来恢复和清理data下数据的线程数量
log.retention.hours=168    # 103行，segment文件（数据文件）保留的最长时间，单位为小时，默认为7天，超时将被删除
log.segment.bytes=1073741824    # 110行，一个segment文件最大的大小，默认为 1G，超出将新建一个新的segment文件
zookeeper.connect=192.168.10.18:2181,192.168.10.21:2181,192.168.10.22:2181    # 123行，配置连接Zookeeper集群地址

修改环境变量

# 修改环境变量
vim /etc/profile
export KAFKA_HOME=/usr/local/kafka
export PATH=$PATH:$KAFKA_HOME/bin

source /etc/profile

---

总结

提示：这里对文章进行总结：

例如：以上就是今天要讲的内容，本文仅仅简单介绍了pandas的使用，而pandas提供了大量能使我们快速便捷地处理数据的函数和方法。