1. Requests, Transactions, and Identifiers
1. Read operation request: The zookeeper server will process the request locally, so the performance of zookeeper will be very high when processing read-only requests as the main load, we can also add more servers to the zookeeper cluster, which can handle more read request.
2. Write operation request: The zookeeper server forwards the request to the leader, and the leader executes the corresponding request and forms a state update, which is called a transaction. For example: a client submits a setData request to the /z node, setData will change the data information of the znode node, and will increase the version number of the node.
3. The zookeeper cluster operates in a transactional manner and ensures that all change operations are performed atomically without being disturbed by other transactions. Transactions are idempotent
4. When the leader generates a transaction, it will assign an identifier (zookeeper session id) to the transaction, which can be executed on the follower designated by the leader.
2. Group leader election
1. The purpose of setting the leader is to sort the zookeeper state changes initiated by the client, including create, setdata, and delete operations. The leader converts each request into a transaction and sends those transactions to follow, ensuring that the cluster accepts and processes them in the order determined by the leader.
2. After each server starts, it enters the looking state. These servers will communicate to elect a group leader, and the server that wins the election will enter the leading state. The other servers in the cluster will enter the following state.
When a server enters the looking state, it sends a notification message to each server in the cluster, which includes the server's voting information. The voting information includes: the server identifier (sid) and the most recently executed transaction (zxid) )information.
Voting Rules:
1: Get the voting information (voteid, votezxid) of other servers.
2: If (voteZxid > myZxid) or (votezxid = myzxid and voteID > mysid), keep the current voting information.
3: Otherwise, modify your voting information
3. Broadcast Protocol for Status Update
When a write request is received, follow will forward the request to the leader, who will execute the request exploratively and broadcast the status update in a transactional manner. Pass (Zab Protocol)
1. Zab (zookeeper atomic broadcast protocol):
Broadcast mode: The leader sends a message to the follower. When a follower receives the message, it responds to the leader with an ack message, and the leader sends a message to notify the follower to submit.
Recovery mode: When the leader crashes, enter recovery mode.
4. Observer: Another type of server
1. Observers do not participate in the election process
2. Function: Improve the scalability of read requests, and can be deployed across multiple data centers
5. Server and session:
The connection between the client and the zookeeper server. The session in zookeeper is called session. The client maintains a session by establishing a long tcp connection with the server. When the client starts, it first establishes a tcp connection with the server. Through this connection, The client can maintain a valid session with the server through heartbeat detection, and can also send a request to the zk server and get a response.
6. Server and watchpoint (event listener): The server implements the watchpoint manager, which is responsible for managing the list of currently registered watchpoints and triggering.
Seven, client: in the client library (zookeeper and clientcnxn)
8. Serialization: Serialized messages and transactions for network transmission and disk storage. zookeeper uses jute in hadoop for serialization
9. ACL policy
1: create permission to create child nodes
2: read permission to obtain child node data and child node list
3: write permission to update node data
4: delete permission to delete child nodes
5: admin sets the permissions of the node acl