文章目录

一、Kafka Controller简介

kafka集群会选举出一个称为Controller的节点,主要有以下几种作用:

  • 主题管理:创建、删除主题等等
  • 重分区:前面脚本执行分区就是靠控制器实现的
  • 集群成员管理:broker新增、关闭、宕机
  • 数据管理:元数据管理。

目前对Controller的了解不多,我们在进行prometheus监控的时候发现,只有controller节点才可以获取partition的数据,也许就和controller的功能有关。

二、节点宕机变化过程

1、查看controller节点

进入zookeeper机器,进入bin,启动./zkCli.sh

$ ls /
$ get /controller

可以得到zookeeper上注册的kafka controller信息:

{"version":1, "brokerid":1, "timestamp":"1578635987138"}

2、查看当前主题分区情况

./kafka-topics.sh --describe --zookeeper zookeeper1.tplinknbu.com |grep subsub

例如一个主题tpc.subunsub:

分区数量12个,副本因子3,列出了每个分区中的Leader(可以看出是轮换的)。分区中的所有副本称为AR(Assigned Repllicas, AR),Follower副本总是去同步Leader副本,且有一定滞后。所有与Leader副本保持一定程度同步的副本都称为同步副本(In-Sync Replicas, ISR),而同步程度滞后过多的副本称为失步副本(Out-Sync Replicas)。只有ISR有资格被选举为Leader。可以看出,这里都是同步副本。

3、停止节点2(非Controller节点)

我们停止节点2,现象:

(1)Controller没有变化

(2)kafka仍然可用,且使用Spring kafka的业务不会抛出异常

(3)节点2从ISR中被剔除,且没有资格再成为Leader

Leader: 3 Replicas: 2,3,1 Isr: 3,1

4、再次启动节点2

(1)刚启动的时候,节点2立刻同步到ISR状态,但Leader没有变化

Leader: 3 Replicas: 2,3,1 Isr: 3,1,2
Leader: 3 Replicas: 3,1,2 Isr: 3,1,2
……

(2)过一段时间,自动均匀分布Leader。

Leader: 2 Replicas: 2,3,1 Isr: 3,1,2
Leader: 3 Replicas: 3,1,2 Isr: 3,1,2
……

5、Controller节点宕机

我们停止Controller节点1,现象:

(1)zookeeper上的controller值立刻变为3,但version没有变化(version固定为1,controller_epoch才会随着每次控制器变化而+1)

{"version":1, "brokerid":3, "timestamp":"1582545775134"}

(2)Isr有一些残留,但Leader全部剔除1

Leader: 2 Replicas: 2,3,1 Isr: 3,1,2
Leader: 3 Replicas: 3,1,2 Isr: 2,3
……

(3)一段时间后,Isr仍然残留有1(应该是对于没有太大变化的partition,仍然认为是同步的)

6、Controller节点恢复

类似节点2启动,只是此时节点1已经是普通节点。

(1)刚启动时,迅速同步到ISR中

(2)过一段时间,均匀分布Leader。

三、不停机磁盘扩容

这里以AWS的EC2机器为例:

1、修改卷大小

(1)点击EC2下面的详细信息的跟设备的EBS ID,跳转到卷列表

(2)点击修改卷,修改为想要的大小,例如50GB

2、主机内扩容

修改完毕后,进入主机,根据官方文档《Extending a Linux File System After Resizing a Volume》找到具体扩容命令,例如m5.large的为:

sudo growpart /dev/nvme0n1 1
sudo resize2fs /dev/nvme0n1p1

磁盘的名称可以通过:

$ lsblk

来查看。

3、确认修改完成

$ df -lh

四、停机修改实例规模

修改实例规模必须要停机,好在kafka集群可以提供高可用,需要注意不要在波峰的时候去停机,多观察消费情况,避免停机一台造成另外两台收到大量请求宕机导致整个集群都宕机…

可以采取"创建1台、再停机1台"的方式,尽量避免“停机1台,扩容,再启动”的方式。

EC2修改很简单,只需要点右键修改实例规模即可。

五、有关kafka磁盘估算

kafka的磁盘收到3个因素影响:

(1)每个patition最大大小

(2)删除策略

(3)主题数量及patition个数

对于第1个,通常设置1GB没问题;

对于第2个,通常设置都是24小时或者默认7天进行清理,清理方式通常都是删除(也可以设置为压缩,但建议删除)

对于第3个,很关键,一定要注意最后的最大磁盘使用量是(所有主题对应partition个数之和)×每个partition最大大小。

我最开始误以为是partition个数×每个partition最大大小,于是给了50GB,性能测试很快就满了。

仔细想一想也可以知道,partition个数是可以每个主题不同的,所以最后应该是所有主题的partition个数加起来再乘以partition最大大小。


转载请注明出处http://www.bewindoweb.com/289.html | 三颗豆子
分享许可方式知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议
重大发现:转载注明原文网址的同学刚买了彩票就中奖,刚写完代码就跑通,刚转身就遇到了真爱。
你可能还会喜欢
具体问题具体杠