Kafka优化提升

一、如何优化kafka集群

1、吞吐量

2、低延时

生产者

a.batch.size=512kb或1MB（批量数据大小）

b.buffer.memory=64M（缓冲区大小）

c.linger.ms=10-100(毫秒)（是否等待传输）

d.compression.type=snappy(是否压缩)

e.acks=0或1 retries=0（安全系数定，重试次数可以设置小一点）

broker端

f.num.replica.fetchers='不大于cpu的核数'（副本数量）

g.replica.lag.time.max=30s（isr列表复制快速剔除）

f.num.network.threads=9（工作线程数）

g.num.io.threads=32（服务器用于请求的线程数）

消费者

f.fetch.min.bytes=1kb（broker积攒多少条数据就可以返回给cosumer端）

g.fetch.max.bytes=50M（消费者获取一批的最大字节数）

f.message.max.bytes=9（broker配置）

g.max.message.bytes=32（topic配置）

g.max.poll.records=500（一次拉取的条数）

topic端

设置合理的分区数（压测调整）

生产者压测脚本、消费端压测脚本

二、kafka实现延迟队列

不适合实现延迟队列，roketmq实现更方便

1、java的delayQueue+kafka实现延迟队列

实现方式：发送消息不直接发送到真实mq，而是发送到内部主题中，对用户不可见

按照5,10秒的延迟等级划分发到多个topic,有一定时间误差，内部有DelayService消费逻辑处理并存储到DelayQueue中

可以在DelayService中计数到达指定值时停止发送到DelayQueue，DelayQueue可以按照投递时间进行排序，最后发送到真实的主题，最后消费者可以在真实的主题中进行消费

虚拟内部主题topic---DelayService用于计数-----DelayQueue------realtopic

问题：不准确时间

2、Rocksdb+kafka实现延迟队列

延迟消费模块 先把消息进Rocksdb 当时间到达再取出来消息放回到kafka中

Rocksdb使用的是LSM算法，适合大量数据写入的场景

结构清晰

三、如何保障kafka的数据一致性

1、主从副本、

是核心、同步副本

与zk保持会话 zookeeper.session.timeout.ms=6000(副本与zk会话时间保持心跳)

从leader副本同步 replica.lag.time.max=30000(follower最多与leader副本晚30秒内的消息)

副本是个动态的过程，时间过长可能剔除，只用在用副本（in sync）延迟会影响整个kafka的速度，out sync不影响整体速度

2、broker端配置、

beoker的数量一定要大于副本的个数

副本个数 replication.factor=3  （高5低2）

最少的in-sync节点数 min.insync.replicas=2（允许部分副本不可用）

是否允许out-of-sync分区成为leader unclean.leader.election.enable=false

3、生产者、

确认成功acks   acks=all

重发次数   retries=2147

需要客户端处理错误

4、消费者可靠性配置

手动提交位移 enable.auto.commit=false

保证幂等性：只成功消费一次即可

四、线上kafka有大量数据挤压时几千万几个小时，如何处理

产生原因：数据库磁盘满，消费错误

接口处理慢，瞬间消息量大、缓存实现方式慢导致

1、修复consumer程序

快速修复消费方式，增加硬盘或让消息尽量快速消费，需要上线处理，风险高，傻傻等待。。。

2、新建一个topic，临时扩容

新建立consumerb程序，

新建一个topicb，partion扩大为原来的10倍（30个）

把原有topic的数据写到新的topicb中，

再加30台机器快速去启动消费consumerb

问题：硬件+机器，如果程序不健壮可能丢失数据

3、离线+实时增量（lambda架构）

停掉消费者

spark离线计算挤压任务，几分钟处理几千万

五、谈谈kafka控制器及选举机制的理解

在kafka集群中只能有一个controller存在

zk集群启动----启动broker0----brokers/ids/0

controller-broker0-epoch

启动broker1----brokers/ids/1

启动broker2----brokers/ids/2

controller节点脑裂问题

GC触发原controller挂掉假死

epoch版本号避免脑裂

controller故障如何启动新的controller

六、深度对比kafka和rabbitmq

1、消息的顺序性消费比对

rabbitmq出现问题

使用消息复制的方式分发数据，会降低性能

多消费者无法严格保证顺序消费消息

2、kafka

可以把同一个订单消息发一个分区

主动拉取消息，没有消息复制过程，不存在消息出错再放回去的情况，吞吐量高，不乱序

3、延迟队列

rabbitmq合适

有个ttl字段，可以设置消息在队列的时间，超时可以放到延迟队列，exchange在消息到时间才把消息放在真正队列并消费

kafka

