kafka笔记1

一、 kafka概述

1、kafka是什么

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

发布/订阅模式

消息的发布者不会将消息发给特定的订阅者,而是将发布的消息分为不同的类别,订阅者只接受感兴趣的消息。

消息队列

1)三个特点

  • 缓冲/消峰: 有助于控制和优化数据流经过系统的速度,解决生产消息和消费消息的处理速度不一致的情况。
  • 解耦: 允许你独立的扩展或修改两边的处理过程,只要确保它们遵守同样的接口约束。
  • 异步通信: 允许用户把一个消息放入队列,但并不立即处理它,然后在需要的时候再去处理它们。

2)两种模式

  • 点对点模式:消费者主动拉取数据,消息收到后清除消息
  • 发布/订阅模式:可以有多个topic主题;消费者消费数据后,不删除数据;每个消费者相互独立,都可以消费到数据

2、kafka高效读写数据

1)Kafka 本身是分布式集群,可以采用分区技术,并行度高
2)读数据采用稀疏索引,可以快速定位要消费的数据
3)顺序写磁盘,写的过程是一直追加到文件末端,省去了大量磁头寻址的时间。
4)页缓存 + 零拷贝技术

二、kafka架构

  • Producer:消息生产者,就是向Kafka broker发消息的客户端
  • Consumer:消息消费者,向Kafka Broker取消息的客户端
  • Consumer Group:消费者组,由多个consumer组成。消费者组内每个消费者负责消费不同分区的数据,一个分区只能由一个组内消费者消费,消费者组之间互不影响。所有的消费者都属于某个消费者组,即消费者组是逻辑上的一个订阅者。
  • Broker:一台服务器就是一个Broker,一个集群由多个broker组成。一个broker可以容纳多个topic
  • Topic:可以理解为一个队列,生产者和消费者面向的都是一个topic
  • Partition:为了实现扩展性,一个非常大的topic可以分布到多个broker上,一个topic可以分为多个partition,每个partition是一个有序队列。------leader
  • Repica:副本,一个leader和多个Follower

文件存储

1、文件存储机制

topic是逻辑概念,partition是物理层面的概念,每个partition对应一个log文件夹,producer生产数据会不断追加到log文件末端,防止log文件过大导致定位效率低下,Kafka采取了分片和索引机制,将每个partition分为多个segment。每个segment包括:“.index”文件、“.log”文件和.timeindex等文件。
在这里插入图片描述
实用工具查看log文件以及索引文件

kafka-run-class.sh kafka.tools.DumpLogSegments --files ./00000000000000000000.index

在这里插入图片描述

kafka-run-class.sh kafka.tools.DumpLogSegments --files ./00000000000000000000.log 

kafka笔记1_第1张图片

步骤
①根据目标offset定位到Segment文件
②找到小于等于目标offset的最大offset对应索引项
③定位到log文件
④向下遍历找到record

2、文件清理策略

Kafka 中默认的日志保存时间为 7 天,可以通过调整如下参数修改保存时间。

  • log.retention.hours,最低优先级小时,默认 7 天。
  • log.retention.minutes,分钟。
  • log.retention.ms,最高优先级毫秒。
  • log.retention.check.interval.ms,负责设置检查周期,默认 5 分钟。

日志超过设置时间,日志清理策略

  • log.cleanup.policy = delete 所有数据启用删除策略

如果一个 segment 中有一部分数据过期,一部分没有过期,怎么处理?
处理的规则:等待获取最新数据时间戳,也就是所有记录中的最大时间戳,作为判断过期的依据,然后进行清理。

  • log.cleanup.policy = compact 所有数据启用压缩策略

副本概念

1、副本作用

副本它的作用是提高数据可靠性,kafka默认副本数是一个,在生产环境中一般配置俩个,保证数据的可靠性,如果太多的副本会增加磁盘存储空间,增加网络上数据传输,降低效率。

Kafka 分区中的所有副本统称为 AR,AR又分为ISR和OSR
ISR(in -sync Replicas):
①达到时间阈值和消息条数阈值,如果 Follower 长时间未向 Leader 发送通信请求或同步数据,则该 Follower 将被踢出 ISR。
②Leader 发生故障之后,就会从 ISR 中选举新的 Leader。

OSR(out -sync Replicas):
表示 Follower 与 Leader 副本同步时,延迟过多的副本。

2、选举机制

Leader 发生故障后,就会从 ISR 中选举出新的 Leader。
当follower变成主节点后,其他follower开始从新的leader同步offset。如果新leader的LEO低于follower,那么follower多余的数据会被删除;最终保证和主节点的数据—致。
kafka leader选举流程
(1)查看 Leader 分布情况

kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic hello

在这里插入图片描述
(2)停掉节点broker=1的节点

 bin/kafka-server-stop.sh

(3)查看leader分区情况:broker=1被提出ISR
在这里插入图片描述
broker=1的节点不可用
在这里插入图片描述
(4)启动节点broker=1的节点 leader分区情况
在这里插入图片描述

