一、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最大大小。