Kafka 集群架构设计
多 Broker 架构
- 多 Broker 部署：部署多个 Broker，形成一个集群。即使部分 Broker 失效，其余的 Broker 仍能继续提供服务。
- 分区副本：每个 Topic 的分区都有多个副本（replicas），通常至少有一个副本处于不同的机器上。这样即使某台机器宕机，其他副本仍然可用。
复制因子
- 复制因子（Replication Factor）：设置分区的复制因子大于 1，以确保每个分区都有多个副本。例如，复制因子设置为 3，则每个分区会有 3 个副本分布在不同的 Broker 上。
- ISR（In-Sync Replicas）：ISR 是指与 Leader 保持同步的副本集合。确保 ISR 中有足够的副本，以防止 Leader 故障时无法选出新的 Leader。
集群分区
- 分区策略：合理规划分区的数量和分布，确保数据均匀分布，避免热点分区。
- 副本分布：副本应分布于不同的 Broker 上，避免单点故障。
发送方 ACK 机制
ZooKeeper 或 KRaft 模式
ZooKeeper
- ZooKeeper 高可用性：部署多个 ZooKeeper 节点，形成一个高可用的 ZooKeeper 集群。ZooKeeper 负责协调 Broker 之间的通信，并在故障时选举新的 Controller。
- ZooKeeper 配置：确保 ZooKeeper 集群的配置正确，能够容忍一定程度的节点失效。
KRaft 模式
- Raft 协议：使用 Raft 协议进行 Leader 选举和日志复制，确保即使部分 Broker 失效，仍能选出新的 Leader 并继续提供服务。
- 日志一致性：通过 Raft 协议确保所有 Broker 的日志条目一致，即使 Leader 更换，数据也是一致的。
数据持久化
日志存储
- 日志存储优化：使用高性能的存储设备（如 SSD）来存储 Kafka 日志，确保写入性能和读取性能。
- 日志清理策略：合理设置日志清理策略（如基于时间或大小），确保日志文件不会无限增长。
日志备份
- 定期备份：定期对 Kafka 日志进行备份，以防数据丢失。
- 远程存储：将备份数据存储在远程位置，以防本地灾难。
故障恢复
自动故障恢复
- Leader 选举：当 Leader Broker 失效时，能够自动选举新的 Leader。
- 分区重分配：当某个 Broker 失效时，能够自动将分区重分配给其他健康的 Broker。
手动故障恢复
- 手动干预：对于复杂故障，可能需要手动干预来恢复集群状态。
- 故障转移：手动将分区 Leader 转移到其他 Broker。