Kafka

一、使用java程序或者插件工具连接kafka服务器时，超时？

1.修改配置文件：

2.重启kafka

二、Kafka的一些基本概念

broker的基本概念:

• 一个topic可以有多个分区，增加分区可以提高性能，加快生产者发送消息的速度和消费者消费消息的速度。
• offset在低版本之前储存在zk里面，后面由于性能问题创建了50个默认的主题来存储offset
  • offset消息提交到哪个分区？ hash（consumerGroupId）% _consumer_offsets主题的分区数
  • offset提交了什么数据？ key是consumerGroupId + topic+分区号。 value是offset

生产者的基本概念：

• 生产者发送消息先把消息发送到缓冲区里面，再由客户端本地线程提交给broker

  • 生产者发送消息时，若指定分区，未设置key，就往指定的分区发消息
  • 生产者发送消息时，若设置key，则按hash（key）对分区总数取模
  • 生产者发送消息时，若未指定分区，未设置key，则会使用默认的分区算法，轮询模式，将消息均匀的分布到不同的分区。当然：如果连续的消息都比较小，他们都会到一个分区里面，因为连续几十个消息可能大小没超过默认的16kb，这样他们一同放在缓冲区的一个batch里面，由本地线程一次发送到broker

• 生产者向topic发送消息，消息顺序存储在kafka的日志文件当中，文件目录一般为：tmp/kafka-logs/topic名称-分区id/0000000000000.log
  

三、单播消息、多播消息

单播消息：一个消费组中只有一个消费者能得到topic中的消息。
多播消息：不同的消费组订阅同一个topic，那么【每一个消费组】中都能【有且仅有一个】消费者得到消息

四、副本

1.有了kafka集群才有了副本的概念。
2.副本相当于是分区的备份。

由上图可见：
1.topic有两个分区：my-replicated-topic _0. my-replicated-topic _1
2.my-replicated-topic _0在每个borker上都有，只不过在broker2上才是leader，读写都在broker2上
3.my-replicated-topic _1在每个borker上都有，只不过在broker0上才是leader，读写都在broker0上

五、集群消费

1.topic中一个分区的消息只能 被一个消费组中的一个消费者消费 比如：Partition0的消息只能被GroupA中的 Consumer1或Consumer2消费 或者 GroupB中的 Consumer3、 Consumer4、 Consumer5、 Consumer6其中之一消费。 目的是为了保证消费的顺序性。但是总的partition消费的顺序得不到保证
2.Group中的消费者 不能大于 topic中的分区，否则多余的消费者消费不到

六、同步、异步发送消息

同步：如果发送者发送完消息没有收到ack，生产者会阻塞，阻塞三秒，然后进行重试 ，重试三次。
ack有三种配置：

• ack=0: Kafka-ckuster 不需要任何broker收到消息，就立即返回ack给生产者，最容易丢消息但是效率是最高的
• ack=1（默认）：多副本之间的leader已经收到消息，并将消息写入到本地的log当中，才返回ack给生产者，性能和安全性是最均衡的
• ack=-1/all ：min.insyncc.replicas=1 则表示需要一个leader和一个follower同步完成之后，才会返回ack给生产者。

异步：生产者发送完消息之后就可以进行后面的业务逻辑，broker收到消息后会异步调用生产者提供的callback方法

七、 消费者offset的自动提交和手动提交

• 自动提交：消费者poll下来消息以后就会自动提交offset
• 手动提交：
  • 同步提交：消费者消费完消息后调用同步提交的方法，当集群返回ack前一直阻塞，返回ack表示提交成功，执行之后的逻辑。
  • 异步提交：消费者消费完消息后，不需要等待集群的ack，直接执行后面的逻辑。可以设置一个回调方法，供集群调用。

八、 长轮询poll消息

