- 什么是Kafka
- 他就是一个消息中间件,可以把数据放到里面,用的时候从里面取数据
- 为什么要使用消息队列
- 缓冲数据削峰
- kafka主要起到一个缓冲的作用,可以把消息暂存在kafka中,让下游服务器可以按照自己的能力慢慢处理
- 解耦扩展
- 项目一开始,并不能确定具体需求,它可以作为一个接口层,解耦重要的业务流程
- 冗余
- 可以采用一对多的方式,一个生产者发布消息,可以被多个订阅topic的服务消费到别的业务使用。
- 健壮性
- 它可以堆积请求,所以消费端业务即使短时间死掉,也不会影响主要业务的正常进行
- 异步通讯
- 用户把一个消息放入队列,但并不立即处理它。想向队列中放入多少消息就放多少,然后在需要的时候再去处理它们。
- 缓冲数据削峰
- Kafka中的ISR、AR代表什么
- AR :所有的副本
- ISR:同步队列的副本
- kafka中的broker 是干什么的
- broker是一个节点,对资源进行管理的
- kafka中的 zookeeper 起到什么作用,可以不用zookeeper么
- zookeeper主要是用来管理用户信息的,kafka的所有元数据信息是放到这里面的
- kafka follower如何与leader同步数据
- Kafka的复制机制既不是完全的同步复制,也不是单纯的异步复制。完全同步复制要求All Alive Follower都复制完,这条消息才会被认为commit,这种复制方式极大的影响了吞吐率。而异步复制方式下,Follower异步的从Leader复制数据,数据只要被Leader写入log就被认为已经commit,这种情况下,如果leader挂掉,会丢失数据,kafka使用ISR的方式很好的均衡了确保数据不丢失以及吞吐率。Follower可以批量的从Leader复制数据,而且Leader充分利用磁盘顺序读以及send file(zero copy)机制,这样极大的提高复制性能,内部批量写磁盘,大幅减少了Follower与Leader的消息量差。
- 什么情况下一个 broker 会从 isr中踢出去
- 达到4000条数据
- 10秒钟
- kafka 为什么那么快
- Cache Filesystem Cache PageCache缓存
- 顺序写 由于现代的操作系统提供了预读和写技术,磁盘的顺序写大多数情况下比随机写内存还要快。
- 零拷技术减少拷贝次数
- 批量量处理。合并小的请求,然后以流的方式进行交互,直顶网络上限。
- Pull 拉模式 使用拉模式进行消息的获取消费,与消费端处理能力相符。
- kafka producer如何优化打入速度
- 增加线程
- 提高 batch.size
- 增加更多 producer 实例
- 增加 partition 数
- 设置 acks=-1 时,如果延迟增大:可以增大 num.replica.fetchers(follower 同步数据的线程数)来调解跨数据心的传输:增加 socket 缓冲区设置以及 OS tcp 缓冲区设置。
- kafka unclean 配置代表啥,会对 spark streaming 消费有什么影响
- unclean.leader.election.enable 为true的话,意味着非ISR集合的broker 也可以参与选举,这样有可能就会丢数据,spark streaming在消费过程中拿到的 end offset 会突然变小,导致 spark streaming job挂掉。如果unclean.leader.election.enable参数设置为true,就有可能发生数据丢失和数据不一致的情况,Kafka的可靠性就会降低;而如果unclean.leader.election.enable参数设置为false,Kafka的可用性就会降低。
- 如果leader crash时,ISR为空怎么办
- kafka在Broker端提供了一个配置参数:unclean.leader.election,这个参数有两个值:
true(默认):允许不同步副本成为leader,由于不同步副本的消息较为滞后,此时成为leader,可能会出现消息不一致的情况。
false:不允许不同步副本成为leader,此时如果发生ISR列表为空,会一直等待旧leader恢复,降低了可用性。
- kafka在Broker端提供了一个配置参数:unclean.leader.election,这个参数有两个值:
- kafka的message格式是什么样的
- 一个Kafka的Message由一个固定长度的header和一个变长的消息体body组成
- header部分由一个字节的magic(文件格式)和四个字节的CRC32(用于判断body消息体是否正常)构成。
- 当magic的值为1的时候,会在magic和crc32之间多一个字节的数据:attributes(保存一些相关属性,
- 比如是否压缩、压缩格式等等);如果magic的值为0,那么不存在attributes属性
- body是由N个字节构成的一个消息体,包含了具体的key/value消息
- kafka中consumer group 是什么概念
- 同样是逻辑上的概念,是Kafka实现单播和广播两种消息模型的手段。同一个topic的数据,会广播给不同的group;同一个group中的worker,只有一个worker能拿到这个数据。换句话说,对于同一个topic,每个group都可以拿到同样的所有数据,但是数据进入group后只能被其中的一个worker消费。group内的worker可以使用多线程或多进程来实现,也可以将进程分散在多台机器上,worker的数量通常不超过partition的数量,且二者最好保持整数倍关系,因为Kafka在设计时假定了一个partition只能被一个worker消费(同一group内)。
- Kafka中的消息是否会丢失和重复消费?
- 要确定Kafka的消息是否丢失或重复,从两个方面分析入手:消息发送和消息消费。
15.为什么Kafka不支持读写分离?
在 Kafka 中,生产者写入消息、消费者读取消息的操作都是与 leader 副本进行交互的,从 而实现的是一种主写主读的生产消费模型。
Kafka 并不支持主写从读,因为主写从读有 2 个很明 显的缺点:
(1)数据一致性问题。数据从主节点转到从节点必然会有一个延时的时间窗口,这个时间 窗口会导致主从节点之间的数据不一致。某一时刻,在主节点和从节点中 A 数据的值都为 X, 之后将主节点中 A 的值修改为 Y,那么在这个变更通知到从节点之前,应用读取从节点中的 A 数据的值并不为最新的 Y,由此便产生了数据不一致的问题。
(2)延时问题。类似 Redis 这种组件,数据从写入主节点到同步至从节点中的过程需要经 历网络→主节点内存→网络→从节点内存这几个阶段,整个过程会耗费一定的时间。而在 Kafka 中,主从同步会比 Redis 更加耗时,它需要经历网络→主节点内存→主节点磁盘→网络→从节 点内存→从节点磁盘这几个阶段。对延时敏感的应用而言,主写从读的功能并不太适用。
16.Kafka中是怎么体现消息顺序性的?
kafka每个partition中的消息在写入时都是有序的,消费时,每个partition只能被每一个group中的一个消费者消费,保证了消费时也是有序的。
整个topic不保证有序。如果为了保证topic整个有序,那么将partition调整为1.