zk----刨根问底4

NullQuorumAuthLearner

 

/**

 * This class represents no authentication learner, it just return

 * without performing any authentication.

 */

 

NullQuorumAuthServer

 

 

/**

 * This class represents no authentication server, it just return

 * without performing any authentication.

 */

QuorumAuth

QuorumAuthLearner

 

/**

 * Interface for quorum learner authentication mechanisms.

 */

QuorumAuthServer

 

 

/**

 * Interface for quorum server authentication mechanisms.

 */

 

 

SaslQuorumAuthLearner

 

 

SaslQuorumAuthServer

 

 

SaslQuorumServerCallbackHandler

 

 

 

/**

 * This is used by the SASL mechanisms to get further information to complete

 * the authentication. For example, a SASL mechanism might use this callback

 * handler to do verification operation. This is used by the QuorumServer to

 * perform the mutual quorum peer authentication.

 */

 

 

QuorumHierarchical

 

 

/**

 * This class implements a validator for hierarchical quorums. With this

 * construction, zookeeper servers are split into disjoint groups, and 

 * each server has a weight. We obtain a quorum if we get more than half

 * of the total weight of a group for a majority of groups.

 * 

 * The configuration of quorums uses two parameters: group and weight. 

 * Groups are sets of ZooKeeper servers, and we set a group by passing

 * a colon-separated list of server ids. It is also necessary to assign

 * weights to server. Here is an example of a configuration that creates

 * three groups and assigns a weight of 1 to each server:

 * 

 *  group.1=1:2:3

 *  group.2=4:5:6

 *  group.3=7:8:9

 *  

 *  weight.1=1

 *  weight.2=1

 *  weight.3=1

 *  weight.4=1

 *  weight.5=1

 *  weight.6=1

 *  weight.7=1

 *  weight.8=1

 *  weight.9=1

 * 

 * Note that it is still necessary to define peers using the server keyword.

 */

 

 

 

QuorumMaj

 

 

 

/**

 * This class implements a validator for majority quorums. The 

 * implementation is straightforward.

 *

 */

QuorumVerifier

 

 

/**

 * All quorum validators have to implement a method called

 * containsQuorum, which verifies if a Set of server 

 * identifiers constitutes a quorum.

 *

 */

 

 

 

 

 

 

AckRequestProcessor

 

 

 

/**

 * This is a very simple RequestProcessor that simply forwards a request from a

 * previous stage to the leader as an ACK.

 */

 

AuthFastLeaderElection

 

/**

 * @deprecated This class has been deprecated as of release 3.4.0. 

 */

 

CommitProcessor

 

/**

 * This RequestProcessor matches the incoming committed requests with the

 * locally submitted requests. The trick is that locally submitted requests that

 * change the state of the system will come back as incoming committed requests,

 * so we need to match them up.

 */

Election

 

FastLeaderElection

 

 

/**

 * Implementation of leader election using TCP. It uses an object of the class

 * QuorumCnxManager to manage connections. Otherwise, the algorithm is push-based

 * as with the other UDP implementations.

 *

 * There are a few parameters that can be tuned to change its behavior. First,

 * finalizeWait determines the amount of time to wait until deciding upon a leader.

 * This is part of the leader election algorithm.

 */

 

 

Follower

 

 

/**

 * This class has the control logic for the Follower.

 */

FollowerBean

 

 

/**

 * Follower MBean interface implementation.

 */

 

FollowerMXBean

 

/**

 * Follower MBean

 */

FollowerRequestProcessor

 

 

/**

 * This RequestProcessor forwards any requests that modify the state of the

 * system to the Leader.

 */

 

 

FollowerZooKeeperServer

 

 

/**

 * Just like the standard ZooKeeperServer. We just replace the request

 * processors: FollowerRequestProcessor -> CommitProcessor ->

 * FinalRequestProcessor

 * 

 * A SyncRequestProcessor is also spawned off to log proposals from the leader.

 */

 

Leader

 

 

