Distributed design and development (iii) ------ high consistency service ZooKeeper,

Distributed design and development (iii) ------ high consistency service ZooKeeper,

In a distributed environment, most services allow partial failures and data inconsistency. However, some of the most basic services require high reliability and consistency, these services are the basis for other distributed services, such as naming service and distributed lock. These distributed basic services have the following requirements:

• High Availability
• High Consistency
• High Performance

Designing a service that challenges the CAP principle is a challenge and a good research topic. Apache's ZooKeeper may give us a good answer. ZooKeeper is a distributed, open-source distributed application Coordination Service that exposes a simple primitive set. distributed applications can implement synchronization services based on it, configuration maintenance and naming services. For more information about ZooKeeper, see the official documentation.

Basic use of ZooKeeper

It is relatively simple to build a distributed ZooKeeper environment. The basic steps are as follows:

1) install ZooKeeper on each server

Download ZooKeeper and decompress it on each server.

Tar-xzf zookeeper-3.2.2.tar.gz

2) configure the Cluster Environment

Create a configuration file named zoo. cfg under the zookeeper installation directory of each server. Fill in the following content:

[Xhtml]View plaincopy

1. # The number of milliseconds of each tick
2. TickTime = 2000
3. # The number of ticks that the initial
4. # Synchronization phase can take
5. InitLimit = 10
6. # The number of ticks that can pass
7. # Sending a request and getting an acknowledgement
8. SyncLimit = 5
9. # The directory where the snapshot is stored.
10. DataDir =/home/admin/zookeeper-3.2.2/data
11. # The port at which the clients will connect
12. ClientPort = 2181
13. Server.1 = zoo1: 2888: 3888
14. Server.2 = zoo2: 2888: 3888

 

Zoo1 and zoo2 correspond to the machine name or ip address of each server in the cluster, and 1 and 2 in server.1 and server.2 correspond to the zookeeper id of each server, respectively, the method for setting id is to create a file named myid under the directory configured by dataDir and use id as the file content. In this example, it is set to 1 and 2. For other configurations, see the official documentation.

3) Start the Cluster Environment

Run the zookeeper STARTUP script on each server.

/Home/admin/zookeeper-3.2.2/bin/zkServer. sh start

4) apply zookeeper

The application zookeeper can execute commands in the shell or call program interfaces in java or c.

Run the following command in shell:

Bin/zkCli. sh-server 10.20.147.35: 2181

10.20.147.35 indicates the ip address or machine name of any machine in the cluster. After execution, you can go to the zookeeper Operation Panel. For details about how to perform the operation, see the official documentation.

In java, calling program interfaces to apply zookeeper is more complex. You need to understand the concepts of watch and callback. However, this is not required for the simplest CURD experiment, you only need to use the ZooKeeper class. The test code is as follows:

[Java]View plaincopy

1. Public static void main (String [] args ){
2. Try {
3. ZooKeeper zk = new ZooKeeper ("10.20.147.35: 2181", 30000, null );
4. String name = zk. create ("/company", "alibaba". getBytes (),
5. Ids. OPEN_ACL_UNSAFE, CreateMode. PERSISTENT_SEQUENTIAL );
6. Stat stat = new Stat ();
7. System. out. println (new String (zk. getData (name, null, stat )));
8. Zk. setData (name, "taobao". getBytes (), stat. getVersion (), null, null );
9. System. out. println (new String (zk. getData (name, null, stat )));
10. Stat = zk. exists (name, null );
11. Zk. delete (name, stat. getVersion (), null, null );
12. System. out. println (new String (zk. getData (name, null, stat )));
13. } Catch (Exception e ){
14. E. printStackTrace ();
15. }
16. }

 

The above code is relatively simple. Check the zooKeeper api doc to see how to use it.

Implementation Mechanism of ZooKeeper

The implementation mechanism of ZooKeeper is the most complex open-source framework I have ever seen. It solves the consistency problem in a distributed environment. This scenario also determines the complexity of its implementation. After reading the source code for two or three days, I am still confused. Some of them are beyond my ability. However, by reading the document and other articles written by other experts, I can roughly understand its principles and basic structure.

1) Basic principles of ZooKeeper

ZooKeeper is based on the Fast Paxos algorithm. In the previous blog, we introduced paxos, but we did not mention the existence of live locks in paxos, that is, when multiple proposer are submitted in a staggered manner, they may be mutually exclusive. As a result, no proposer can be submitted successfully, while Fast Paxos has made some optimizations and elected a leader, only the leader can submit propose. The specific algorithm can be seen in Fast Paxos. Therefore, to get ZooKeeper, you must first understand Fast Paxos.

