Kafka 的灵魂伴侣 LogiKM(1) 之集群的接入及相关概念讲解

作者：Kafka中文社区

2022 年 1 月 05 日
本文字数：2717 字
阅读完需：约 9 分钟

温馨提示: 如有排版问题可访问：

Kafka的灵魂伴侣LogiKM(1)之集群的接入及相关概念讲解

前言

今天新开了专栏 :【Kafka 的灵魂伴侣 LogiKM】

前言
正文
接入集群
基本信息展示
创建 Region 和逻辑集群
创建一个普通用户
普通用户申请应用
普通用户申请 Topic
运维人员审核 Topic
文章列表

在阅读此文前,您可以先按照文档 Logi-KafkaManager 的部署. 自己搭建一下项目;

那么运维管理人员搭建好了平台之后,接下来要做什么呢？

正文

阅读完本文,你讲了解到以下内容

[x] 接入集群步骤
[x] Region、逻辑集群、物理集群等相关概念
[x] Topic 的申请流程

接下来第一步肯定就是接入现有 kafka 集群了; 那么本篇文章就来讲解一下集群的接入;

接入集群

参数描述

数据中心默认国内; 这个也只是一个划分数据的维度,这个应该是滴滴内部有多个数据中心的缘故集群类型无效,后续会去掉安全协议 TODO JMX 认证 JMX 的认证鉴权, 如果 kafka 没有开认证的话就不需要填写 3、解决方法 —— 认证的 JMX JMX 端口记得要开起来,不然很多数据会没有 JMX-连接失败问题解决

接入成功之后可以看见接入的物理集群; 列表中展示了一些基本信息，可能会有一分钟的延迟

基本信息展示

点进刚刚接入的集群可以有很多集群信息的展示; 这些放在后面去讲,我们着重讲解一下两个模块 Region 信息和逻辑集群信息

创建 Region 和逻辑集群

在这之前. 我们先去了解一下官方的相关概念 Logi-KafkaManager 主要概念讲解

面对大规模集群、业务场景复杂的情况。引入 Region、逻辑集群的概念这也是滴滴在长期实践沉淀下来的经验。

在这里插入图片描述

Region: 划分部分 Broker 作为一个 Region，用 Region 定义资源划分的单位，提高扩展性和隔离性。如果部分 Topic 出现异常也不会影响大面积的 Broker。比如，右图中，将部分 Broker 划分为一个 Region，当某个 Topic 发送异常时，影响范围就会被限制在它所属的 Region 里。

逻辑集群: 将部分 Region 划分为逻辑集群，便于对大规模集群按照业务划分、保障能力的划分。

我们来举几个显示场景的例子;

对于小规模集群来说:

一般可能也就只部署了一套 kafka 的物理集群; 一套 kafka 集群可能也就 3~5 个 broker; 所有业务公用一套集群; 对于这样的场景来说,也就没有必要那么复杂的化分 Region 和逻辑集群；我们可以直接让 Region = 逻辑集群 = 物理集群;

创建 Region

PS: 这里的状态下拉还有一个磁盘已满的选项; 这里先忽略他的作用,直接填写正常就行;

创建逻辑集群(逻辑集群需要先有配置 Region)

逻辑集群标识: 作为逻辑集群的唯一标识; RegionIdList: 选择 Region 列表,比如刚刚我们创建好的 common_region 出现在下拉框中;我们选择这个 Region;

集群类型： 独享集群: 在物理集群中为某一应用单独划分部分 Region 作为独享集群。只能该应用使用。 独立集群: 为某一应用部署单独的物理集群。只能该应用使用。 共享集群: 划分部分 Region 作为共享集群。所有应用皆可使用。

对于小集群来说; 我们选择共享集群就可以了因为其他模式是需要绑定到具体应用的;

中大规模集群如何划分好 Region 和逻辑集群

我们假设一个场景; 某个企业 kafka 有 N 个物理集群; 其中有一个共享的物理集群 broker=20; 公司研发部门的所有应用都接入到了这个集群中 ; 正常情况下他们是这样的

