使用java程序或者插件工具连接kafka服务器时，超时？
1.修改配置文件：
2.重启kafka
一、Kafka的一些基本概念
生产者向topic发送消息，消息顺序存储在kafka的日志文件当中。消费者从最后一条消息的下一条或者最开始那一条进行消费。
二、单播消息、多播消息
单播消息：一个消费组中只有一个消费者能得到topic中的消息。
多播消息：不同的消费组订阅同一个topic，那么【每一个消费组】中都能【有且仅有一个】消费者得到消息
三、主题和分区
1.topic主题在kafka中是一个逻辑概念。kafka通过topic将消息进行分类。
2.如果topic对应日志文件中的数量过多，kafka提出了分区的概念：partition
分区的好处？
1.解决统一存储文件过大的问题
2.加大读写的吞吐量
kafka的默认分区是干啥的？
kafka有五十个默认分区（_consumer_offsets-xxxx），存储消费者消费某个主题的偏移量。
- 消息提交到哪个分区？ hash（consumerGroupId）% _consumer_offsets主题的分区数
- 提交了什么数据？ key是consumerGroupId + topic+分区号。 value是offset
四、副本
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方法
七、消息发送缓冲区
- kafka会默认创建一个存放消息的缓冲区，生产者发送消息先发到缓冲区里。默认大小为32MB
- kafka本地线程会去缓冲区里拉取16KB的数据，发送到broker
- 如果拉取不到16k的数据，间隔10ms也会将已经拉到的数据发送到broker
八、 消费者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新建的时候会尝试在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或者all
- 设置发送失败重试机制
- 消费者
- 什么时候消息会丢失？ 设置offset为自动提交
- 设置offset为手动提交，即消费完消息后再提交offset。（如果消息消费完了，没有提交offset消费者挂了，可能会造成重复消费）
2.如何防止重复消费？
- 什么场景下会重复消费？
- 消费者在消费完消息后，在提交offset之前挂掉了。
- 消费者处理业务逻辑时间超长，会触发kafka的Rebanlance机制，会踢掉消费能力较弱的消费者导致提交offset失败。
- 解决方案？
- 提高消息处理的性能或者将消息的处理超时时间变长一些
- 使用联合主键在数据库层面避免重复消费