【kafka专栏】kafka集群可用性验证与配置-为主题增加分区数

在专栏前面的文章中，我们已经为大家介绍了kafka2.0和kafka 3.0(无需zookeeper)的安装方式，两种安装方式虽然发生了变化，但是在安装完成之后，面向开发人员几乎是没有变化的。所以验证集群的可用性方法也是一样的，本节可以通用。

一、集群安全性配置

在开始生产集群安全性验证之前，有必要说明的是：按照实际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
1
2
3
4

注意我这里没有使用绝对路径 /home/kafka/kafka_2.13-2.8.0/bin/kafka-topics.sh，而是直接使用了kafka-topics.sh,是因为我在使用shell脚本安装的时候配置了环境变量。

查看topic：test的详细信息

kafka-topics.sh --bootstrap-server zimug1:9092,zimug2:9092,zimug3:9092 --describe -topic test
1

查看分区详情的显示信息如下

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
1
2

• Topic：名称test
• PartitionCount：分区数量1
• ReplicationFactor：分区副本共3个，含1个Leader分区副本2个Follower分区副本
• Partition: 0: 这一条记录分区编号0(一个分区编号从0开始)，如果有多个分区依次为：<Partition: 1> 、<Partition: 2>，以此类推。
• Leader: 1: 表示主分区在broker.id=1的节点上
• Replicas: 1,2,3: 表示分区的3个副本分别在broker.id=1\2\3的节点上
• 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
1
2
3
4

在另一台服务器上(kafka用户下)消费者接受数据：

> kafka-console-consumer.sh --topic test --from-beginning --bootstrap-server zimug1:9092,zimug2:9092,zimug3:9092

hello test1
hello test2
1
2
3
4

能够正常的收发数据，证明集群所有节点都正常状态下，生产消费正常。如果不能正常检查自己的安装过程配置、集群是否启动、kafka服务日志(kafka_2.13-2.8.0/logs)等信息。

3.2.三个节点停掉一个就无法消费了？

停掉Follower副本broker.id=2所在的服务器上的kafka进程，看看kafka生产者和kafka消费者是否正常消费。

kafka-server-stop.sh
1

如果我们此时再去查看test topic的分区情况，会发现Isr集合里面只剩去1，2号分区副本。

Topic: test     Partition: 0    Leader: 1       Replicas: 1,2,3 Isr: 1,2
1

此时再去生产消费数据，可能出现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
1

主题__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
1
2
3
4
5
6

假如__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]
        }
    ]
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255

一共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
1
2
3

这种通过json文件修改分区副本数量的方式，不仅适用于__consumer_offsets主题，也适用于其他的我们自建的主题。执行完成下面的命令之后可以使用下面的命令进行验证。

kafka-reassign-partitions.sh \
--bootstrap-server zimug1:9092,zimug2:9092,zimug3:9092 \
--reassignment-json-file ./offsets-topic.json --verify
1
2
3

如果验证的结果，每一个分区都是“is complete”，表示正确完成分区副本分配。（一共50个分区，我的截图碍于篇幅，只截了8个分区）

经过上面的配置，最终的实验结果将符合我们的期望：三个节点，停掉1个节点或者停掉2个节点，都不影响集群正常的接收生产者的消息，也不影响消费者进行消费。 即使停掉分区Leader副本，如果有Follower分区副本活着，就会重新选举Leader，除了会浪费一定的选举时间，集群整体上还是可用的。