Kafka

Kafka

在虚拟机中启动kafka

依赖于zookeeper，zk中会存入一些kafka的信息，如kafka集群中有几个topic，名字，几个分区，副本在哪个机器上、leader是哪个机器等等。在kafka的配置文件中需要配置不同的broker_id，zk会默认将每个kafka组成一个集群，

在虚拟机centos-one的/opt/zookeeper/bin/multiply_zk.sh和/opt/kafka/bin/multiply_zkafka.sh是一个zookeeper和kafka一起启动的脚本。执行命令：/opt/zookeeper/bin/multiply_zk.sh stop/start即可启动和关闭

定义

是一个分布式（集群）的基于发布/订阅模式的消息队列

使用场景

参考文档：https://blog.csdn.net/lp284558195/article/details/80271853

**日志收集：**一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer；

**消息系统：**解耦生产者和消费者、缓存消息等

特点

(1) 解耦

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

(2) 冗余

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

(3) 扩展性

因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码、不需要调节参数。扩展就像调大电力按钮一样简单。

(4) 灵活性 & 峰值处理能力

在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见；如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。

(5) 顺序保证

在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。Kafka保证一个Partition内的消息的有序性。

(6) 缓冲

在任何重要的系统中，都会有需要不同的处理时间的元素。例如，加载一张图片比应用过滤器花费更少的时间。消息队列通过一个缓冲层来帮助任务最高效率的执行———写入队列的处理会尽可能的快速。该缓冲有助于控制和优化数据流经过系统的速度。

kafka架构图

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

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

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

消息队列的两种模式

（1）点对点模式

一对一，消费者主动拉取数据，收到消息后就将它清除，队列中就不存在了，复用性差

（2）发布/订阅模式

消息生产者发布消息到topic中，同时有多个消费者订阅消息。

kafka工作流程

Kafka 中消息是以 topic 进行分类的，生产者生产消息，消费者消费消息，都是面向 topic的。topic 是逻辑上的概念，而 partition 是物理上的概念，每个 partition 对应于一个 log 文件，该 log 文件中存储的就是 producer 生产的数据。Producer 生产的数据会被不断追加到该log 文件末端，且每条数据都有自己的 offset。消费者组中的每个消费者，都会实时记录自己消费到了哪个 offset，以便出错恢复时，从上次的位置继续消费

生产者和消费者的操作

生产者发布消息，9092是kafka端口号，输入一个回车即发布一个消息（在centos-01机器上发布，此时在centos-02中输入消费消息的命令后即可输出消息）

[root@localhost ~]# kafka-console-producer.sh --broker-list 192.168.2.10:9092 --topic second
[2020-08-27 13:59:09,133] WARN Property topic is not valid (kafka.utils.VerifiableProperties)
1111
2222
3333
444
555

消费者订阅下消息

• 此命令是在生产者边发布消息（如上面的555），这里才会输出最新的

[root@localhost logs]# kafka-console-consumer.sh \ --zookeeper 192.168.2.10:2181 --topic second
555

• 加上–from-beginning，即会将所有数据都读取出来

[root@localhost logs]# kafka-console-consumer.sh \ --zookeeper 192.168.2.10:2181 --from-beginning  --topic second
1111
2222
3333
444

kafka文件系统

由于生产者生产的消息会不断追加到 log 文件末尾，为防止 log 文件过大导致数据定位效率低下，Kafka 采取了分片和索引机制，将每个 partition 分为多个 segment。每个 segment对应两个文件——“.index”文件和“.log”文件

在/opt/kafka/data的分区中主要包含两个index（主要存储索引信息）和log（存储数据），当存储的消息数据很多时，index文件就派上场了，能够快速定位到log中的数据，首先通过二分查找找到索引的偏移量，再去log文件中查找数据，first-0就是一个主题topic的一个分区，可以创建多个，创建后是一个有序的分区

[root@localhost data]# cd first-0/
[root@localhost first-0]# ll
总用量 4
-rw-r–r--. 1 root root 10485760 8月 27 14:51 00000000000000000000.index
-rw-r–r--. 1 root root 59 8月 27 14:55 00000000000000000000.log

Kafka生产者Producer

分区策略

定义：生产消息后，如何分发到不同分区中，默认使用的策略是轮询策略，能够最大限度的平均分配到所有分区

数据可靠性保证（ack）

为了保证producer能够可靠的发送到指定的topic中，在topic的partition收到数据后，会发送一个ack，如果producer收到ack，就会进行下一轮的发送。

ack=0：

​ producer发送消息后，broker接收到还没有写入磁盘就已经返回，此时broker故障时有可能丢失数据。

ack=1：

​ 写入磁盘后返回ack，如果在follower同步成功之前leader出现故障，此时会丢失数据

