文章目录
- 一、Controller选举
- 二、Kafka集成
- 2.1、大数据应用场景
- 2.1.1、Flume集成
- 2.1.2、Spark集成
- 2.1.3、Flink集成
- 2.2、Java应用场景(SpringBoot集成)
- 三、Kafka常见问题
- 3.1、Kafka都有哪些组件?
- 3.2、分区副本AR, ISR, OSR的含义?
- 3.3、Producer 消息重复或消息丢失的原因?
- 3.4、Consumer消息重复或消息丢失的原因?
- 3.5、Kafka数据如何保证有序?
一、Controller选举
一句话总结:先到先得。
Controller,是kafka的核心组件。它的主要作用是在Apache Zookeeper的帮助下管理和协调控制整个Kafka集群。下面介绍一下Zookeeper的特点:
- 一个是在ZooKeeper软件中创建节点Node,创建一个Node时,我们会设定这个节点是持久化创建,还是临时创建。所谓的持久化创建,就是Node一旦创建后会一直存在,而临时创建,是根据当前的客户端连接创建的临时节点Node,一旦客户端连接断开,那么这个临时节点Node也会被自动删除,所以这样的节点称之为临时节点。
- ZooKeeper节点是不允许有重复的,所以多个客户端创建同一个节点,只能有一个创建成功。
- 另外一个是客户端可以在ZooKeeper的节点上增加监听器,用于监听节点的状态变化,一旦监听的节点状态发生变化,那么监听器就会触发响应,实现特定监听功能。
集群中的任意一台Broker都能充当Controller的角色,但是,在整个集群运行过程中,只能有一个Broker成为Controller。也就是说,每个正常运行的Kafka集群,在任何时刻都有且只有一个Controller。
最先在Zookeeper上创建临时节点/controller成功的Broker就是Controller。Controller重度依赖Zookeeper,依赖zookeepr保存元数据,依赖zookeeper进行服务发现。Controller大量使用Watch功能实现对集群的协调管理。如果此时,作为Controller的Broker节点宕掉了。那么zookeeper的临时节点/controller就会因为会话超时而自动删除。而监控这个节点的Broker就会收到通知而向ZooKeeper发出创建/controller节点的申请,一旦创建成功,那么创建成功的Broker节点就成为了新的Controller。
有一种特殊的情况,就是Controller节点并没有宕掉,而是因为网络的抖动,不稳定,导致和ZooKeeper之间的会话超时,那么此时,整个Kafka集群就会认为之前的Controller已经下线(退出)从而选举出新的Controller,而之前的Controller的网络又恢复了,以为自己还是Controller了,继续管理整个集群,那么此时,整个Kafka集群就有两个controller进行管理,那么其他的broker就懵了,不知道听谁的了,这种情况,我们称之为脑裂现象,为了解决这个问题,Kafka通过一个任期(epoch:纪元)的概念来解决,也就是说,每一个Broker当选Controller时,会告诉当前Broker是第几任Controller,一旦重新选举时,这个任期会自动增1,那么不同任期的Controller的epoch值是不同的,那么旧的controller一旦发现集群中有新任controller的时候,那么它就会完成退出操作(清空缓存,中断和broker的连接,并重新加载最新的缓存),让自己重新变成一个普通的Broker。
二、Kafka集成
2.1、大数据应用场景
只是记录常见的大数据应用场景,具体细节不做记录。
2.1.1、Flume集成
Flume也是日志采集器,类似于ELK中的LogStash软件功能。早期设计的功能就是通过Flume采集过来数据,然后将数据写入HDFS分布式文件存储系统,不过,随着功能的扩展,现在也可以把采集的数据写入到kafka当中,作为实时数据使用。
2.1.2、Spark集成
Spark是分布式计算引擎,是一款非常强大的离线分布式计算框架,其中的SparkStreaming模块用于准实时数据处理,其中就可以将Kafka作为数据源进行处理。
2.1.3、Flink集成
Flink是分布式计算引擎,是一款非常强大的实时分布式计算框架,可以将Kafka作为数据源进行处理。
2.2、Java应用场景(SpringBoot集成)
参考Springboot整合kafka简单使用。
三、Kafka常见问题
3.1、Kafka都有哪些组件?
参考kafka基础。
3.2、分区副本AR, ISR, OSR的含义?
这里的AR可以理解为分区的所有副本集合。而ISR表示的就是正在同步数据的副本列表,列表的第一个就是分区的Leader副本,其他的副本就是Follower副本。OSR就是没有处于同步数据的副本列表。一旦副本拉取数据满足了特定的条件,那么会从OSR中移除并增加到ISR中。同样,如果副本没有拉取数据满足了特定的条件,就会从ISR中移除,放入到OSR中。这就是所谓的ISR列表的收缩和扩张。kafka使用这种ISR的方式有效的权衡了数据可靠性和性能之间的关系。
3.3、Producer 消息重复或消息丢失的原因?
Producer消息重复和消息丢失的原因,主要就是kafka为了提高数据可靠性所提供的重试机制,如果禁用重试机制,那么一旦数据发送失败,数据就丢失了。而数据重复,恰恰是因为开启重试机制后,如果因为网络阻塞或不稳定,导致数据重新发送。那么数据就有可能是重复的。所以kafka提供了幂等性操作来解决数据重复问题,并且幂等性操作要求必须开启重试功能和ACK取值为-1,这样数据就不会丢失了。
kafka提供的幂等性操作只能保证同一个生产者会话中同一个分区中的数据不会重复,一旦数据发送过程中,生产者对象重启,那么幂等性操作就会失效。那么此时就需要使用Kafka的事务功能来解决跨会话的幂等性操作。但是跨分区的幂等性操作是无法实现的。
3.4、Consumer消息重复或消息丢失的原因?
这里主要说的是消费者提交偏移量的问题。消费者为了防止意外情况下,重启后不知道从哪里消费,所以会每5s时间自动保存偏移量。但是这种自动保存偏移量的操作是基于时间的,一旦未达到时间,消费者重启了,那么消费者就可能重复消费数据。
Kafka提供自动保存偏移量的功能的同时,也提供了手动保存偏移量的2种方式,一个是同步提交,一个是异步提交。本质上都是提交一批数据的最后一个偏移量的值,但是可能会出现,偏移量提交完毕,但是拉取的数据未处理完毕,消费者重启了。那么此时有的数据就消费不到了,也就是所谓的数据丢失。
3.5、Kafka数据如何保证有序?
这里的有序我们要考虑的点比较多,但是总结起来就是生产有序,存储有序和消费有序。
生产有序:生产者对象需要给数据增加序列号用于标记数据的顺序,然后在服务端进行缓存数据的比对,一旦发现数据是乱序的,那么就需要让生产者客户端进行数据的排序,然后重新发送数据,保证数据的有序。不过这里的缓存数据的比对,最多只能有5条数据比对,所以生产者客户端需要配置参数,将在途请求缓冲区的请求队列数据设置为5,否则数据依然可能乱序。因为服务端的缓存数据是以分区为单位的,所以这就要求生产者客户端需要将数据发送到一个分区中,如果数据发送到多个分区,是无法保证顺序的。
存储有序:kafka的服务端获取数据后会将数据顺序写入日志文件,这样就保证了存储有序,当然也只能是保证一个分区的数据有序。
消费有序:kafka在存储数据时会给数据增加一个访问的偏移量值,那消费者只能按照偏移量的方式顺序访问,并且一个分区的数据只能被消费者组中的一个消费者消费,那么按照偏移量方式的读取就不会出现乱序的情况。
所以综合以上的描述。Kafka就能够实现数据的有序。