点一下关注吧!!!非常感谢!!持续更新!!!
目前已经更新到了:
- Hadoop(已更完)
- HDFS(已更完)
- MapReduce(已更完)
- Hive(已更完)
- Flume(已更完)
- Sqoop(已更完)
- Zookeeper(已更完)
- HBase(已更完)
- Redis (已更完)
- Kafka(正在更新…)
章节内容
上一节我们完成了如下的内容:
现实业务中我们会遇到:当Kafka集群中有一个节点宕机了,比如Broker0、Broker1中,Broker1宕机了,此时由于我们配置了副本数为2,Kafka集群正常工作,提供生产和消费能力。
但是当我们修好Broker1之后,恢复宕机之后,发现Leader都是Broker0,不会再平衡到Broker1上,所以我们需要用脚本来让Kafka集群进行自动再平衡。
- Kafka自动再平衡
- 新建主题
- 查看主题
- 模拟宕机
- 重启节点
- 编写JSON
- 测试运行
分区(Partition)
Kafka 中的每个主题(Topic)都可以分为多个分区。分区是 Kafka 实现可扩展性和高吞吐量的关键机制。每个分区可以看作是一个有序的消息队列,消息在分区内按写入顺序进行存储,并且每个消息都会分配一个唯一的偏移量(Offset)。
分区优势
- 并行处理:通过将主题分为多个分区,Kafka 可以在多台服务器上并行处理消息,从而提高系统的吞吐量。
- 负载均衡:消费者组中的不同消费者可以消费不同的分区,从而实现负载均衡。
- 水平扩展:当需要处理更多的消息时,可以通过增加分区来扩展 Kafka 集群的容量。
副本因子(Replication Factor 或者 Replicas)
副本因子表示每个分区在 Kafka 集群中的副本数量。每个分区的副本包括一个首领副本(Leader)和多个追随者副本(Follower)。
- Leader:Leader 是分区的主要副本,负责处理所有的读写请求。
- Follower:Follower 是 Leader 的备份副本,它们会同步 Leader 的数据,但不会直接处理客户端的请求。只有当 Leader 出现故障时,Follower 才会成为新的 Leader。
副本因子作用
- 容错性:副本因子提供了容错能力。当一个节点发生故障时,Kafka 可以通过选举新的 Leader 来保证数据的可用性。
- 高可用性:即使集群中的部分节点不可用,Kafka 依然能够确保数据的可用性和持久性。
- 副本因子的选择:副本因子通常设置为 3,这意味着每个分区有 3 个副本。这样即使有一个副本节点宕机,系统仍然能保证数据的安全性和服务的连续性。
工作原理
在 Kafka 中,当一个消息写入到某个分区时,首先会写入到该分区的 Leader 副本中,然后 Leader 会将该消息同步到所有的 Follower 副本。当所有的 Follower 都成功同步后,该消息才被认为是提交成功的(即对消费者可见)。
通过分区和副本因子,Kafka 实现了数据的高可用性和高性能处理能力。在实际应用中,合理配置分区和副本因子对于 Kafka 集群的性能和稳定性至关重要。
修改分区副本
现实业务中与实际项目中,我们可能由于主题的副本因子设置问题,需要重新设置副本因子。
由于集群的扩展,需要重新设置副本因子。
Topic一旦使用又不能轻易删除重建,因此动态增加副本因子就成为最终的选择。
背景情况
假设我们有两个KafkaBroker分别为:Broker0、Broker1
- 当我们创建Topic有2个分区,并且replication-factor为1,基本一个Broker一个分区。
- 当一个分区宕机了,该Topic就无法使用了,因为两个分区中只有一个可以使用
- 当我们创建的Topic有3个分区时,replication-factor为2时,可能分区数据分布情况是:[broker0,partition0,partition1,partition2] 和 [broker1,partition1,partition0,partition2]
- 每个分区有一个副本,当其中一个Broker宕机了,Kafka集群还能完整的凑出该Topic的两个分区,例如当Broker0宕机了,可以通过Broker1组合出Topic的两个分区。
启动服务
确保你有两台节点是可以正常使用的:
我这里是h121和h122
kafka-server-start.sh /opt/servers/kafka_2.12-2.7.2/config/server.properties
h121
h122
创建主题
kafka-topics.sh --zookeeper h121.wzk.icu:2181 --create --topic topic_test_02 --partitions 3 --replication-factor 1
运行结果如下图:
查看主题
kafka-topics.sh --zookeeper h121.wzk.icu:2181 --describe --topic topic_test_02
运行结果如下图:
可以看到跟我们的上一个实验的开头分配情况是一致的。
修改副本因子(不允许)
尝试修改
# 刚才 --create的时候 --replication-factor是1
kafka-topics.sh --zookeeper h121.wzk.icu:2181 --alter --topic topic_test_02 --replication-factor 2
我们可以观察到,是不允许我们这样操作的:
那如果我们业务上要求我们修改副本因子,我们该怎么办呢?
下面提供一个可行的方案。
修改副本因子
编写JSON
所以我们需要借助 kafka-reassign-partitions.sh
新建一个文件,这里的JSON在replicase里写入了多个:
vim topic_test_02_increment-replication-factor.json
{
"versions": "1",
"partitions": [
{
"topic": "topic_test_02", "partition": 0, "replicas": [0,1]
},
{
"topic": "topic_test_02", "partition": 1, "replicas": [0,1]
},
{
"topic": "topic_test_02", "partition": 2, "replicas": [1,0]
}
]
}
我们写入的内容如下:
执行JSON
kafka-reassign-partitions.sh --zookeeper h121.wzk.icu:2181 --reassignment-json-file topic_test_02_increment-replication-factor.json --execute
观察执行的结果如下:
查看结果
kafka-topics.sh --zookeeper h121.wzk.icu:2181 --describe --topic topic_test_02
执行的结果如下图所示:
可以看到,我们的副本数已经是 01、01、10了,此时就算 h121 或者 h122 中有一台节点挂掉了,我们也可以继续进行消费!