Kafka
一、为什么要使用Kafka
- 削峰:上游的数据下游可能扛不住,Kafka在中间起到调剂的作用,将消息暂存,下游自行拉取
- 解耦和扩展性:消息队列可以作为一个接口层,解耦重要的业务流程
- 异步通讯:不需要上下游同时处理数据,在需要时才回去发布(生产者)或者消费数据(消费者)
- 健壮性:消息队列可以堆积请求,及时消费端业务短时间死掉,也不会影响到业务的正常运行
二、Kafka消费过的数据怎么再消费
? Kafka消费信息的offset信息是定义在Zookeeper中的,若果想要重复消费Kafka的消息,可以在redis中记录offset的checkpoint点,当想要重复消费数据的时候,通过Redis中的checkpoint点进行zookeeper的offset重新设置,这样就可以重新消费了
三、Kafka为什么会快?
Kafka使用的磁盘存储。
- 顺序写入:硬盘的机械机构,喜欢顺序存储,使用顺序IO比较快
- Memory Mapper Files(内存映射文件):64位操作系统中一般可以表示20G的数据文件,它的工作原理是直接利用操作系统的Page来实现文件到物理内存的直接映射。完成映射之后你对物理内存的操作会被同步到硬盘上。
- Kafka高效文件存储设计:Kafka把topic中一个Partition大文件分成多个小文件段,通过多个小文件段,就容易定期清除或删除已经消费完文件,减少磁盘占用。通过索引信息可以快速定位message和确定response的 大小。通过index元数据全部映射到memory(内存映射文件),可以避免segment file的IO磁盘操作。通过索引文件稀疏存储,可以大幅降低index文件元数据占用空间大小。
注:
- Kafka解决查询效率的手段之一是将数据文件分段,比如有100条Message,它们的offset是从0到99。假设将数据文件分成5段,第一段为0-19,第二段为20-39,以此类推,每段放在一个单独的数据文件里面,数据文件以该段中 小的offset命名。这样在查找指定offset的
Message的时候,用二分查找就可以定位到该Message在哪个段中。 - 为数据文件建 索引数据文件分段 使得可以在一个较小的数据文件中查找对应offset的Message 了,但是这依然需要顺序扫描才能找到对应offset的Message。
为了进一步提高查找的效率,Kafka为每个分段后的数据文件建立了索引文件,文件名与数据文件的名字是一样的,只是文件扩展名为.index。
四、Kafka数据怎么保障不丢失?
分三个角度保障:生产者端,消费者端,broker端
- 生产者数据不丢失
- Kafka的ack机制:应答机制分为三种
- ack = 0,producer不等待同步完成确认,直接发送下一条(批)信息
- ack = 1,producer等待leader成功接收数据并得到确认,才发送下一条message
- ack = 2,producer等待follower确认之后,才发送下一条message
-
消费者数据不丢失 ? 通过offset commit来保证数据的不丢失,Kafka自己记录了每次消费的offset的数值,下次消费的时候,会接着上一次消费的offset进行消费 ? ? offset信息在Kafka0.8版本之前保存在zookeeper中,在0.8版本之后保存到topic中,及时消费者在运行过程中挂掉了,再次启动的时候会找到offset的值,找到之前消费信息的位置,接着消费,由于offset的信息斜入式并不是每一条信息消费完之后都会写入offset,所以可能出现重复消费,但是不会丢失数据。 -
Kafka集群中的broker的数据不丢失 ? 每个broker中的partition我们一般都会设置有replication(副本)的个数,生产者写入的时候首先根据分发策略(有partition按partition,有key按照key,都没有就轮询)写入到leader中,follower(副本)再跟leader同步数据,这样就有了备份,可以保证数据的不丢失。
五、采集数据选择Kafka?
采集层主要可以使用Flume,Kafka等技术。
Flume: Flume是管道流方式,提供了很多的默认实现,让用户通过参数部署,及拓展API
Kafka: Kafka是一个可持久化的分布式的消息队列。Kafka 是一个非常通用的系统。你可以有许多生产者和很多的消费者共享多个主题Topics。
相比之下,Flume是一个专用工具被设计为旨在往HDFS,HBase发送数据。它对HDFS有特殊的优化,并且集成了Hadoop的安全特性
结论:多个系统消费的话,使用kafka;如果数据被设计给Hadoop使用,使用Flume。
六、kafka 重启是否会导致数据丢失?
- kafka是将数据写到磁盘的,一般数据不会丢失。
- 但是在重启kafka过程中,如果有消费者消费消息,那么kafka如果来不及提交offset,可能会造成数据的不准确(丢失或者重复消费)
七、 kafka 宕机了如何解决?
- 先考虑业务是否受到影响
kafka 宕机了,首先我们考虑的问题应该是所提供的服务是否因为宕机的机器而受到影响,如果服务提供没问题,如果实现做好了集群的容灾机制,那么这块就不用担心了。
- 节点排错与恢复
想要恢复集群的节点,主要的步骤就是通过日志分析来查看节点宕机的原因,从而解决,重新恢复节点
八、 为什么Kafka不支持读写分离?
在Kafka中,生产者写入消息、消费者读取消息的操作都是与leader副本进行交互的,从而实现的是一种主写主读的生产消费模式
-
主写从读的缺点:
-
数据一致性问题:数据从主节点转到从节点有一个时间差,可能会导致数据不一致的问题 -
延时问题: 类似Redis这种组件,数据从写入主节点到同步至从节点的过程需要经历: 网络->主节点内存->网络->从节点内存 在Kafka中,主从同步会比Redis更加耗时: 网络→主节点内存→主节点磁盘→网络→从节 点内存→从节点磁盘
而kafka的主从主读的优点就很多了:
- 可以简化代码的实现逻辑,减少出错的可能
- 将负载力度细化均摊,与主写从读相比,不仅负载效能更好,而且用户可控
- 没有延时的影响
- 在副本稳定的情况下,不会出现数据不一致的情况。
|