2) Basic operation process of ZooKeeper

ZooKeeper has the following two processes:

• Election Leader
• Synchronize data

There are many algorithms in the election Leader process, but the election criteria to be met are consistent:

• The Leader must have the highest zxid
• Most machines in the cluster receive the response and the Leader selected by follow.

The data synchronization process is the essence of ZooKeeper, and is the specific implementation of the Fast Paxos algorithm. A cool man draws a ZooKeeper data flow chart, which intuitively describes how ZooKeeper synchronizes data.

I cannot understand the essence of the above two core processes at the moment. This is also related to my lack of full understanding of the Fast Paxos algorithm. Further study is required.

Application field of ZooKeeper

Tim mentioned several main scenarios that can be applied by Paxos in his blog, including database replication, naming service, config configuration management, and access control list. This is also the main application scenario of ZooKeeper. In addition, the ZooKeeper official document mentions several more basic distributed applications. This is a wonderful use of ZooKeeper.

1) distributed Barrier

Barrier is a mechanism for controlling and coordinating the trigger sequence of multiple tasks. Simply put, it is used to set a gate to block the tasks to be executed. When all tasks are in the executable state, to open the gate. The Mechanism is shown in the following figure:

JDK provides the javasicbarrier class on a single machine to implement this mechanism, but JDK is powerless in a distributed environment. To implement Barrer in a distributed system, high consistency is required. Therefore, ZooKeeper can be used. The solution adopted is to use a Node as the Barrer entity, A Barrer task needs to call exists () to detect the existence of this Node. When Barrier needs to be enabled, delete the Node. The watch mechanism of ZooKeeper notifies all tasks to start execution.

2) Distributed Queue

Like Barrier, high consistency is also required to implement Queue in a distributed environment. ZooKeeper provides a simple way to maintain the Queue entity through a Node, its children is used to store Queue content, and the ZooKeeper create method provides an incremental mode. It automatically adds an incremental number after the name to insert new elements. You can use its children to construct a queue data structure. When offer is used, create and take are used to delete the first queue in the order of children. ZooKeeper ensures that the data on each server is consistent, so it implements a distributed Queue. The take and offer instance codes are as follows:

 

[Java]View plaincopy

1. /**
2. * Removes the head of the queue and returns it, blocks until it succeeds.
3. * @ Return The former head of the queue
4. * @ Throws NoSuchElementException
5. * @ Throws KeeperException
6. * @ Throws InterruptedException
7. */
8. Public byte [] take () throws KeeperException, InterruptedException {
9. TreeMap <Long, String> orderedChildren;
10. // Same as for element. shocould refactor this.
11. While (true ){
12. LatchChildWatcher childWatcher = new LatchChildWatcher ();
13. Try {
14. OrderedChildren = orderedChildren (childWatcher );
15. } Catch (KeeperException. NoNodeException e ){
16. Zookeeper. create (dir, new byte [0], acl, CreateMode. PERSISTENT );
17. Continue;
18. }
19. If (orderedChildren. size () = 0 ){
20. ChildWatcher. await ();
21. Continue;
22. }
23. For (String headNode: orderedChildren. values ()){
24. String path = dir + "/" + headNode;
25. Try {
26. Byte [] data = zookeeper. getData (path, false, null );
27. Zookeeper. delete (path,-1 );
28. Return data;
29. } Catch (KeeperException. NoNodeException e ){
30. // Another client deleted the node first.
31. }
32. }
33. }
34. }
35. /**
36. * Inserts data into queue.
37. * @ Param data
38. * @ Return true if data was successfully added
39. */
40. Public boolean offer (byte [] data) throws KeeperException, InterruptedException {
41. For (;;){
42. Try {
43. Zookeeper. create (dir + "/" + prefix, data, acl, CreateMode. PERSISTENT_SEQUENTIAL );
44. Return true;
45. } Catch (KeeperException. NoNodeException e ){
46. Zookeeper. create (dir, new byte [0], acl, CreateMode. PERSISTENT );
47. }
48. }
49. }

3) Distributed lock

ZooKeeper is used to implement distributed lock. A Node is used to represent a Lock. When a client obtains the lock, a child with an auto-incrementing sequence is created under the Node, then, use the getChildren () method to check whether the created child is the top child. If yes, the lock is obtained. Otherwise, the exist () method is called to check the second top child, add watch to monitor. When the lock is returned after the lock is executed by the child, only the child created by the lock needs to be deleted. In this case, the watch mechanism notifies all clients that have not obtained the lock, these child will compete for the lock according to the lock rules mentioned above.