/**

 * This class has the control logic for the Leader.

 */

 

LeaderBean

 

 

/**

 * Leader MBean interface implementation.

 */

 

LeaderElection

 

 

/**

 * @deprecated This class has been deprecated as of release 3.4.0. 

 */

 

LeaderElectionBean

 

 

/**

 * Leader election MBean interface implementation

 */

 

 

LeaderElectionMXBean

 

 

/**

 * Leader election protocol MBean. 

 */

 

LeaderMXBean

 

 

/**

 * Leader MBean.

 */

 

 

 

LeaderZooKeeperServer

 

/**

 * 

 * Just like the standard ZooKeeperServer. We just replace the request

 * processors: PrepRequestProcessor -> ProposalRequestProcessor ->

 * CommitProcessor -> Leader.ToBeAppliedRequestProcessor ->

 * FinalRequestProcessor

 */

 

 

 

Learner

 

 

 

/**

 * This class is the superclass of two of the three main actors in a ZK

 * ensemble: Followers and Observers. Both Followers and Observers share 

 * a good deal of code which is moved into Peer to avoid duplication. 

 */

 

 

LearnerHandler

 

/**

 * There will be an instance of this class created by the Leader for each

 * learner. All communication with a learner is handled by this

 * class.

 */

 

LearnerSessionTracker

 

 

/**

 * This is really just a shell of a SessionTracker that tracks session activity

 * to be forwarded to the Leader using a PING.

 */

 

LearnerSyncRequest

 

 

LearnerZooKeeperServer

 

 

/**

 * Parent class for all ZooKeeperServers for Learners 

 */

 

LocalPeerBean

 

 

/**

 * Implementation of the local peer MBean interface.

 */

 

LocalPeerMXBean

 

 

/**

 * A local zookeeper server MBean interface. Unlike the remote peer, the local

 * peer provides complete state/statistics at runtime and can be managed (just 

 * like a standalone zookeeper server).

 */

 

Observer

 

 

/**

 * Observers are peers that do not take part in the atomic broadcast protocol.

 * Instead, they are informed of successful proposals by the Leader. Observers

 * therefore naturally act as a relay point for publishing the proposal stream

 * and can relieve Followers of some of the connection load. Observers may

 * submit proposals, but do not vote in their acceptance. 

 *

 * See ZOOKEEPER-368 for a discussion of this feature. 

 */

 

ObserverMXBean

 

 

/**

 * Observer MX Bean interface, implemented by ObserverBean

 *

 */

 

ObserverRequestProcessor

 

 

/**

 * This RequestProcessor forwards any requests that modify the state of the

 * system to the Leader.

 */

 

ObserverZooKeeperServer

 

 

/**

 * A ZooKeeperServer for the Observer node type. Not much is different, but

 * we anticipate specializing the request processors in the future. 

 *

 */

 

ProposalRequestProcessor

 

 

/**

 * This RequestProcessor simply forwards requests to an AckRequestProcessor and

 * SyncRequestProcessor.

 */

 

ProposalStats

 

 

/**

 * Provides live statistics about a running Leader.

 */

 

QuorumBean

 

QuorumCnxManager

 

 

/**

 * This class implements a connection manager for leader election using TCP. It

 * maintains one connection for every pair of servers. The tricky part is to

 * guarantee that there is exactly one connection for every pair of servers that

 * are operating correctly and that can communicate over the network.

 * 

 * If two servers try to start a connection concurrently, then the connection

 * manager uses a very simple tie-breaking mechanism to decide which connection

 * to drop based on the IP addressed of the two parties. 

 * 

 * For every peer, the manager maintains a queue of messages to send. If the

 * connection to any particular peer drops, then the sender thread puts the

 * message back on the list. As this implementation currently uses a queue

 * implementation to maintain messages to send to another peer, we add the

 * message to the tail of the queue, thus changing the order of messages.

 * Although this is not a problem for the leader election, it could be a problem

 * when consolidating peer communication. This is to be verified, though.

 * 

 */

 

