Kafka Kraft 核心实现

/** * This class implements a Kafkaesque version of the Raft protocol. Leader election * is more or less pure Raft, but replication is driven by replica fetching and we use Kafka's * log reconciliation protocol to truncate the log to a common point following each leader * election. * * Like Zookeeper, this protocol distinguishes between voters and observers. Voters are * the only ones who are eligible to handle protocol requests and they are the only ones * who take part in elections. The protocol does not yet support dynamic quorum changes. * * These are the APIs in this protocol: * * 1) {@link VoteRequestData}: Sent by valid voters when their election timeout expires and they *    become a candidate. This request includes the last offset in the log which electors use *    to tell whether or not to grant the vote. * * 2) {@link BeginQuorumEpochRequestData}: Sent by the leader of an epoch only to valid voters to *    assert its leadership of the new epoch. This request will be retried indefinitely for *    each voter until it acknowledges the request or a new election occurs. * *    This is not needed in usual Raft because the leader can use an empty data push *    to achieve the same purpose. The Kafka Raft implementation, however, is driven by *    fetch requests from followers, so there must be a way to find the new leader after *    an election has completed. * * 3) {@link EndQuorumEpochRequestData}: Sent by the leader of an epoch to valid voters in order to *    gracefully resign from the current epoch. This causes remaining voters to immediately *    begin a new election. * * 4) {@link FetchRequestData}: This is the same as the usual Fetch API in Kafka, but we add snapshot *    check before responding, and we also piggyback some additional metadata on responses (i.e. current *    leader and epoch). Unlike partition replication, we also piggyback truncation detection on this API *    rather than through a separate truncation state. * * 5) {@link FetchSnapshotRequestData}: Sent by the follower to the epoch leader in order to fetch a snapshot. *    This happens when a FetchResponse includes a snapshot ID due to the follower's log end offset being less *    than the leader's log start offset. This API is similar to the Fetch API since the snapshot is stored *    as FileRecords, but we use {@link UnalignedRecords} in FetchSnapshotResponse because the records *    are not necessarily offset-aligned.

/** * QuorumController implements the main logic of the KRaft (Kafka Raft Metadata) mode controller. * * The node which is the leader of the metadata log becomes the active controller.  All * other nodes remain in standby mode.  Standby controllers cannot create new metadata log * entries.  They just replay the metadata log entries that the current active controller * has created. * * The QuorumController is single-threaded.  A single event handler thread performs most * operations.  This avoids the need for complex locking. * * The controller exposes an asynchronous, futures-based API to the world.  This reflects * the fact that the controller may have several operations in progress at any given * point.  The future associated with each operation will not be completed until the * results of the operation have been made durable to the metadata log. */

/** * The ReplicationControlManager is the part of the controller which deals with topics * and partitions. It is responsible for managing the in-sync replica set and leader * of each partition, as well as administrative tasks like creating or deleting topics. */public class ReplicationControlManager