一、 Kafka、ZooKeeper 的分布式消息队列系统总体架构
典型的 Kafka 体系架构包括若干 Producer（消息生产者），若干 Broker（作为 Kafka 节点的服务器），若干 Consumer （Group），以及一个 ZooKeeper 集群。
Kafka 通过 ZooKeeper 管理集群配置、选举 Leader，并在 Consumer Group 发生变化时进行 Rebalance（即消费者负载均衡）。Producer 使用 Push（推）模式将消息发布到 Broker，Consumer 使用 Pull（拉）模式从 Broker 订阅并消费消息。
Kafka 节点涉及 Topic、Partition 两个重要概念。
在 Kafka 架构中，有几个术语需要了解下。
- Producer： 生产者，即消息发送者，Push 消息到 Kafka 集群的 Broker（就是 Server）中； Broker：
Kafka 集群由多个 Kafka 实例（Server）组成，每个实例构成一个 Broker，其实就是服务器； - Topic： Producer 向 Kafka 集群 Push 的消息会被归于某一类别，即
Topic。本质上，这只是一个逻辑概念，面向的对象是 Producer 和 Consumer，Producer 只需关注将消息 Push
到哪一个 Topic 中，而 Consumer 只需关心自己订阅了哪个 Topic； - Partition： 每个 Topic 又被分为多个 Partition，即物理分区。出于负载均衡的考虑，同一个 Topic 的
Partition 分别存储于 Kafka 集群的多个 Broker 上。而为了提高可靠性，这些 Partition 可以由 Kafka
机制中的 Replicas 来设置备份的数量。如上面框架图所示，每个 Partition 都存在两个备份； - Consumer： 消费者，从 Kafka 集群的 Broker 中 Pull 消息、消费消息；
- Consumer Group： High-Level Consumer API 中，每个 Consumer 都属于一个 Consumer
Group，每条消息只能被 Consumer Group 中的一个 Consumer 消费，但可以被多个 Consumer Group 消费； - Replicas： Partition 的副本，保障 Partition 的高可用；
- Leader： Replicas 中的一个角色， Producer 和 Consumer 只与 Leader 交互；
- Follower： Replicas 中的一个角色，从 Leader 中复制数据，作为它的副本，同时一旦某 Leader
挂掉，便会从它的所有 Follower 中选举出一个新的 Leader 继续提供服务； - Controller： Kafka 集群中的一个服务器，用来进行 Leader Election 以及各种 Fail Over；
Zookeeper： Kafka 通过 ZooKeeper 存储集群的 Meta 信息等，文中将详述。
Kafka、ZooKeeper 的分布式消息队列系统总体架构已经简单了解啦，接下来开始上干货！
二、部署nfs-provisioner 实现PV 动态供给（StorageClass）
nfs-provisioner 直通车链接
三、集群部署
# 操作系统
# CentOS Linux release 7.9.2009 (Core)
lsb_release -a
# 内核版本
# 3.10.0-1160.90.1.el7.x86_64
uname -a
# k8s 版本 1.21
# zookeeper 版本 3.4.10
# kafka 版本 3.5.2
一、Zookeeper on k8s 部署
k8s官网参考链接
zookeeper.yaml
apiVersion: v1
kind: Service
metadata:
name: zk-hs
labels:
app: zk
spec:
ports:
- port: 2888
name: server
- port: 3888
name: leader-election
clusterIP: None
selector:
app: zk
---
apiVersion: v1
kind: Service
metadata:
name: zk-cs
labels:
app: zk
spec:
ports:
- port