QuorumMXBean

 

 

/**

 * An MBean representing a zookeeper cluster nodes (aka quorum peers)

 */

 

 

 

QuorumPeer

 

 

/**

 * This class manages the quorum protocol. There are three states this server

 * can be in:

 * <ol>

 * <li>Leader election - each server will elect a leader (proposing itself as a

 * leader initially).</li>

 * <li>Follower - the server will synchronize with the leader and replicate any

 * transactions.</li>

 * <li>Leader - the server will process requests and forward them to followers.

 * A majority of followers must log the request before it can be accepted.

 * </ol>

 *

 * This class will setup a datagram socket that will always respond with its

 * view of the current leader. The response will take the form of:

 *

 * <pre>

 * int xid;

 *

 * long myid;

 *

 * long leader_id;

 *

 * long leader_zxid;

 * </pre>

 *

 * The request for the current leader will consist solely of an xid: int xid;

 */

 

 

QuorumPeerConfig

 

QuorumPeerMain

 

 

/**

 *

 * <h2>Configuration file</h2>

 *

 * When the main() method of this class is used to start the program, the first

 * argument is used as a path to the config file, which will be used to obtain

 * configuration information. This file is a Properties file, so keys and

 * values are separated by equals (=) and the key/value pairs are separated

 * by new lines. The following is a general summary of keys used in the

 * configuration file. For full details on this see the documentation in

 * docs/index.html

 * <ol>

 * <li>dataDir - The directory where the ZooKeeper data is stored.</li>

 * <li>dataLogDir - The directory where the ZooKeeper transaction log is stored.</li>

 * <li>clientPort - The port used to communicate with clients.</li>

 * <li>tickTime - The duration of a tick in milliseconds. This is the basic

 * unit of time in ZooKeeper.</li>

 * <li>initLimit - The maximum number of ticks that a follower will wait to

 * initially synchronize with a leader.</li>

 * <li>syncLimit - The maximum number of ticks that a follower will wait for a

 * message (including heartbeats) from the leader.</li>

 * <li>server.<i>id</i> - This is the host:port[:port] that the server with the

 * given id will use for the quorum protocol.</li>

 * </ol>

 * In addition to the config file. There is a file in the data directory called

 * "myid" that contains the server id as an ASCII decimal value.

 *

 */

 

QuorumStats

 

QuorumZooKeeperServer

 

 

/**

 * Abstract base class for all ZooKeeperServers that participate in

 * a quorum.

 */

 

 

ReadOnlyBean

 

/**

 * ReadOnly MX Bean interface, implemented by ReadOnlyBean

 *

 */

 

 

ReadOnlyRequestProcessor

 

/**

 * This processor is at the beginning of the ReadOnlyZooKeeperServer's

 * processors chain. All it does is, it passes read-only operations (e.g.

 * OpCode.getData, OpCode.exists) through to the next processor, but drops

 * state-changing operations (e.g. OpCode.create, OpCode.setData).

 */

 

 

ReadOnlyZooKeeperServer

 

 

/**

 * A ZooKeeperServer which comes into play when peer is partitioned from the

 * majority. Handles read-only clients, but drops connections from not-read-only

 * ones.

 * <p>

 * The very first processor in the chain of request processors is a

 * ReadOnlyRequestProcessor which drops state-changing requests.

 */

 

 

 

RemotePeerBean

 

/**

 * A remote peer bean only provides limited information about the remote peer,

 * and the peer cannot be managed remotely. 

 */

 

 

RemotePeerMXBean

 

 

 

/**

 * A proxy for a remote quorum peer.

 */

 

 

SendAckRequestProcessor

 

 

ServerBean

 

/**

 * An abstract base class for the leader and follower MBeans.

 */

 

ServerMXBean

 

 

/**

 * A quorum server MBean.

 */

StateSummary

 

 

 

/**

 * This class encapsulates the state comparison logic. Specifically,

 * how two different states are compared.

 */

 

 

Vote