kafka笔记

消息队列

使用场景

缓存/消峰：数据量过大时，消息队列缓存数据，服务端缓慢读取

解耦：数据源、目的地不同，符合接口约束即可

异步通信：无所谓的工作，由其他从kafka中读取完成

模式

• 点对点：一对一，消费者主动拉取数据，读取后删除
• 发布订阅模式（设计模式）：多对多，消费者相互独立，消费后不删除，其他消费者可以读到数据。多个topic主题

中间件比较

• RabbitMQ
  ​ 支持很多的协议：AMQP，XMPP, SMTP, STOMP
  ​ 重量级，适合企业级的开发
  ​ 发送给客户端时先在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持。

• Redis
  ​ 基于Key-Value对的NoSQL数据库
  ​ 入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；
  ​ 出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。

• ZeroMQ
  ​ 快，大吞吐量的需求场景。
  ​ 高级/复杂的队列，技术复杂度高，开发人员需要自己组合多种技术框架
  ​ 不需要安装和运行一个消息服务器或中间件
  ​ 仅提供非持久性的队列，如果宕机，数据丢失。

• ActiveMQ
  ​ 类似于ZeroMQ，以代理人和点对点的技术实现队列。
  ​ 类似于RabbitMQ，高效

• Kafka/Jafka
  ​ 高性能，分布式，发布/订阅消息队列系统
  ​ 快速持久化，可以在O(1)的系统开销下进行消息持久化；
  ​ 高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率；
  ​ 完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现负载均衡；
  ​ 支持Hadoop数据并行加载，对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka通过Hadoop的并行加载机制统一了在线和离线的消息处理。
  ​ 轻量级，性能好，工作良好的分布式系统。
  ​ 采用零拷贝技术

kafka

Kafka：数据管道、流分析、数据集成和关键任务应用。存储、计算、分析、集成

基础架构

• Broker： 一台 Kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个broker 可以容纳多个 topic。一个大的 topic 可以分布到多个 broker（即服务器）上。扩展性↑
• Topic： 可以理解为一个队列， 生产者和消费者面向的都是一个 topic。逻辑概念
• partition（分区）：有序队列。海量数据，为提高吞吐量****分区，一个topic分为多个partition。一个分区的数据只能由一个消费者来消费。物理概念
• Replica（ 副本）：为提高可用性，为每个partition增加若干副本，partition为leader，副本为follower，生产和消费只针对leader，Follower 找 Leader 进行同步数据。leader挂掉后ISR中follower推举产生新的leader。
  默认副本 1 个，生产环境一般配置为 2 个，保证数据可靠性；太多副本会增加磁盘存储空间，增加网络上数据传输，降低效率。
• zk：分区信息， leader和follower信息由zk存储，新版本可以不使用zk存储
• Consumer Group（CG）：消费者组，由多个consumer组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。
• ISR队列：和Leader保持同步的follower，follower一段时间内（replica.lag.time.max.ms，默认30s）未与leader同步数据或通信则认为follower挂掉，踢出ISR队列。
  OSR： Follower 与 Leader 副本同步时，延迟过多的副本。
  AR：Kafka 分区中的所有副本统称为 AR（Assigned Repllicas）。AR = ISR + OSR

生产端

发送原理

• 序列化器：客户指定，java自带的过重
• 分区器：分区器在内存中，大小32m，实际上为一个缓存队列，包含多个双端队列。
  一个分区一个队列，将数据发送到对应分区的队列中（一个数据可发往多个队列）。
  分区器中还包含一个内存池，每一批次数据从内存池取内存插入队列，发送成功后删除数据，内存释放回内存池
• sender：从分区器中读取数据发到kafka，队列中累积batch.size数据为一组读取发送。如果未达到batch.size，在达到linger.ms时间也读取发送。
  每个分区一个队列，读取对应分区队列的数据发送到对应分区（leader和follower）。如果分区未应答，可继续发送，最多可发送五组数据，如果仍未应答则不再发送。分区应答，回复成功，则清除sender发送的数据以及分区器队列中的数据，失败则重试（次数不限）。

batch.size：数据积累到batch.size之后，sender才会发送数据。默认16k
linger.ms：如果数据迟迟未达到batch.size，sender等待linger.ms设置的时间，到了之后就会发送数据。单位ms，默认值是0ms，表示没有延迟。

