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用户空间
- 避免垃圾收集(通道，原生缓冲区，页面缓存，直接内存的使用之类)
- 分区机制