• 默认情况下。消费者一次会poll 500条消息。
• 代码中设置了长轮询的时间是1000毫秒
  • 如果一次poll到了五百条，则直接执行for循环
  • 如果这一次没有poll到500条，且时间在一秒之内，那么则直接执行for循环
  • 如果多次都没有poll到500条，且一秒时间到了，那么直接执行for循环
• 如果 两次poll的时间间隔超过30s，集群会认为该消费者的消费能力过弱，将其踢出消费组，触发rebalance机制，rebalance机制会造成性能开销。

九、Kafka集群中的controller、rebalance、HW

1.controller

controller相当于是broker集群中的一个管理者。

• controller的选举机制：每个broker新建的时候会尝试在zookeeper中尝试创建一个新节点 /controller。 第一个成功创建该节点的broker会被选举为controller
• controller挂掉了怎么办：zookeeper通过watch机制感知到并删除临时的/controller节点后，存活的broker会开始竞选新的控制器身份。
• controller的作用是什么？
  • 当集群中有一个副本的leader挂掉，controller会在集群中选择一个新的leader，选举的规则是从isr集合的最左边获取。
  • 当集群中的broker增加或减少时，将信息同步给其他broker
  • 当集群中的分区增加或减少时，将信息同步给其他broker

2.rebanlance机制

• rebanlance机制是指【消费组内消费者】均衡消费topic分区的方式。
• 什么时候会触发rebanlance机制？
  • 消费组成员发生变更
  • 消费者无法在指定时间内完成消息的消费
  • Topic的分区发生了变化

3.HW和LEO

详细讲解：https://cloud.tencent.com/developer/article/2434506
HW「hight weight」： 是一个offset的值，他表示offset小于HW消息可以被消息，offset大于HW的值不能被消费
LEO （log-end-offset）：是offset中的最后一个值，新消息进来的那个offset
每一个broker都有自己的HW和LEO，leader的HW和LEO作为整个分区的HW和LEO。leader还保存了其他follower的HW和LEO。

十、Kafka线上问题优化：

1.如何防止消息丢失？

• 生产者
  • 什么时候会丢失消息？ 异步发送 或者ack为0
  • 设置发送方式为同步发送，并设置ack为1或者-1
  • 如果坚持异步发送 ，可以回调函数中进行重试
  • 设置发送失败重试机制
• 消费者
  • 什么时候消息会丢失？ 设置offset为自动提交
  • 设置offset为手动提交，即消费完消息后再提交offset。（如果消息消费完了，没有提交offset消费者挂了，可能会造成重复消费）

设置定时任务，进行兜底策略。

2.如何防止重复消费？

新增场景下如果进行重复消费，业务数据可能会产生脏数据，其他场景如删除、更新无需处理。解决方案主要是根据业务场景创建联合主键或者代码里保证幂等。

• 什么场景下会重复消费？
  • 消费者在消费完消息后，在提交offset之前挂掉了。
  • 消费者处理业务逻辑时间超长，会触发kafka的Rebanlance机制，会踢掉消费能力较弱的消费者导致提交offset失败。
• 解决方案？
  • 提高消息处理的性能或者将消息的处理超时时间变长一些
  • 使用联合主键在数据库层面避免重复消费

3.如何保证顺序消费？

kafka保证单分区内的消息是有序的，所以生产者把消息都发送到同一个分区，消费者只从这个分区里面拉取消息能够保证顺序消费。

4.如何处理消息积压？

先判断是生产者生产消息过快 还是 消费者消费消息过慢。

一般都是消费者的问题，有两种方案：

• 消费者数量小于分区数量，可以适度增加消费者的数量
• 提高消费者的消费能力，比如不在循环里面调RPC接口或者复杂逻辑，优化数据库操作
• 如果实在是用普通的优化手段优化不了了，还可以用多线程去处理消息，
  • 每个线程去维护一个offset队列。 当前线程消费完这个消息以后，维护本线程的offset队列。
  • 维护一个offset监听程序，可以每隔五秒就收集一下某个topic中的某个分区的offset，维护在一个有序数组当中，将最大的连续offset提交即可