ack=-1/all：

​ 最好的情况，数据不会丢失但是数据会重复，不过有解决办法，开启幂等性即可，下面有介绍在Exactly Once中

何时发送ack？

​ 当leader和follow同步完成，leader再发送ack。（这样才确保leader挂掉之后，follwer中存在完整数据，以便可以重新选出leader，数据不会丢失），但是follwer不一定是全部同步数据后才发送ack，这里有两种方式：半数以上完成同步可以发送ack、全部完成同步再发送ack。一般采用第二种方式，当有n个节点出现故障，只需要n+1个副本即可保证有一台机器数据完整，缺点延迟高（并不影响）下面有解决方案：采用ISR。第一种方式，当有n个节点出现故障，只需要2n+1个副本才能保证有一台机器数据完整。

ISR（in-sync replicda set同步副本）

**作用：**采用第二种方案，当有一个follower因为某种故障，导致无法与leader同步，就要一直等，就不能发送ack，所以采用ISR解决该问题

**定义：**leader会维持一个与其保持同步的replica集合，该集合就是ISR，每一个partition都有一个ISR，它时有leader动态维护

机制原理：

ISR中会存放一部分（需要保证ISR中至少有一个follower）follower集合，当follower集合完成与leader的数据同步后，leader就发送ack。如果folower未向leader同步数据，则该follower将被踢出ISR，该时间阈值有replica.lag.max.ms参数决定，若leader发生故障后，就从ISR中选举leader

HW和LEO

作用：HW和LEO主要是为了保证ISR列表中的数据是一致的（前提是leader和follower都在ISR列表中），进而保证kafka数据的不丢失。

LEO：last and offset，日志末端偏移量，用来表示当前日志文件中下一条写入消息的offset。如：若LEO=10，则表示在该副本日志上已经保存了10条消息，偏移量范围为[0,9]

HW：Highwatermark，俗称高水位，它标识了一个特定的消息偏移量（offset），消费者只能拉取这个offset之前的消息。任何一个副本对象的HW的值等于ISR队列中最小的LEO值

• HW的作用主要是来判读副本的备份进度

• 小于或等于HW的消息被认为是“已经被提交”或“已经备份的”

  

Exactly Once

精准一次性，指保证数据既不重复也不丢失

Exactly Once = At Least Once + 幂等性

At Least Once：保证数据不丢失，但不能保证数据不重复

幂等性：将enable.idompotence 设置为true即可开启。producer无论发送多少次重复数据，server端只会持久化一次。

Kafka消费者Consumer

consumer都采用pull（拉）模式从broker中消费消息数据，但是有一个缺点就是当kafka中没有数据时，消费者还是会一直去拉取，导致陷入循环解决办法就是设置一个timeout时间，如果没有数据可消费，consumer等待一段时间后再返回。push（推）不合适，因为每个消费者的消费速率不同，假设50M/s,有点消费者只需要10M/s,有的20M/s,这样就导致资源浪费

分区分配策略

两种方式：RoundRobin轮询策略和Range范围策略（默认的）

两种策略的参考文档：https://blog.csdn.net/dz77dz/article/details/89384935

消费者案例

1）需求：测试同一个消费者组中的消费者，同一时刻只能有一个消费者消费。

2）案例实操

（1）在 centos-02、centos-03 上修改/opt/module/kafka/config/consumer.properties 配置

文件中的 group.id 属性为任意组名。

group.id=atguigu

（2）在 centos-02、centos-03 上分别启动消费者

 bin/kafka-console-consumer.sh \ --zookeeper centos-02:2181 --topic first --consumer.config  config/consumer.properties

（3）在centos-01 上启动生产者

 bin/kafka-console-producer.sh \ --broker-list hadoop102:9092 --topic first

\>hello world

（4）查看 centos-02 和 centos-03 的接收者。

同一时刻只有一个消费者接收到消息。

kafka事务

Producer事务（重要的）

为了实现跨分区和跨会话的事物，需要引入一个全局的Transaction ID，将Producer获取的PID和Transaction ID绑定在一起，这样当producer挂掉或者重启时可以通过Transaction ID拿到原来的PID，就可以保证事务。需要引入组件Transaction Coordinator管理Transaction ID。Producer 就是通过和 Transaction Coordinator 交互获得 Transaction ID 对应的任务状态。Transaction Coordinator 还负责将事务所有写入 Kafka 的一个内部 Topic，这样即使整个服务重启，由于事务状态得到保存，进行中的事务状态可以得到恢复，从而继续进行

consumer事务（了解）

对于 Consumer 而言，事务的保证就会相对较弱，尤其时无法保证 Commit 的信息被精确消费。

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

自动提交offset

手动提交offset

（1）同步提交

（2）异步提交