-
Leader 选举：
- 当 Kafka 集群启动或某个 Broker 失效时，集群中的 Broker 会通过 Raft 协议进行选举，选出一个 Leader Broker。Leader Broker 负责处理客户端请求，并维护元数据的一致性。
-
日志复制：
- 一旦选举出 Leader，Leader 将负责管理日志条目（即元数据更改记录）。每当有新的元数据更改（如创建 Topic、修改分区配置等），Leader 将把这些更改记录在本地的日志文件中，并将这些更改广播给集群中的其他 Broker（称为 Follower）。
- Follower Broker 会将接收到的日志条目追加到自己的日志文件中，并向 Leader 发送确认信息。
-
日志一致性：
- Raft 协议确保日志条目的顺序和内容在所有 Broker 中是一致的。Leader 会定期向 Follower 发送心跳消息（AppendEntries RPC），以确认 Follower 的状态，并确保 Follower 的日志是最新的。
- 如果 Follower 的日志与 Leader 不一致，Leader 会发送缺少的日志条目给 Follower，直到两者日志一致为止。这样，即使某个 Broker 失效，重新启动后也能通过与其他 Broker 的日志同步来恢复一致性。
-
多数派原则（Majority Rule）：
- 在 Raft 中，只有当大多数（超过一半）的 Broker 确认了一个日志条目后，该条目才被认为是已提交（committed）。这意味着即使有一部分 Broker 失效，只要大多数 Broker 正常工作，元数据的一致性就可以得到保证。
-
日志条目匹配：
- Raft 协议还提供了日志条目匹配机制，确保每个 Broker 的日志条目在相同的位置上是一致的。Leader 会通过日志条目的索引（index）和任期（term）来确保条目的正确性。
-
Leader 失效处理：
- 如果 Leader Broker 失效，集群中的其他 Broker 会重新进行选举，选出一个新的 Leader。新的 Leader 会继续管理日志条目，并确保所有 Broker 的元数据保持一致。
-
心跳机制：
- Leader 定期向 Follower 发送心跳消息，以确认 Follower 的状态，并保持与其他 Broker 的联系。心跳消息包含日志条目，以确保所有 Broker 的日志是最新的。