面试问Kafka，这一篇全搞定(3)

如图，因为前面提到过了消费者会直接和 Leader 建立联系，所以它们分别消费了三个 Leader，所以一个分区不会让消费者组里面的多个消费者去消费，但是在消费者不饱和的情况下，一个消费者是可以去消费多个分区的数据的。

Controller

熟知一个规律：在大数据分布式文件系统里面，95% 的都是主从式的架构，个别是对等式的架构，比如 ElasticSearch。

Kafka 也是主从式的架构，主节点就叫 Controller，其余的为从节点，Controller 是需要和 Zookeeper 进行配合管理整个 Kafka 集群。

Kafka 和 Zookeeper 如何配合工作

Kafka 严重依赖于 Zookeeper 集群，所有的 Broker 在启动的时候都会往 Zookeeper 进行注册，目的就是选举出一个 Controller。

这个选举过程非常简单粗暴，就是一个谁先谁当的过程，不涉及什么算法问题。

那成为 Controller 之后要做啥呢，它会监听 Zookeeper 里面的多个目录，例如有一个目录 /brokers/，其他从节点往这个目录上**注册(就是往这个目录上创建属于自己的子目录而已)**自己。

这时命名规则一般是它们的 id 编号，比如 /brokers/0,1,2。注册时各个节点必定会暴露自己的主机名，端口号等等的信息。

此时 Controller 就要去读取注册上来的从节点的数据(通过监听机制)，生成集群的元数据信息，之后把这些信息都分发给其他的服务器，让其他服务器能感知到集群中其它成员的存在。

此时模拟一个场景，我们创建一个主题(其实就是在 Zookeeper 上 /topics/topicA 这样创建一个目录而已)，Kafka 会把分区方案生成在这个目录中。

此时 Controller 就监听到了这一改变，它会去同步这个目录的元信息，然后同样下放给它的从节点，通过这个方法让整个集群都得知这个分区方案，此时从节点就各自创建好目录等待创建分区副本即可。这也是整个集群的管理机制。

加餐时间

Kafka 性能好在什么地方?

①顺序写

操作系统每次从磁盘读写数据的时候，需要先寻址，也就是先要找到数据在磁盘上的物理位置，然后再进行数据读写，如果是机械硬盘，寻址就需要较长的时间。

Kafka 的设计中，数据其实是存储在磁盘上面，一般来说，会把数据存储在内存上面性能才会好。

但是 Kafka 用的是顺序写，追加数据是追加到末尾，磁盘顺序写的性能极高，在磁盘个数一定，转数达到一定的情况下，基本和内存速度一致。

随机写的话是在文件的某个位置修改数据，性能会较低。

②零拷贝

先来看看非零拷贝的情况：

可以看到数据的拷贝从内存拷贝到 Kafka 服务进程那块，又拷贝到 Socket 缓存那块，整个过程耗费的时间比较高。

Kafka 利用了 Linux 的 sendFile 技术(NIO)，省去了进程切换和一次数据拷贝，让性能变得更好。

（编辑：ASP站长网）