1. Set up a cluster

  • This experiment is based on three CentOS hosts, and the construction process of the standalone version can be slightly changed.
  • First, modifyconf/zoo.confFile. Check to see if you have this configuration information.dataDirIs used to store data files, according to the actual situation. The followingserverUsed to configure information about all servers in the cluster. All files in the file cluster can be the same as long as the destination address remains the same. 
    Corresponding port clientPort = 2181 # # server data snapshot file path where dataDir = / home/they/they are - 3.4.10 / data # # server cluster configuration information. A = B: C: D # A: B: indicates the IP address of the server. C: indicates the communication port between Zookeeper servers. D: Indicates the IP address of the server. 1=192.168.60.130:2287:3387 server.2=192.168.60.131:2288:3388 server.3=192.168.60.132:2289:3389Copy the code
  • indataIn the directory, write a file that identifies your host ID, which should correspond to the configuration file above. The host is1Just write1.2Just write2 
    cd data
echo "1" > myid
Copy the code
  • At this point, you are configured. Start each server separately. 
    ./zkServer.sh start
Copy the code
  • Viewing Local Roles 
    ./zkServer.sh status
Copy the code
  • Test, you can modify data on one server, the other server to see if the data has been modified.

2. Consistency protocol: ZAB protocol

  • The full name of the ZAB protocol is Zookeeper Atomic Broadcast.
  • Zookeeper uses the ZAB protocol to ensure the ultimate consistency of distributed transactions
  • Based on the ZAB protocol, there are three roles in the ZooKeeper cluster:
  • Working principle of ZAB broadcast mode:

  • All data write requests are performed by the Leader role. If the followers receive the write request, the write request is forwarded to the Leader, who completes it.
  • All machines can complete the read request.
  • When the Leader receives a write request, it first generates a unique new transaction node for the transaction.
  • The Leader then sends the proposed transaction to all Followers nodes.
  • After receiving a transaction request, the Follower node adds it to the history queue and sends an ACK back to the Leader
  • When the Leader receives more than half of the acks, it sends a commit request to commit the data and send a commit request to all followers to commit as well.

3. The Leader election

3.1 Server Status

  • A server has several states
    • Looking: Searches for the leader status. When the server is in this state, it considers that there is no leader in the cluster and therefore needs to enter the Leader election state.
    • Leading: Indicates the leader status. Indicates that the current server role is Leader.
    • Following: status of the follower. The current server role is follower.
    • Observing: Indicates the status of the observer. Indicates that the current server role is observer.

3.2 Leader election during server startup

  • During the initial phase of cluster initialization, when two servers are started, the two servers can communicate with each other, and both machines are trying to find the leader, thus entering the election process.
  1. Each server uses its own ID and the largest transaction ID on the host as its voting information. For example, the voting information for Server1 is(1, 0), indicating that its own ID is 1 and the maximum transaction ID is 0.
  2. Each server in the cluster receives voting information from each server.
  3. And then you can process it. First, compare transaction ids. The server with the largest transaction ID acts as the leader. If the transaction ID is the same, the server ID is compared, with the largest serving as the leader
  4. After the statistics, everyone knows who is the leader and follower, so change your state.

3.3 Leader election during server running

  • Once the leader goes down, a new election is called. The election process is as follows:
  1. All machines enter the looking state and then enter the leader election process
  2. As with the startup process, compare transaction ids to find the largest. If no, compare the server ID.
  3. Process the result and modify the status.

4. Observer roles and configurations

  • The observer role is only intended to improve cluster performance and load capacity. It does not participate in the election of leader.
  • Machines that want to be observers add a sentence to their configuration file 
    peerType=observer
Copy the code
  • And append one to the configuration files of all machines when declaring servers:observer 
    Server. 3 = 192.168.60.130:2289-3389: the observerCopy the code

5. Connect the Java API to the ZooKeeper cluster

  • In fact, the operation is no different from the stand-alone, but when configuring the address, add more addresses 
    ZooKeeper("192.168.60.130:2181192168 60.130:2182192168 60.130:2183".5000.newWatcher() {... });Copy the code