kafka知识总结

Kafka分区：

分区策略：1、轮训策略：最平均 2、随机。3、key 4、自定义分区

Kafka压缩：

Kafka消息层次分两次：消息集合 消息 一个消息集合中包含若干条日志项，日志项才是真正封装消息的地方。

producer压缩 ->broker保持()->Consumer解压缩。

Kafka无消息丢失配置怎么实现：

1、什么是Kafka消息丢失。已提交状态消息的消息丢失才算kafka消息丢失，好多情况都是Producer端，由于网络波动，消息没有到达Broker。其实这并不是kafka丢失。 Producer.send(msg) 是fire or forget 不会收到是否发送成功的标示，应该用：producer.send(msg, callBack) callback方法可以收到发送结果

2、什么是已提交消息：producer端有acks=3 代表3个broker接受到消息，该消息才算”已提交”。 acks=all：所有broker接受到消息。

3、broker端丢失：broker挂掉了。

4、customer端丢失：offSet是消费分区消息的位置，默认情况下，offSet是自动提交的，正常来说是先消费后移动offSet 但在多线程消费消息时，可能会出现一种特殊情况， 5个线程消费5个消息，如果不关闭默认提交，offSet会是5，但可能5个线程消费时，有2消费失败了。那么这2条消息就会丢失，所以异步消费时，应该关闭自动提交，采用手动提交（实现会很难)。

kafka拦截器：

生产者拦截器：ProducerInterceptor onSend() onAcknowledgement()

消费者拦截器：ConsumerInterceptor  onConsum()  onCommit()

kafka TCP链接：

1、kafka在实例创建时会启动Sender线程，创建bootstrap.sever中配置的所有的broker的TCP链接。

2、KafkaProducer 实例首次更新元数据信息之后，还会再次创建于集群中所有broker的TCP链接。

3、如果producer发送到某台broker发现没有与该broker的TCP链接，也会立即创建链接。

4、connections.max.idle.ms 大于0 步骤1 创建TCP会自动关闭，如果是-1。则步骤1创建的TCP链接将无法关闭，从而成为僵尸链接。

消息交付可靠性：

1、最多一次 消息可能会丢失，但绝不会重复发送

2、至少一次 消息不回丢失，但有可能重复发送

3、精确一次 消息不会丢失，也不会重复发送-kafka通过幂等和事务实现 0.11.0以上

幂等性：producer 

Producer 默认不是幂等的。可设置成幂等性  props.put(“enable .idempotence”,true) 只能保证单分区单会话保证幂等性

事务性：producer 保证跨分区跨会话  性能较差

消费者组 consumer Group

1、常见的消息框架有两种，消息队列模型、发布/订阅模型 Kafka consumer group 这种设计同时满足两种模型，当只有一个cousumer group 和topic 就是消息队列模型，多个cousumer group 和topic 就是发布/订阅模型 

2、_consumer_offSet 从0开始，代表下一条消息的位置。老版本是保存在Zookeeper中，当Consumer重启时可以直接从Zookeeper读取位移，继续消费。但Offset是经常修改的。其实Zookeeper并擅长经常写操作，所以新版本位移是保存在Broker主题。 消息格式；K V 对 K:consumer group  

cousumer位移OffSet 提交位移，自动、手动两种。enable.auto.commit=true(默认值) auto.commit.interval.ms =5(默认,自动提交的时间间隔) enable.auto.commit =false (关闭自动提交，需要手动调用kafkaAPI 提交位移)commitSync()(同步)提交位移此时Consumer时阻塞，会影响TPS 可以自动重试commitAync()(异步)，该方法是异步提交的，所以出现问题不会重试。

如果提交位移值=5 Kafka会认为0-4的消息已经消费。

3、Rebalance当消费者组里的consumer实例数量发生变化或者订阅的主题数量，订阅主题的分区数变化就会触发重平衡，该过程会尽量平均分配分区给consumer实例

此过程是Stop the word STW 和JVM垃圾回收一样。

弊端：影响Consumer TPS 、Rebalance 比较耗时、所有的consumer实例参与Rebalance导致效率低

Kafka:CommitFailedException 一次消费消息处理时间过长 ，提交consumer位移失败。

max.poll.records(一次poll消息的数量)= 

max.poll.interval.ms(一次poll消息处理时长)=

Kafka consumer端 多线程消费

Java kafka consumer API 是单线程设计。

kafkaConsumer多线程消费

消费者启动多个线程，每个线程维护专属的kafkaConsumer实例。负责完整的消息的获取和消息处理流程

常见的异常总结：

1、根本原因是Consumer Handler的处理时间过长，超过了Max.poll.interval.ms

常见两种场景：一次消费的MQ过多。调整max.poll.records。

                        MQ里的数据多导致的消费处理逻辑时间长，改成异步。