Category Archives: Hadoop

Kafka涉及到的多种选举机制

提起Kafka中的选举,第一印象肯定是broker节点之间的选举,它依赖于Zookeeper来进行选举,其实还有partition之间也有选举,以及其他地方都存在选举,但这些都是由Kafka内部完成,它们都需要一个leader来把控全场,由leader来负责读写请求,处理消息的同步,监听分区变化,监听主题变化,保存一些分区方案,记录消费位移等信息。我总结的有以下几种选举。

使用CyclicBarrier控制Kafka多线程消费消息的位移提交问题

Kafka中消费者是线程不安全的,一个topic只能被一个消费组中的消费者消费,想要提高数据消费能力,可以增加分区数,因为消费者数可以和分区数进行对应,当消费者数大于分区数时,多余的消费者将处于空闲状态,或者也可以在每个线程中创建一个消费者实例,这样也可以对数据来处理,但创建多个消费者实例必然会造成资源的浪费。通过线程池来对数据进行消费,就会存在位移提交的问题,从而引发数据丢失或重复,所以对位移的提交要格外处理,消费者默认是定时提交位移信息的,如果需要手动提交,要先修改配置参数关闭自动提交,再通过代码里调用commitSync()方法。

Kafka中再均衡的发生过程

Kafka中消费者以消费组的形式存在,消费组来消费每个主题中分区的数据,因为主题中的分区数和消费者数量并不一一对应,这时候就涉及到如何为每个消费者分配分区,而当有消费者在中途退出时,就会触发再均衡的发生,再重新为剩余的消费者分配分区。每个消费组在服务端对应一个GroupCoordinator对其进行管理,而消费者客户端中的ConsumerCoordinator组件负责与GroupCoordinator进行交互,它们负责执行分区的分配,以及消费者再均衡的操作。

对于mysql,redis,Kafka,zookeeper磁盘缓存技术使用分析

大部分组件是基于磁盘存储的,但由于CPU速度和磁盘速度之间的鸿沟,都会使用缓存技术来提高性能,缓存简单来说就是一块内存区域,首先将从磁盘读到的数据放在缓存中,之后查询或修改时直接操作缓存,对于缓存中的数据则以一定的频率刷新到磁盘上,怎样缓存,缓存多少,何时刷新,这些影响着整个组件的性能。在看过一些关于mysql等组件的架构原理后,会发现不论是基于磁盘的mysql数据库和Kafka消息中间件zookeeper分布式协调框架,还是基于内存的redis数据库,它们都设计了完善的内存和磁盘之间数据交互实现。

测试单节点Kafka在Zookeeper关闭后的运行状态和请求响应状态

这个问题是在一次面试的时候面试官问的,当时确实懵了,只能模糊的去描述zookeeper关闭后的kafka 状态,自己并不非常肯定,回来之后一直想亲自试验一下,今天刚好搭了一个单节点的Kafka和单节点的zookeeper,之后有时间再去分别测试集群版环境的响应情况。

Kafka的主题删除机制

命令删除 在Kafka中当一个主题不再使用的时候,可以选择将其删除,以此来释… Read More »

Kafka connect快速构建数据ETL通道

一.背景介绍 Kafka connect是Confluent公司(当时开发出Apache Kafka的核心团队成员出来创立的新公司)开发的confluent platform的核心功能… Read More »