关于kafka的一些认识“开启掘金成长之旅！这是我参与「掘金日新计划 · 2 月更文挑战」的第 5 天，点击查看活动详情

“开启掘金成长之旅！这是我参与「掘金日新计划 · 2 月更文挑战」的第 5 天，点击查看活动详情”

名词解释

AR:Kafka分区中的所有副本统称
ISR:Leader和Follow之间工作正常的节点
Segment (1G) .log,.index

linux集群常用的执行命令脚本(xcall) 和同步文件脚本(xsync)

kafka入门安装

赋役新节点,退役旧节点 -- 需要注意负载均衡

1.创建一个要均衡的主题

vim topics-to-move.json

{
	"topics":[
		{"topic":"first"}
	],
	"version":1
}

2.创建执行计划

bin/kafka-reassign-partitions.sh --bootstarp-server xxxx:9092 --topics-to-move-json-file topics-to-move.json --breker-list "0,1,2" --generate

3.创建副本存储计划(所有副本存储在 broker0,broker1,broker2中)

vim increase-replication-factor.json
存储内容为步骤2生成的计划内容

4.执行副本存储计划

bin/kafka-reassign-partitions.sh --bootstarp-server xxxx:9092 --reassignment-json-file increase-replication-factor.json --execute

5.验证副本存储计划

bin/kafka-reassign-partitions.sh --bootstarp-server xxxx:9092 --reassignment-json-file increase-replication-factor.json --verify

broker

zk存储了哪些信息
    (1) broker.ids
    (2) leader
    (3) 辅助选举 controller

查看分区副本情况

/bin/kafka-topics.sh --bootstarp-server hadoop102:9092 --describe --topic three

通过工具查看 index 和 log 信息

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

offset

0.9之后保存到 kafka的系统主题里

0.9之前存在zk里

coordinator: 辅助实现消费者组的初始化和分区的分配

coordinator 节点选择 = groupid的hashcode值% 50(__consumer_offsets的分区数量)

每个消费者都会和coordinator保持心跳(默认3s),一旦超时(session.timeout.ms=45s),该消费者会被移除,并触发再平衡;或者消费者处理消息的时间过长(max.poll.interval.ms=5min),也会触发再平衡

关于抓取消息时的一些参数

Fetch.min.bytes每批次最小抓取大小,默认1字节

Fetch.max.wait.ms一批数据最小值未达到的超时时间

Fetch.max.bytes 每批次最大抓取大小,默认50m

Max.poll.records 一次拉取数据返回消息的最大条数

Kafka四种主流的分区分配策略:

Range、RoundRobin、Sticky、CooperativeSticky,通过配置参数 partition.assignment.strategy -- 修改分区的分配策略

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

Sticky以及再平衡粘性分区是Kafka从0.11x版本开始引入的这种分配策略,首先会尽量均衡的放置分区到消费者上面,在出现同一消费者组内消费者出现问题的时候,会尽量保持原有分配的分区不变化

enable.auto.commit: 是否开启自动提交offset功能,默认是true

auto.commit.interval.ms:自动提交offset的时间间隔,默认是5s

按照时间进行消费的方法

把时间转换为对应的offset

先获取分配方案,把时间转换为offset,再指定 offset

生产环境--数据积压(消费者如何提高吞吐量)

如果是Kafka消费能力不足,则可以考虑增加Topic的分区数,并且同时提升消费组的消费者数量,消费者数 = 分区数
如果是下游的数据处理不及时,提高每批次拉取的数量。批次拉取数据过少(拉取数据/处理时间 < 生产速度),使处理的数据小于生产的数据,也会造成数据积压

EFAK---kafka可视化

Kafka-Kraft模式 2.8.0以后去掉了zk

一、生产调优硬件选择

1、100万日活 * 每人每天产生日志100条 = 1亿条
	处理日志速度 1亿条/ (24*3600s) = 1150条/s
	1条日志 (0.5k-2k)
2、购买多少台服务器
	服务器台数 = 2 * (生产者峰值生产速率 * 副本数 /100) +1
3、磁盘选择
	kafka 按照顺序读写 机械硬盘和固态硬盘 顺序读写速度差不多
	
	1亿条 * 1k =100g
	100g * 2个副本 * 3天 /0.7 = 1t
	建议三台服务器总的磁盘大小 大于1t
4、内存选择
	kafka 内存 = 堆内存(kafka 内部配置) + 页缓存(服务器内存)
	1) 堆内存 10-15G
	2) 页缓存 分区数(10)*segment(1G) 1G*25%
5、CPU选择
	num.io.threads = 8 负责写磁盘的线程数,整个参数值要占总核数的 50%
	num.replica.fetchers =1 副本拉取线程数,这个参数占总核数的 50% 的1/3
	num.network.threads =3 数据传输线程是,这个参数占总核数的50%的 2/3
	建议 32 个cpu core
6、网络选择
	网络带宽 = 峰值吞吐量 选择千兆网卡即可
	100Mbps 单位是 bit；10M/s 单位是 byte

关于消费者的一些参数

session.timeout.ms Kafka消费者和coordinator之间的链接超时时间,默认45s。超过该值,该消费者被移除,消费者组执行再平衡

max.poll.interval.ms 消费者处理消息的最大时长,默认是5分钟。超过该值,该消费者被移除,消费者组执行再平衡

max.poll.records 一次poll拉取数据返回消息的最大条数,默认是 500条

partition.assignment.strategy 消费者分区分配策略,默认策略是 Range + CooperativeSticky。Kafka可以同时使用多个分区分配策略。可以选择的策略包括:Range,RoundRobin,Sticky,CooperativeSticky

提升生产吞吐量

1、 buffer.memory : 发送消息的缓冲区大小,默认值是32m,可以增加到64m  
2、 batch.size: 默认是16k。如果batch设置太小,会导致频繁网络请求,吞吐量下降;如果batch太大,会导致一条消息需要等待很久才能被发送出去,增加网络延时  
3、 linger.ms 这个值默认是0.意思是消息必须立即被发送。一般设置一个 5-100毫秒。如果linger.ms 设置的太小,会导致频繁请求网络,吞吐量下降;如果linger.ms太长,会导致一条消息需要等待很久才能被发送出去,增加网络延时  
4、 compression.type: 默认是none,不压缩,但是也可以使用lz4压缩,效果还是不错的,压缩之后可以减小数据量,提升吞吐量,但是会加大producer端的CPU开销

关于kafka的一些认识