那么在 KafkaManager 中曾加了 Region 和逻辑集群的概念之后; 可以这样子划分;

这样划分好了之后, 各个业务线中的 Topic 申请的时候就，运维管理员审核的时候就根据研发人员所填信息,然后进行 Region 的分配;

这样划分之后有几个明显的好处：

隔离性 不同应用的 Topic 散落到的 Broker 更集中; 同时也可以减少 Broker 之间的通信; 假如一个应用 App-1 接入的所有 Topic，都在这 20 个 Broker 有分区; （例如 TopicA 分区到了 123，TopicB 分区到了 456...）; 那么这种情况下,应用 App-1 在发送的时候是不是需要跟这 20 个 Broker 都有通信; 那么假如 App-1 的所有 Topic 的创建都只在 Broker 1,2,3 中,那么这个连接数就会减少
集群稳定性 避免小部分异常扩展到更大范围的异常,比如某个 Broker 不可用,那么影响的的范围会被控制在这个 Broker 所属的 Region 中的系统;
运维友好性 运维对于整个集群有了更清晰的了解和更有力的掌控; 根据业务划分、保障等级等来划分逻辑集群; 然后可以有针对性的做一些伸缩扩容等操作;

划分好 region 和逻辑集群之后, 接下来的操作;就是用户管理应用申请 Topic 申请

创建一个普通用户

运维管理员新建一个普通用户角色的用户;

普通用户可以登录系统做一下应用申请 Topic 申请等操作

普通用户申请应用

关于用户角色相关解释请看 Kafka 的灵魂伴侣 Logi-KafkaManger(5)之运维管控–平台管理(用户管理和平台配置)

普通用户登录账户后, 申请一下自己的系统

运维管理员审核通过之后

普通用户申请 Topic

在这里插入图片描述

普通用户申请 Topic 的时候会选择指定的逻辑集群; 和 Topic 归属于哪个应用; 运维管理人员会根据逻辑集群和所属应用来帮你划分好 Topic 最终会落在哪个 Region 或者 Broker 中;

峰值流量: 指的是 Topic 的最大生产/消费速率

其实这里只是一个展示项; 普通用户创建 Topic 的时候自己评估最大的生产速率是多少, 运维人员根据这个速率对这个 Topic 进行分区,如果速率大一点可能分配的分区数也更多一点；那么填写的速率和分区数应该怎么对于起来呢？这就需要用户自身来评判了, 毕竟每台 Broker 的性能配置啥的都不一样; 比如: 普通用户创建 Topic 的时候预估了一下,这个 topic 一条消息 102kb; 最大峰值的时候可能每秒会产生 10000 条数据; 那么峰值流量就是 102kb*10000/s 就约等于 1000Mb/s 了; 假如运维人员根据自己的经验或者压测结果得知一台 XX 配置的服务器最大写入速率在 300MB/s; 那么运维人员审核的时候就知道该 topic 至少要 4 台这样配置的 broker;

注意：这里并不是真正设置限流的地方; 只是作为一个分配分区数的参考值; 并没有把配额信息写入到 zk 中 那么哪里可以去设置 Topic 的生产/消费的限流呢？Kafka 的灵魂伴侣 Logi-KafkaManger(2)之 kafka 针对 Topic 粒度的配额管理(限流)

运维人员审核 Topic

运维人员根据自身对 Kafka 集群的划分,选择对应的 Region 或者 Broker 比如这个 topic 是归属于系统 a 的，刚刚我们划分的时候把它划分给了 Region1 中；那么审核的时候选择对应的 Region；当然也可以直接指定 Broker;

在这里插入图片描述

Topic 审核通过之后, 就会去选中的 Broker 中 create 对应的 Topic; 这样 Topic 的创建被 KM 管理了之后,就会限定在指定的 Region 或者 Broker 中了;

PS: 只是在平台创建 Topic 的时候会被限制在指定的 Broker 中; 但是如果你直接用 kafka 提供的工具去创建 Topic 或者开启了 Broker 的自动创建 Topic 功能，那还是不会被限制在我们的 Broker 中的; 所以建议关闭 Broker 中的的自动创建 Topic 功能。