Kafka的灵魂伴侣Logi-KafkaManger（一）

最新推荐文章于 2024-09-22 18:10:40 发布

weixin_42073629

最新推荐文章于 2024-09-22 18:10:40 发布

阅读量175

点赞数

分类专栏： Kafka

本文链接：https://blog.csdn.net/weixin_42073629/article/details/116100534

版权

Kafka 专栏收录该内容

43 篇文章 5 订阅

订阅专栏

接下来第一步肯定就是接入现有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申请