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，之后有时间再去分别测试集群版环境的响应情况。