• 同步发送：等上一批数据已发送到kafka集群中再继续发送。可靠可重试
• 异步发送：将外部数据发送到分区器中，无需等待ack。效率高，可以异步知道消息发送结果，缺点是无法重试

异步发送

// 1.创建kafka生产者的配置对象
Properties properties = new Properties();

// 2.给kafka配置对象添加配置信息
properties.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "hadoop102:9092");
// key,value序列化（必须）：key.serializer，value.serializerproperties.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG,
StringSerializer.class.getName());
properties.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG,StringSerializer.class.getName());

// 3.创建kafka生产者对象
KafkaProducer<String, String> kafkaProducer = new KafkaProducer<String, String>(properties);

// 4.调用send方法,发送消息
for (int i = 0; i <5; i++) {
	//添加回调
	kafkaProducer.send(new ProducerRecord<>("first", "atguigu" + i),new Callback(){
		//该方法在Producer收到ack时调用，为异步调用
		@Override
		public void onCompletion(RecordMetadata metadata, Exception exception) {
			if (exception == null) {
				//没有异常,输出信息到控制台
				System.out.println("主题：" +
				metadata.topic()+ "->"  + "分区：" +metadata.partition());
			} else {
				//出现异常打印
				exception.printStackTrace();
			}
		}
	});
	//延迟一会会看到数据发往不同分区
	Thread.sleep(2);
}

// 5.关闭资源
kafkaProducer.close();

同步发送

// 1.创建kafka生产者的配置对象
Properties properties = new Properties();

// 2.给kafka配置对象添加配置信息
properties.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "hadoop102:9092");
// key,value序列化（必须）：key.serializer，value.serializerproperties.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG,
StringSerializer.class.getName());
properties.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG,StringSerializer.class.getName());

// 3.创建kafka生产者对象
KafkaProducer<String, String> kafkaProducer = new KafkaProducer<String, String>(properties);

// 4.调用send方法,发送消息
for (int i = 0; i <5; i++) {
	//异步发送默认
//            kafkaProducer.send(newProducerRecord<>("first","kafka" + i));
	//同步发送
	kafkaProducer.send(new ProducerRecord<>("first","kafka" + i)).get();
}

// 5.关闭资源
kafkaProducer.close();

消息的分区

• 便于合理使用存储资源，数据存储在多台Broker上。合理控制分区的任务，可以实现负载均衡的效果。
• 提高并行度，生产者可以以分区为单位发送数据；消费者可以以分区为单位进行消费数据。

有指定分区，按指定分区，没有指定分区按key，没有指定分区没有key，随机一个一直使用直到已满或已完成，再随机一个（必须和上一个随机的不同）

可自定义分区器：实现Partitioner接口

/**
* 1.实现接口Partitioner
* 2.实现3个方法:partition,close,configure
* 3.编写partition方法,返回分区号
*/

/**
*返回信息对应的分区
* @param topic主题
* @param key消息的key
* @param keyBytes消息的key序列化后的字节数组
* @param value消息的value
* @param valueBytes消息的value序列化后的字节数组
* @param cluster集群元数据可以查看分区信息
* @return
*/
@Override
public intpartition(String topic, Object key, byte[]
keyBytes, Object value, byte[] valueBytes, Cluster cluster) {
	// 获取消息
	String msgValue = value.toString();
	// 创建 partition
	int partition;
	// 判断消息是否包含 atguigu
	if (msgValue.contains("atguigu")){
		partition = 0;
	}else {
		partition = 1;
	}
	// 返回分区号
	return partition;
}

