kafka基础概念整理

1、kafka是什么？

分布式消息中间件，支持分区，多副本，多订阅者，基于zookeeper协调的消息系统

2、kafka特点

• 高吞吐、低延迟：

• 可扩展：支持热扩展，使用kafka-reassign-partitions.sh脚本重新分区对topic进行负载均衡

• 持久、可靠：消息被持久化到本地硬盘；支持数据备份

• 容错：允许集群中节点失败，只剩一个节点都可以

• 高并发：支持数千个客户端同时读写

3、kafka为什么这么快？

• 顺序读写，无寻道时间
• 零拷贝，类似Java里的filechannel nio技术，内存间互拷，没有客户端的中转
• 分区，存储在不同的brokers上，并行读写
• 文件分段，数据根据offset被划分为segment存储，以该段最小的offset命名，可以通过二分法进行查找定位
• 稀疏索引：二分法查找索引文件，再顺序查找msg对应的位置，做到高效检索
• 批量发送，默认批量提交同一分区的数据大小为16K
• 数据压缩，snappy和gzip，减少数据传输

4、kafka核心组件

• broker：服务器节点
• topic：消息类别，生产和消费时指定topic而不需要关心数据存放位置。可以理解为一个队列
• partition：物理概念，分区内数据有序，不一定全局有序。分区对于集群来说可以实现负载均衡，对于消费者来说提高并发度
• producer：发布消息至broker
• consumer：读取broker上消息的客户端
• consumer group：实现一个topic消息的广播和单播的手段。不指定消费者组的话自动生成一个组。一个group就是一个订阅者
• replica：副本，高可用保障
• leader：副本的一个角色，生产者和消费者只跟leader交互
• follower：副本的一个角色，从leader中复制数据
• controller：一个服务器，进行leader选举和各种failover
• assigned replicas：所有副本
• isr：所有与leader同步的副本，包含leader
• osr：滞后过多的副本
• HW：高水位，标识一个消息偏移量，消费者只能拉取到这个offset之前的消息，HW mark取决于俄ISR列表里偏移量最小的分区，类似木桶原理。目的是防止消息丢失
• LEO：下一条待写入消息的offset

5、消费者组的意义是什么？

• 提高并发消费能力
• 提高容错能力：某个consumer失效，其他consumer自动接管

6、consumer加入或离开？

会触发topic分区的负载均衡，提升并发消费能力

7、kafka文件存储基本结构

kafkalogs–>topics_partition_number–>segment file–>index+log+timestamp

__consumer_offsets 是 kafka 自行创建的，和普通的 topic 相同。它存在的目的之一就是保存consumer提交的位移。

8、为什么要划分为多个segment?

• 如果只存一个文件中, 文件会越来越大
• 更容易定期清理：Kafka中的数据默认存储7天, 每一天都会删除7天前的数据, 如果都存在一个文件当中, 会不好删

9、isr副本同步列表和acks应答机制简介

isr是一个动态的副本列表，每个副本在同步完数据后会向leader发送ack消息确认，如果迟迟等不到副本的消息，就会把follower踢出isr列表，进入osr列表，可以设置等待时间的参数（replica.lag.time.max.ms）

leader向生产者发送acks确认消息有三种可靠级别，1 0 -1，代表的含义分别是：

• acks=0时，不需要任何节点的消息确认，这样的话没法保证数据被写入到服务端（网络故障、对象未被序列化），并且重试机制也会失效；
• acks=1的时候是不需要等follower应答，leader应答就行了，但是如果leader挂掉而follower还没有复制过去的话，消息也会丢失；
• acks=-1的时候，leader等待所有副本都同步完成后再应答消息，就可以保障消息不会丢失。效率略低。可以和参数min.insync.replicas参数结合起来，设置返回确认前至少多少个副本收到消息。一般设置为大于1或大于2

10、不清洁选举unclean.clean.election.enable，默认为false

