kafka介绍及常见问题解答

kafka介绍及常见问题解答

1.1 主要功能

根据官网的介绍，ApacheKafka®是一个分布式流媒体平台，它主要有3种功能：

1：It lets you publish and subscribe to streams of records.发布和订阅消息流，这个功能类似于消息队列，这也是kafka归类为消息队列框架的原因

2：It lets you store streams of records in a fault-tolerant way.以容错的方式记录消息流，kafka以文件的方式来存储消息流

3：It lets you process streams of records as they occur.可以再消息发布的时候进行处理

1.2 使用场景

1：Building real-time streaming data pipelines that reliably get data between systems or applications.在系统或应用程序之间构建可靠的用于传输实时数据的管道，消息队列功能

2：Building real-time streaming applications that transform or react to the streams of data。构建实时的流数据处理程序来变换或处理数据流，数据处理功能

1.3 详细介绍

1.3.1 消息传输流程

Producer即生产者，向Kafka集群发送消息，在发送消息之前，会对消息进行分类，即Topic，上图展示了两个producer发送了分类为topic1的消息，另外一个发送了topic2的消息。

Topic即主题，通过对消息指定主题可以将消息分类，消费者可以只关注自己需要的Topic中的消息

Consumer即消费者，消费者通过与kafka集群建立长连接的方式，不断地从集群中拉取消息，然后可以对这些消息进行处理。

从上图中就可以看出同一个Topic下的消费者和生产者的数量并不是对应的。

1.3.2 消息存储

数据存储

• 压缩与解压缩
  • 消息压缩指两块，一是单条数据的压缩，二是批量数据的压缩
  • 单条数据的压缩指将数据序列化为二进制
  • 批量数据的压缩指将多条消息合并为1个消息集，共享消息头(比如消息数量，压缩格式等)，提高吞吐量
  • 压缩式发生在生产者端，生产者通过缓存机制和批量提交机制，一次性发送多条消息给kafka
  • 当生产者压缩格式与服务端需要的压缩格式不一致时，服务端会发生解压缩和重压缩的步骤，带来的影响是服务端需要使用jvm内存来完成这一步操作，影响写入效率
  • 解压缩的步骤发生在消费者端
• 存储形式是什么样的？
  • 以文件的方式存储，数据文件是.log结尾
  • 数据内容为原封不动的生产端压缩过后的数据
  • kafka通过mmap+write的形式，写系统缓存(page cache)，由系统控制刷入磁盘，一致性及可用性由副本和ack机制保证
• 是否可更改？
  • 与其他消息队列不同，kafka不允许对已有数据进行更改，消息消费过后也不会被删除
• 日志文件多了怎么办？
  • 通过配置过期删除策略，删除过期的文件
• offset机制
  • offset即位移，指的是消息在文件中的位置,每个分区内单独递增，主要用于副本同步和消费者消费位置管理

分区

• 什么是分区？
  • 分区指的是消息保存在服务端的不同位置，单机下是分文件，集群下是分机器
• 为什么需要分区机制？
  • 分区是为了做负载均衡和横向扩容
• 分多少个合适？
  • 一般而言，分区需要根据数据量决定，数据越多，分区越多，一般而言，日均百万级的数据，3个分区就够了
• 消息会发到哪个分区去？
  • 跟分区策略相关，包括指定分区，hash分区，轮循分区(默认)，自定义分区
  • 消息发送到哪个分区是由生产者决定的，每个生产者会缓存所有的分区信息

副本

• 什么是副本?
  • 副本是kafka为了保证数据不丢失引入的机制
• 一个topic有几个副本?
  • 一个topic的每个分区都有多个副本，由创建topic时的参数replicationFactor决定
• leader与follower机制
  • 一个topic内的多个副本中，一个为leader，其他的都为follower，基于zookeeper的节点加锁，成功创建节点的为leader
  • leader副本控制整个集群的读写请求，生产者端缓存了该topic下所有分区及副本的信息，只会往leader发，如果发到了follower节点，会重新找leader节点
  • follower定时向leader发起同步请求，同步的依据是offset
• 怎么判断follower与leader同步上了
  • 通过ISR(IN-SYNC-REPLICA)副本机制，实际上是存储在zk里面的节点数据
  • replica.log.max.messages，最大消息位置差距,follower副本通过offset同步数据，判断该offset和当前leader节点的结尾offset可得
  • replica.log.time.max.ms，最大同步时间，follower上次发起同步的时间和当前时间比较可得
• 什么时候选leader?
  • 分区数量变化
  • 原leader宕机
• 哪些副本可以作为leader?
  • ISR中的所有服务都可作为leader,谁先往zk中写入数据，谁就是leader
  • ISR副本全挂了怎么办？unclean选举，带来的问题是数据丢失
• 为什么不能主写从读?
  • 主写从读机制存在的目的就是为了负载均衡和分流，比如，终端管理平台的终端交互侧作为主库，后台管理测用从库
  • 主写从读带来的问题就是数据的延迟和不一致，比如连到A从库时有数据，A宕机，连到B从库(还未同步到)，发现没有那条数据
  • 分区机制带来的负载均衡比主写从读更有效

索引

• kafka索引是什么
  • kafka索引是一个文件，以.index结尾
  • kafka索引有两种,offset索引和timestamp索引
  • kafka索引是稀疏索引，类似于数组的结构，每个索引项指向日志中的一条记录，通过二分查找找到区间，再遍历日志记录找到数据

2.1 生产者

• 怎么算写入成功?
  • 因为批量提交的存在，调用producer的send方法后并不说明发送成功，需要注册回调方法判断是否成功
  • ack机制，producer端可配置acks， 0：消息发出去了就成功，1：leader写入了就成功，all:所有ISR写入成功才成功

3.1 消费者

• 消费分组
  • 消费者以组为组织结构，不同group的消费者隔离
  • 在一个group中，一个分区只能给一个消费者消费，一个消费者可以消费多个分区
• 怎么决定我该消费哪个分区?
  • 同一个组中，第一个连接到kafka集群(joinGroup)的消费者自动成为消费者组的leader
  • kafka把所有的topic分区及消费者信息都发送给这个leader，这个leader会把分区分配信息发送给kafka
  • 其他消费者syncGroup时会获取到自己应该消费的分区信息
• 消费到哪了？
  • 消费者通过offset维护当前消费的位置
• offset保存位置?
  • 老版本offset保存在zk中，一个topic节点下有一个group，一个group下有每个分区的offset
  • 新版本offset保存在_consumer_offsets这个topic下
  • 手动管理，druid就是手动管理,自己保存在数据库
• 什么时候提交offset?
  • autoCommit，消费端默认每隔100ms提交一次offset，存在重复消费的可能性
  • 手动管理,可以根据消费进度，保证精确一次，flink里的kafka连接器就是这样的

4.1 kafka为什么这么快

• 日志格式：二进制格式，发送端压缩，接收端解压缩
• 顺序IO：只追加写，尤其指mmap(日志文件映射到内存),操作系统一次性刷新到磁盘
• 批量提交: 提高吞吐量，不需要那么多线程处理
• 批量压缩：减少数据量
• 廉价的消费者:主要指通过offset读取，不更改日志文件
• 未刷新的缓冲写入,指mmap
• 客户端优化:分区策略，压缩，生产者直接发给主节点
• 零拷贝：主要指数据文件发送给消费者时，通过sendfile调用直接发给网络socket，不用加载到jvm用户空间
• 避免垃圾收集(通道，原生缓冲区，页面缓存，直接内存的使用之类)
• 分区机制