在专栏前面的文章中，我们已经为大家介绍了kafka2.0和kafka 3.0(无需zookeeper)的安装方式，两种安装方式虽然发生了变化，但是在安装完成之后，面向开发人员几乎是没有变化的。所以验证集群的可用性方法也是一样的，本节可以通用。
文章目录- 一、集群安全性配置
- 二、Topic创建结果验证
- 创建topic
- 查看topic：test的详细信息
- 三、验证集群容错能力
- 3.1.正常生产消费测试
- 3.2.三个节点停掉一个就无法消费了？
- 3.3.为什么及如何配置
- 3.4.如何动态增加`__consumer_offsets`的分区数
在开始生产集群安全性验证之前，有必要说明的是：按照实际kafka生产环境的需求，我们的kafka集群还没有安装完成。
因为我们忽略了一个非常重要的问题就是：kafka集群的安全性，哪些用户可以访问集群？哪些用户可以访问哪些topic?这些问题都需要进行额外的安装配置，请关注本专栏的后续文章《kafka安全认证》，建议的使用的安全认证方式是《SCRAM认证》方式。因为那一部分相对于kafka开发者而言有点脱节，更多的是面向kafka系统管理员、运维人员的知识。所以本文暂且先不介绍。
二、Topic创建结果验证 创建topic首先要将集群启动起来，下面我们创建一个topic，使用下面的命令我们创建了一个只有1个分区、共2个分区副本的topic，名字叫做test
kafka-topics.sh --create --bootstrap-server zimug1:9092,zimug2:9092,zimug3:9092 --replication-factor 3 --partitions 1 --topic test
查看topic：test的详细信息注意我这里没有使用绝对路径 /home/kafka/kafka_2.13-2.8.0/bin/kafka-topics.sh，而是直接使用了kafka-topics.sh,是因为我在使用shell脚本安装的时候配置了环境变量。
kafka-topics.sh --bootstrap-server zimug1:9092,zimug2:9092,zimug3:9092 --describe -topic test
查看分区详情的显示信息如下
Topic: test TopicId: EDXcMbT7R7iY7JVCWMHNHA PartitionCount: 1 ReplicationFactor: 3 Configs: cleanup.policy=delete,flush.ms=1000,segment.bytes=1073741824,flush.messages=10000
Topic: test Partition: 0 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3
- Topic：名称test
- PartitionCount：分区数量1
- ReplicationFactor：分区副本共3个，含1个Leader分区副本2个Follower分区副本
- Partition: 0: 这一条记录分区编号0(一个分区编号从0开始)，如果有多个分区依次为：
- Leader: 1: 表示主分区在broker.id=1的节点上
- Replicas: 1,2,3: 表示分区的3个副本分别在broker.id=123的节点上
- Isr: 1,2,3: 表示3个分区副本都在Isr集合中，2个Follower与1个Leader数据处于同步状态。
我们来做这样一个实验
- 第一步：首先集群所有节点都正常状态下，保证生产消费正常
- 第二步：停掉Follower副本broker.id=3所在的服务器上的kafka进程，看看kafka生产者和kafka消费者是否正常消费；
- 第三步：再停掉Leader副本broker.id=1所在的kafka服务试一次，再看看生产消费状态。
我们期待的实验结果是：三个节点，停掉1个节点或者停掉2个节点，都不影响集群正常的接收生产者的消息，也不影响消费者进行消费。
3.1.正常生产消费测试在一台服务器上(kafka用户下)生产者发送数据：
> kafka-console-producer.sh --topic test --bootstrap-server zimug1:9092,zimug2:9092,zimug3:9092 hello test1 hello test2
在另一台服务器上(kafka用户下)消费者接受数据：
> kafka-console-consumer.sh --topic test --from-beginning --bootstrap-server zimug1:9092,zimug2:9092,zimug3:9092 hello test1 hello test2
能够正常的收发数据，证明集群所有节点都正常状态下，生产消费正常。如果不能正常检查自己的安装过程配置、集群是否启动、kafka服务日志(kafka_2.13-2.8.0/logs)等信息。
3.2.三个节点停掉一个就无法消费了？停掉Follower副本broker.id=2所在的服务器上的kafka进程，看看kafka生产者和kafka消费者是否正常消费。
kafka-server-stop.sh
如果我们此时再去查看test topic的分区情况，会发现Isr集合里面只剩去1，2号分区副本。
Topic: test Partition: 0 Leader: 1 Replicas: 1,2,3 Isr: 1,2
此时再去生产消费数据，可能出现2种结果：
- 生产者不受影响，消费者也可以消费
- 生产者不受影响，消费者不能消费到数据
2种结果可能随机出现。
3.3.为什么及如何配置为什么我们才停掉一个节点，集群就有可能无法正常消费了？ 这是因为kafka存在一个特殊的主题__consumer_offsets,这个主题用于保存其他的主题的生产数据及消费数据的进度offsets，这个主题有50个分区。核心问题默认情况下是它的分区副本因子是1，也就是说每个分区只有一个Leader副本。通过下列命令我们可以看到：
kafka-topics.sh --bootstrap-server zimug1:9092,zimug2:9092,zimug3:9092 --describe -topic __consumer_offsets
主题__consumer_offsets每个分区只有一个Leader，没有Follower副本。Replicas
isr副本数都是一个，所以一旦这个副本挂了，整个__consumer_offsets主题就挂掉了。
现在你的消息发往test主题（这一步没有问题），假设主题的数据生产进度偏移量需要保存到__consumer_offsets主题的5号分区，但是我们把broker.id=2的服务器停掉了，并且分区只有一个Leader，没有备份。生产者数据正常写入test主题，但是主题的生产进度偏移量需要更新到__consumer_offsets，生产数据的偏移量无法更新，消费者就不能消费这条数据。
所以为了保证集群的高可用
- 一是我们自己建的主题的分区要有多副本，创建主题时候指定参数--replication-factor n
- 二是主题__consumer_offsets的分区也要有多副本。比如做如下配置，设置副本因子为n，设置方法是配置如下参数。
# 创建topic时候，默认的分区数 num.partitions=3 # 允许默认创建Topic auto.create.topics.enable=true # __consumer_offsets的分区数设置（n>1,建议值3） offsets.topic.replication.factor=n
假如__consumer_offsets的分区包含n=3个副本，坏掉2个还可以继续工作，除非3个都坏掉！所以n越大，集群的高可用能力越强，但是在副本之间数据同步的角度来看资源耗费也越严重。
3.4.如何动态增加__consumer_offsets的分区数你会发现虽然我们做了配置修改，即使你重启了集群，__consumer_offsets主题的分区副本数仍然是1。因为上面提到的三个参数，是在__consumer_offsets主题初始化创建的时候生效(集群生产第一条消息的时候生效)。如果已经错过这个时间，我们想动态修改，需要实用下面的方法，首先新建一个JSON文件，比如叫offsets-topic.json
{
"version": 1,
"partitions": [
{
"topic": "__consumer_offsets",
"partition": 0,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 1,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 2,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 3,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 4,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 5,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 6,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 7,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 8,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 9,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 10,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 11,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 12,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 13,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 14,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 15,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 16,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 17,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 18,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 19,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 20,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 21,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 22,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 23,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 24,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 25,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 26,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 27,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 28,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 29,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 30,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 31,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 32,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 33,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 34,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 35,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 36,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 37,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 38,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 39,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 40,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 41,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 42,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 43,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 44,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 45,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 46,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 47,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 48,
"replicas": [1,2,3]
},
{
"topic": "__consumer_offsets",
"partition": 49,
"replicas": [1,2,3]
}
]
}
一共50个分区，每个分区三个副本分布在broker.id=1,2,3的三台服务器上，这就是上面的这个json文件的含义。把该文件放入$KAFKA_HOME/explain目录下。并在该目录下执行命令：
kafka-reassign-partitions.sh --bootstrap-server zimug1:9092,zimug2:9092,zimug3:9092 --reassignment-json-file ./offsets-topic.json --execute
这种通过json文件修改分区副本数量的方式，不仅适用于__consumer_offsets主题，也适用于其他的我们自建的主题。执行完成下面的命令之后可以使用下面的命令进行验证。
kafka-reassign-partitions.sh --bootstrap-server zimug1:9092,zimug2:9092,zimug3:9092 --reassignment-json-file ./offsets-topic.json --verify
如果验证的结果，每一个分区都是“is complete”，表示正确完成分区副本分配。（一共50个分区，我的截图碍于篇幅，只截了8个分区）
经过上面的配置，最终的实验结果将符合我们的期望：三个节点，停掉1个节点或者停掉2个节点，都不影响集群正常的接收生产者的消息，也不影响消费者进行消费。 即使停掉分区Leader副本，如果有Follower分区副本活着，就会重新选举Leader，除了会浪费一定的选举时间，集群整体上还是可用的。