三、分配策略

生产
一个consumer group中有多个consumer组成,一个 topic有多个partition组成,现在的问题是,到底由哪个consumer来消费哪个partition的数据。
可以通过配置参数partition.assignment.strategy,修改分区的分配策略。

1.Range

Range 是对每个 topic 而言的。
首先对同一个 topic 里面的分区按照序号进行排序,并对消费者按照字母顺序进行排序。

通过 partitions数/consumer数 来决定每个消费者应该消费几个分区。如果除不尽,那么前面几个消费者将会多消费 1 个分区。

再平衡

如果一个消费者挂掉了如何实现再平衡呢
一个消费者挂掉后,会把他的任务会整体被分配到其他消费者,消费者组需要按照超时时间45s来判断它是否退出,所以需要等待,时间到了45s后,判断它真的退出就会把任务分配给其他broker执行。

2.RoundRobin

RoundRobin 针对集群中所有Topic而言。

RoundRobin 轮询分区策略,是把所有的 partition 和所有的consumer 都列出来,然后按照 hashcode 进行排序,最后通过轮询算法来分配 partition 给到各个消费者。

再平衡

一个消费者挂掉,会按轮询的方式把它的数据分给其他的消费者,也是再过45s后确认是否真正退出。

3.Sticky

首先会尽量均衡的放置分区到消费者上面,在出现同一消费者组内消费者出现问题的时候,会尽量保持原有分配的分区不变化

再平衡

一个消费者挂掉之后,会按照粘性规则,尽可能随机分配分区,有其他消费者消费。

生产者发送消息

案例一

将数据发往指定 partition 的情况下,例如,将所有数据发往分区 1 中。
生产者端
kafka笔记1_第2张图片

案例二

没有指明 partition 值但有 key 的情况下,将 key 的 hash 值与 topic 的 partition 数进行取余得到 partition 值
key 值为 a,b,f
kafka笔记1_第3张图片
kafka笔记1_第4张图片
kafka笔记1_第5张图片

四、offset

offset是什么

生产者把数据存放在leader分区,存放完毕后,消费者组开始消费分区数据,消费过程中会有offset,就是指消费者消费到哪里

offset维护位置

0.9之前,维护在zookeeper中,但是会造成一个问题,每个消费者都会和zookeeper进行通讯,造成大量网络通讯问题,效率比较低下
0.9之后。默认将offset存放在kafka一个内置的topic中,名称为_consumer_offsets

__consumer_offsets 主题里面采用 key 和 value 的方式存储数据。key 是 group.id+topic+分区号,value 就是当前 offset 的值。每隔一段时间,kafka 内部会对这个 topic进行compact,也就是每个 group.id+topic+分区号就保留最新数据。

offset提交方式

自动提交

enable.auto.commit:是否开启自动提交offset功能,默认是true
auto.commit.interval.ms:自动提交offset的时间间隔,默认是5s
产生的问题: 重复消费
1) Consumer:每5s提交offset
2)如果提交offset后的2s,consumer挂了
3)再次重启consumer,则从上一次提交的offset处继续消费,导致重复消费

手动提交

手动提交offset的方法有两种:分别是commitSync(同步提交)和commitAsync(异步提交)。

commitSync(同步提交):必须等待offset提交完毕,再去消费下一批数据。
commitAsync(异步提交) :发送完提交offset请求后,就开始消费下一批数据了。

相同点:都会将本次提交的一批数据最高的偏移量提交
不同点:同步提交阻塞当前线程,一直到提交成功,并且会自动失败重试(由不可控因素导致,也会出现提交失败);而异步提交则没有失败重试机制,故有可能提交失败。

产生的问题: 漏消费
当offset被提交时,数据还在内存中未落盘,此时刚好消费者线程被kill掉,那么offset已经提交,但是数据未处理,导致这部分内存中的数据丢失。

五、kafka安全

  • 幂等性

幂等性就是指Producer不论向Broker发送多少次重复数据,Broker端都只会持久化一条,保证了不重复。

幂等性的实现原理,kafka引入了PID和Sequence Number。
PID。每个新的Producer在初始化的时候会被分配一个唯一的PID,这个PID对用户是不可见的。
Sequence Numbler。(对于每个PID,该Producer发送数据的每个都对应一个从0开始单调递增的Sequence Number)

幂等性无法实现跨分区和跨会话数据不重复,因为服务器在重启之后,首先PID,就是刚才所说的生产者分配的ID会被打乱,所以无法实现跨会话,然后就是partition的主键会被打乱,所以幂等性无法实现跨分区的数据不重复

  • 开启事务:

弥补了这一缺陷,需要开始事务
事务它的实现原理: Producer 端引入了一个 TransactionalId 来解决这个问题,它可以用来标识一个事务操作,便于这个事务的所有操作都能在一个地方(同一个 TransactionCoordinator)进行处理,这个操作把消费和生产的处理在一 个原子单元内完成,操作要么全部完成、要么全部失败。

你可能感兴趣的:(大数据,kafka,笔记,分布式)