实现延迟队列复杂，需要一个临时的topic，自己开发中间消费者，判断延时，可以放在数据库，到时间再放回去。

总结

rabbitmq 安全性可靠

消息的时序控制

高级路由策略实现

kafka 吞吐量大 不能保证多线程消费的顺序性

需要比较严格的顺序消费

消息吞吐量大的场景

七、kafka批量处理数据和日志存储模式

1、生产者

消息经过拦截器、序列化器、过滤器后把消息写到pagecache中，

当pagecache数据达到10%的时候将会异步顺序追加的方式写入到磁盘中，

为提高吞吐量将一个topic分为多个partion，每个partion会对应一个磁盘的文件夹有数据文件和索引文件，默认1GB

log.segment.bytes=1G（数据文件）

log.index.size.max.bytes=10M（索引文件--内存中）

跳跃表baseoffset   00000.index 批量写入数据

数据文件和索引文件对应关系

八、生产环境大量消息挤压如何处理

加机器+加硬件

提高吞吐量

broker0-partion0-消息-本地缓存-消费者0（每个分区一个消费者）

拉取消息默认500条  max.pull.records=500

当broker0不够500会从其他分区筹齐500条返回数据

kafka只是从分区拉取500条并不会控制哪个分区，容易造成堆积

可以处理流量削峰

在消息加一个key，不同消息分区到一个线程，每个分区一个独立的线程池，通过key取模，保证一个

本地缓存到达一个量时候，可以暂停拉取。

九、kafka读写数据为何这么快

磁盘顺序追加写，pagecache，0拷贝技术、批量发送消息、压缩技术

1、磁盘顺序追加写

顺序追加写，能达到50M每秒，随机磁盘写只能达到300k，减少了磁盘寻址时间及切换

2、pagecache内存空间

mmap内存映射的方式，利用操作系统pagecache异步写数据，操作系统自己管理的内存，

数据写入pagecache，当达到参数内存百分比10%就会批量写磁盘

vm.dirty_backgroud_ratio=10,后台的sync线程就会把数据同步到磁盘上

3、0拷贝技术

通过pagecache把数据拷贝到网卡上去，用户直接可以消费数据，避免了内核态和用户态的拷贝

已经到磁盘的数据采用DMA拷贝技术回到pagecache再同步到网卡（DMA gater）

cpu拷贝只是把文件描述符和数据长度拷贝到socket缓存

0拷贝并不是么有数据拷贝，只是省去了用户态和内核态的数据拷贝，没有cpu数据拷贝过程，但有cpu进行描述符和数据长度的拷贝过程

4、批量发送消息

先把消息堆积到kafka的池化内存中，再分批发送的pagecache中，生产者高吞吐量

5、压缩技术

两个地方用到压缩，生产者端和broker端

消费者解压缩，减少磁盘的带宽

十、kafka的ISR是如何收缩广播

controller节点管理列表，kafka有一个副本管理器replicaManager

1、定时任务

ISR列表的收缩和伸展机制任务

replica.lag.time.max.ms/2(默认30秒)

如果某个节点在30秒follower还没有从leader同步数据会被剔除掉ISR列表

15秒执行一次，

1、检查follower和leader的LEO值是否相等，

2、follower超时时间30秒内未fetch数据

满足两条进行ISR列表收缩，把新的ISR列表同步到zk的持久化映射中

isrchangeset保存修改记录controller中

lastchangeMs记录变更时间controller中

扩展是通过follower节点fetch数据的时候发生

当follower的LEO =HW值就可以满足加入ISr列表中，需要封装isr列表信息

2、广播定时任务

每隔2500毫秒执行一次，满足两个条件进行广播

isrchangeset有变更&&（距离上次修改ISR列表时间超过5秒||距离上次广播时间超过60秒）

广播首先创建zk的永久节点存放isrchange系列号，读取两个内存对象，通过controller节点进行

controller监听isrchange系列号通过结果获取哪部分isr变更后的数据，写到controller自己的内存，广播到所有节点

十一、kafka异步发送消息如何保证可靠性

1、生产者可靠性

request.required.acks=-1

所有follower副本从生产者同步信息后才返回ack确认信息

数据重复问题可以通过kafka的事物特性来解决

min.insync.replicas=2

最小同步副本数，当isr的副本数小于这个值时，整个分区就不可用了，通常设置为分区副本的半数以上

太大一个节点故障整个kafka分区不可用

unclean.leader.election.enable=false

客户端都是leader副本进行读写操作

2、broker可靠性保障

LEO 日志末端offset

HW 分区的最小leo值

replica.lag.time.max.ms=30s默认