如果设置为true时，且isr列表的所有副本都挂掉时，会选举osr列表里的副本作为leader，然后isr副本恢复后，在同步之前发现此时的leo比leader的leo还要打，则会截断数据至leader副本leo处并加入新的isr列表中，此时就会造成数据丢失和数据不一致的情况，可靠性降低

而设置为false时，kafka的可用性就会降低

11、怎么保证kafka消费者消费数据是全局有序的

分区有序，如果要全局有序就需要保证每个环节都有序，只有亦可能就是一个生产者一个partition一个消费者，但这种场景和大数据应用场景相悖

12、数据丢失参数设置

13、异步发送消息时消息丢失怎么解决？

异步发送消息时会立即返回，在发生网络抖动时，就会造成数据丢失没有发到Broker端，或者消息不合格被broke拒绝接收

• Producer 永远要使用带有回调通知的发送 API，也就是说不要使用 producer.send(msg)，而要使用 producer.send(msg, callback)。当出现消息失败的情况，针对性的做相应处理即可

14、避免消息丢失最佳实践：

producer：

• 使用带有回调通知的send方法producer.send(msg, callback)，解决异步发送消息时的数据丢失情况
• 设置acks=all
• 设置retries为一个较大的值，自动重试消息

brokers：

• 关闭不清洁选举机制unclean.leader.election.enable = false
• 设置replication.factor>=3，将消息保存多份，通过冗余来方式丢失
• 设置min.insync.replicas > 1，控制消息至少要被写入多个副本才算是已提交
• replication.factor > min.insync.replicas，两者相等，那么只要有一个副本挂机，整个分区就无法正常工作了，推荐设置为replication.factor = min.insync.replicas + 1

consumer：

• 确保消息消费完再提交。Consumer端有个参数enable.auto.commit，最好把它设置成 false，并采用手动提交位移的方式

15、消息重复的问题怎么解决？

将消息的唯一标识保存到外部介质中，每次消费时判断是否消费过即可

16、为什么离线分析要用kafka？

解耦：采集到数据后，在kafka中设置实时和离线两个不同的group读取就行

17、数据积压怎么解决

• kafka消费能力不足的话，增加topic分区数，同时增加group里的消费数量，使消费者数>分区数
• 下游的数据处理不及时的话，增加每批次拉取的数量

18、创建一个topic之后，Kafka背后执行什么逻辑？

• 在zookeeper的/brokers/topics节点下创建一个新的topic节点
• 触发Controller的监听程序
• kafka Controller负责topic的创建工作，并更新metadata cache

19、topic分区数修改

• 增加的话可以用–alter命令
• 不可以减少，被删除的分区数据难以处理（删除？没消费的消息就会丢。保留？追加到其他的分区破坏了分区内的有序性）

20、内部topic，__consumer_offsets的作用

保存消费者offset

21、kafka Controller的作用

• 管理集群broker的上下线
• 所有topic的分区副本分配
• leader选举工作

22、选择使用kafka的场景

• 日志收集
• 消息系统，解耦生产者和消费者、缓存消息
• 流式处理

23、kafka是如何做到消息的有序性的？

• 写入时都是有序的
• 带有offset，消费者根据offset消费

24、kafka数据一致性的原理

HW以上的消息才支持consumer消费，选举新的leader后会截断其他副本HW以后的消息

25、kafka高效文件存储设计特点

• segment机制：定期删除减少磁盘占用
• index机制：index元数据映射到memory中，避免segment的磁盘IO
• 稀疏索引：降低index元数据占用空间大小

26、新建分区的目录在哪？

server.properties里的log.dirs参数

如果多个目录，则创建在目录里文件夹总数最少的目录

27、kafka缺点

• 批量发送，非真正实时
• 分区内有序，非全局有效
  到memory中，避免segment的磁盘IO
• 稀疏索引：降低index元数据占用空间大小