首页 > MQ > 基础概念、架构和新版的升级-Kafka知识体系(一)
2019
02-06

基础概念、架构和新版的升级-Kafka知识体系(一)

概念

    Kafka 是一种高吞吐量、分布式、基于发布/订阅的消息系统,最初由 LinkedIn 公司开发,使用 Scala (JAVA)语言编写,目前是Apache 的开源项目。

    主要解决应用解耦、异步消息、流量削峰等问题。

    Kafka实际上也是一个主从架构,有一个Controller角色即控制器,协调管理整个集群。

关键术语

broker

Kafka 服务器,负责消息存储和转发。

topic

消息类别,Kafka 按照topic 来分类消息;似于关系型数据库的表。

partition

topic 的分区,一个 topic 可以包含多个 partition ,topic 消息保存在各个 partition 上。

offset

消息在日志中的位置,可以理解是消息在partition 上的偏移量,也是代表该消息的唯一序号。

Producer

消息生产者,将消息push到Kafka集群中的Broker。

Consumer

消息消费者,从Kafka集群中pull消息,消费消息。

Consumer Group

消费者分组,每个Consumer 必须属于一个group

Zookeeper

保存着集群broker、topic、partition 等meta 数据;另外,还负责broker 故障发现,partition leader 选举,负载均衡等功能。

从抽象到具体理解Kafka架构设计

从宏观的层面来理解,它就是一个存储系统。

image.png

细分一下,又有多个生产者,多个消费者,Broker 集群和Kafka 组成。

image.png

再次细分,broker有一个controller角色,每一个broker 可能存多个Topic的不同partion,每个partion 都有 leader 和follower 。这些信息都会注册到zk上。

image.png

控制器 controller

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

kafka也是主从式的架构,主节点就叫controller,其余的为从节点,controller是需要和zookeeper进行配合管理整个kafka集群。

作用

协调与管理整个集群。

职责

    主题增删改

    分区重分配

    leader选举

    元数据管理

    broker成员管理,宕机或加入

控制器选举

基于zookeeper实现,利用了zookeeper的znode模型与监听机制。

控制器故障转移

存在单点故障,但是每个broker节点都可以成为controller;

故障转移即failover也是基于zookeeper实现的,znode模型与监听机制,/controller节点。

kafka和zookeeper如何配合工作

    kafka严重依赖于zookeeper集群。

    所有的broker在启动的时候都会往zookeeper进行注册,目的就是选举出一个controller

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

    成为controller之后,它会监听zookeeper里面的多个目录.

    注册时各个节点必定会暴露自己的主机名,端口号等等的信息,此时controller就要去读取注册上来的从节点的数据(通过监听机制),生成集群的元数据信息,之后把这些信息都分发给其他的服务器,让其他服务器能感知到集群中其它成员的存在。

新版Kafka将要抛弃ZooKeeper!!!!!!

2021年3月30日,Kafka背后的企业Confluent发布博客表示,在即将发布的 2.8 版本里,用户可在完全不需要 ZooKeeper 的情况下运行 Kafka,该版本将依赖于 ZooKeeper 的控制器改造成了基于 Kafka Raft 的 Quorm 控制器。

在之前的版本中,如果没有 ZooKeeper,Kafka 将无法运行。但管理部署两个不同的系统不仅让运维复杂度翻倍,还让 Kafka 变得沉重,进而限制了 Kafka 在轻量环境下的应用,同时 ZooKeeper 的分区特性也限制了 Kafka 的承载能力。

第一次,用户可以在没有 ZooKeeper 的情况下运行 Kafka。

这是一次架构上的重大升级,让一向“重量级”的 Kafka 从此变得简单了起来。轻量级的单进程部署可以作为 ActiveMQ 或 RabbitMQ 等的替代方案,同时也适合于边缘场景和使用轻量级硬件的场景。

为什么要抛弃使用了十年的 ZooKeeper?

zk的缺点:

    zookeeper 的一个缺点就是 同步数据不能太大。

    zookeeper集群中leader和follower同步数据的极限值是500M,这500M的数据,加载到内存中,大约占用3个G的内存。

    数据过大,在每次选举之后,需要从server同步到follower,容易造成下面2个问题:

        触发重新选举    

        io 太久

ZooKeeper 充当 Kafka 的领导者,以更新集群中的拓扑更改;根据 ZooKeeper 提供的通知,生产者和消费者发现整个 Kafka 集群中是否存在任何新 Broker 或 Broker 失败。大多数的运维操作,比如说扩容、分区迁移等等,都需要和 ZooKeeper 交互。

也就是说,Kafka 代码库中有很大一部分是负责实现在集群中多个 Broker 之间分配分区(即日志)、分配领导权、处理故障等分布式系统的功能。而早已经过业界广泛使用和验证过的 ZooKeeper 是分布式代码工作的关键部分。

假设没有 ZooKeeper 的话,Kafka 甚至无法启动进程,但严重依赖 ZooKeeper,也给 Kafka 带来了掣肘。

不过目前大部分用的还是和zk结合版本的kafka。


本文》有 0 条评论

留下一个回复