//使用
properties.put(ProducerConfig.PARTITIONER_CLASS_CONFIG,"com.atgui
gu.kafka.producer.MyPartitioner");

生产者提高吞吐量

batch.size：批次大小，默认16k
linger.ms：等待时间，修改为5-100ms
compression.type：压缩snappy
RecordAccumulator：缓冲区大小，修改为64m

数据可靠性

ack应答

• 0：生产者发送过来的数据，不需要等数据落盘应答。效率最高。如果服务端挂掉则数据丢失（此时数据在内存中，或未收到），不安全
• 1：生产者发送过来的数据，Leader收到数据后应答。应答后，leader数据还未与follower同步就挂掉，则数据丢失
• -1（all）：生产者发送过来的数据，Leader+follower（ISR队列）收齐数据后应答。数据可靠，若一个follower挂掉则无法收齐。

若分区副本数为1，或ISR应答最小副本数量=1，当follower挂了，则与ack=1情况相同
数据完全可靠条件：ack=-1+分区副本数>=2+ISR应答最小副本数量>=2
数据重复（ack=-1）：leader+部分follower获得数据，未收齐时leader挂掉，没有回复ack，则重新选举leader，重发数据，follower可能获得一个已获得的数据。

数据重复

最多收一次：ack=0
最少收一次：ack=-1+分区副本数>=2+ISR最小副本数量>=2
精确一次（ExactlyOnce）= 幂等性+至少一次（ack=-1+分区副本数>=2+ISR最小副本数量>=2）。

幂等性

• Producer不论向Broker发送多少次重复数据，Broker端都只会持久化一条，保证了不重复。如果重复，不会在磁盘中落盘，在内存中删掉
• 单分区单会话内不重复。
• 重复数据的判断标准：具有<PID,Partition,SeqNumber>相同主键的消息提交时，Broker只会持久化一条。
  PID是生产者id，kafka每重启一次，产生一个新的id；Partition表示分区号；SequenceNumber是单调自增的。

事务

数据有序

保证单分区内有序：给消息用统一的topic和key指定分区
可以完成多分区内有序：多个分区统一读取，排序，效率低。不如只用一个topic

数据乱序

生产者最多可接受kafka五个数据包没有应答
eg：①②正常发送，③失败，④正常，③重发

方案：
（1）未开启幂等性
max.in.flight.requests.per.connection需要设置为1。
（2）开启幂等性
max.in.flight.requests.per.connection需要设置小于等于5。
原因说明：因为在kafka1.x以后，启用幂等后，kafka服务端会缓存producer发来的最近5个request的元数据，故无论如何，都可以保证最近5个request的数据都是有序的。

①②有序，正常落盘，应到③，实际收到④，则内存中缓存④，直到收到③

Broker

工作流程

• offset存于kafka 的topic中
• broker启动向zk注册，zk存储broker、leader相关信息
• zk选举leader 按照AR中的顺序，要求ISR中存活的
• follower主动拉取数据，与leader同步

Leader选举

每个broker 有一个controller，其中一个Controller 会被选举为 Controller Leader，负责管理集群broker 的上下线，所有 topic 的分区副本分配和 Leader 选举等工作。
Controller 的信息同步工作是依赖于 Zookeeper 的。

follower故障

LEO（Log End Offset）：每个副本的最后一个offset，LEO其实就是最新的offset + 1。
HW（High Watermark）：所有副本中最小的LEO。

消费者能见到的最大的offset = HW-1

leader故障

从ISR中选出一个新的Leader
为保证多个副本之间的数据一致性，其余的Follower会先将各自的log文件高于HW的部分截掉，然后从新的Leader同步数据。
只保证副本之间的数据一致性，并不能保证数据不丢失或者不重复。

分区副本分配

• 可手动调整

Leader Partition 负载平衡

Kafka自动会把LeaderPartition均匀分散在各个机器上，来保证每台机器的读写吞吐量都是均匀的。
如果部分broker宕机，重启之后的broker都是followerpartition，会导致LeaderPartition过于集中在其他少部分几台broker上，这会导致少数几台broker的读写请求压力过高，followerpartition读写请求很低，造成集群负载不均衡。

auto.leader.rebalance.enable，默认是true。自动Leader Partition平衡
leader.imbalance.per.broker.percentage，
默认是10%。每个broker允许的不平衡的leader的比率。如果每个broker超过了这个值，控制器会触发leader的平衡。
leader.imbalance.check.interval.seconds，
默认值300秒。检查leader负载是否平衡的间隔时间。

增加副本因子

由于某个主题的重要等级需要提升，我们考虑增加副本。副本数的增加需要先制定计划，然后根据计划执行

文件存储

• 每个partition一个log文件， 存储Producer生产的数据。
• 数据在末尾插入到log中 ，为防止文件过大导致数据定位效率低下，每个partition 分片为多个segment，对segment建索引机制
• 每个segment包括： “.index”文件（偏移量索引文件）、 “.log”文件（日志文件）和.timeindex（时间戳索引文件）等文件。 这些文件位于一个文件夹下， 该文件夹的命名规则为： topic名称+分区序号
  index和log文件以当前segment的第一条消息的offset命名。
  index为稀疏索引，4kb数据一条索引

数据查找

index文件名中有offset
根据文件名，判断使用哪个index文件
index文件名中的offset+index存储的相对offset 选择适当的log文件
根据log文件查找位置

文件清除

日志默认保存 7 天，超时，清除

• delete
  • 以segment中最后文件的时间为时间戳，计算过期时间
  • 数据大小超出指定范围，则删除最早的segment
• compact压缩：同一个key只留最新的value，其余删掉。压缩后的offset不连续。适用于特殊场景。eg：用户信息

高效读写

• 分布式集群，分区技术
• 稀疏索引，快速定位
• 顺序写磁盘：避免磁头寻址
• 页缓存+零拷贝：不对数据进行处理，不走应用层，所以零拷贝（linux提供），效率更高。数据到kafka存储于页缓存，然后存于内存/落盘
• 16kb一个包，传输次数减少
  

消费端

消费方式

• 推：消费者能力不足消费不了时还会推。kafka没有
• 拉：没有数据时，消费者还会拉

消费者流程

消费者消费的offset，存于kafka集群，topic相关位置。如果存在zk，会导致客户端和zk频繁通信

• 一个消费者可以消费多个分区
• 一份分区只能由消费者组内的一个消费者消费
• 组内每个消费者负责消费不同分区
• 消费者组的消费者数量超过主题分区数量，则有一部分消费者就会闲置，不会接收任何消息。

• 消费一次，1k-50m数据/一定时间内的数据为一条，一次五百条

消费者组初始化

根据消费者组的groupid 选择分区，所有消费者与分区的coordinator通信，coordinator选择一个消费者做leader，将相关信息反馈给消费者leader，leader制定合适的消费计划把方案发给coordinator，coordinator发给所有消费者。如果消费者挂掉或者消费时间过长，则coordinator将其消费工作Rebalance，分配给其他消费者

分区分配策略

range

一个topic的全部分区按分区号排序，平均分给所有消费者，除不尽的给最前面的几个消费者。

数据倾斜：最前面的几个消费者获取更多数据，如果多个topic，则前面几个消费者总能获得更多数据，压力大

eg：一万个topic，每个topic4个分区（0-3），共三个消费者
分区0，1归消费者1，分区2归消费者2，分区3归消费者3
消费者1比其他消费者多消费一个分区，一万个topic，则消费者1比其他消费者多消费一万个分区

再平衡
某个消费者挂掉后，消费者组需要按照超时时间 45s 来判断它是否退出，45s 后，判断它真的退出就会把全部任务按照现有消费者数量重新分配

RoundRobin

所有Topic的所有的partition按照hashcode排序，轮询分配partition给到各个消费者。

eg：一万个topic，每个topic4个分区（0-3）。共三万个分区，按照hashcode排序（0-29999），轮询给每个消费者。
分区0归消费者1，分区1归消费者2，分区2归消费者3，分区3归消费者1，分区4归消费者2，分区5归消费者3

再平衡：全部任务重新分配

Sticky

粘性分区，尽可能均衡分区，尽可能保持原有不变
全部分区乱序，其他约等于range
再平衡：将挂掉的消费者的任务重新分配

offset

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

自动提交

每隔五秒，自动提交
重复消费：已消费，未提交，消费者挂了，则重启后，从旧offset处消费。
消费者消费时间过长，认为消费者挂掉，也会导致重复消费

手动提交

同步/异步提交：消费数据&提交offset
漏消费：已消费，offset已提交，数据未落盘，消费者挂了，则数据丢失。重启后从offset位置向后消费

避免数据重复/丢失：生产端，消费者应支持事务，给消息体中加唯一标识

指定位置消费

指定offset：消费者中设置offset
指定时间：时间转为offset

数据积压（消费者提高吞吐量）

增加分区和消费者
消费者拉取数据50m，500条，修改参数

Kafka-Kraft 模式

Kafka 现有架构， 元数据在 zookeeper 中， 运行时动态选举 controller， 由controller 进行 Kafka 集群管理。
kraft 模式架构：用三台 controller 节点代替 zookeeper， 元数据保存在 controller 中， 由 controller 直接进行 Kafka 集群管理。

• Kafka 不再依赖外部框架， 而是能够独立运行；
• controller 管理集群时， 不再需要从 zookeeper 中先读取数据， 集群性能上升；
• 集群扩展时不再受到 zookeeper 读写能力限制；
• controller 不再动态选举， 而是由配置文件规定。 这样我们可以有针对性的加强controller 节点的配置， 而不是像以前一样对随机 controller 节点的高负载束手无策