Zookeeper is an open source distributed, to provide coordinated services to distributed applications Apache project.
Zookeeper mode from the design point of view to understand: is a service-based distributed mode observer tube frame design, which is responsible for the storage and management of the core data, receive registration of the observer, once the core data changes, it will be responsible for notifying Zookeeper Zookeeper already What the observer registered react accordingly, Zookeeper = + file system notification mechanism.
Zookeeper Features
- A leader (Leader), with multiple clusters with (Follower) composition.
- As long as more than half of the cluster nodes survival, Zookeeper cluster will be able to normal service.
- Global data consistency: Each Server retain an identical copy of the data, Client randomly connect to the Server, the data are consistent
- Order the update request, the update request from the same Client executed sequentially transmitted sequence
- Data update atomic, either all succeed, or all fail.
- Real-time, within a certain range, Client can read the latest data.
Zookeeper data structure
ZooKeeper this "tree" What are the characteristics of it? ? ZooKeeper nodes we call Znode, Znode divided into two types:
short-term / temporary (Ephemeral) : When the client and server is disconnected, Znode (node) are created automatically deleted
persistent (Persistent) : When after the client and server is disconnected, znode (node) created will not be deleted
short / temporary : short and divided into ordinary node / nodes with short numbers.
persistence : persistence and divided into ordinary nodes / serialized lasting node.
Zookeeper service scenarios
Services provided include: unified naming services, unified configuration management, unified cluster management, offline dynamic server node, soft load balancing.
Uniform Naming Service:
In each ZooKeeper namespace (Namespace) is called ZNode, you can understand that each ZNode contains a path and associated metadata with them, as well as inherited from the child list of this node. With traditional file system it is different, in ZooKeeper data stored in memory to achieve high throughput and low latency distributed synchronization services.
In the data model of FIG ZooKeeper example, there are the following points:
- Each node (znode) stored in the data related to the synchronization (which is originally designed ZooKeeper, small amount of data, about the order of B to KB), such as status information, configuration content, the location information and the like.
- A ZNode maintains a state structure that includes: a version number, ACL change, time stamp. ZNode each data changes, the version number is incremented, so that the client read request may be retrieved based on the status data version number.
- Each ZNode has an ACL, whether to limit access to the ZNode.
- In a namespace, the data stored on ZNode perform read and write operations are requested atoms.
- The client may be provided on a ZNode a monitor (Watch), if the data ZNode changed, the client notifies the ZooKeeper, thereby triggering the execution logic implemented in the monitor.
Unified Configuration Management:
ZooKeeper Server cluster consists of a set of nodes, the existence of this group Server nodes in a role as Leader of the node, the other nodes are Follower. When the client is connected to the Client ZooKeeper cluster and write requests, which are sent to the Leader node, then the data change synchronized Leader node to other nodes in the cluster Follower.
The Unified Cluster Management:
ZooKeeper The Watch is only triggered once. That is, if the client specified ZNode set Watch, ZNode if the data changed, ZooKeeper sends a change notification to the client, while the trigger Watch event settings. If ZNode data changes took place, the client does not reset Watch the ZNode after receipt of the first notification, the ZooKeeper does not send a change notification to the client.
ZooKeeper asynchronous notification settings Watch clients. But ZooKeeper can guarantee will inform the client asynchronously after the entry into force of the change ZNode, then the client will be able to see the data change ZNode. Due to network delays, multiple clients may see a change ZNode data at different times, but see the order change is to ensure an orderly consistent.
Watch ZNode can set two types, one is the Data Watches (ZNode of the data changes lead to Watch triggering event), and the other is Child Watches (child node of the ZNode changed leads Watch triggering event). Call the getData () and exists () method to set Data Watches, call getChildren () method can set the Child Watches. Call the setData () method triggers the ZNode registered Data Watches. Call to create () method to create a ZNode, will trigger the ZNode of Data Watches; create a child node ZNode call to create () method is triggered ZNode of Child Watches. Call the delete () method to delete ZNode, while the trigger Data Watches and Child Watches, if the deleted ZNode also the parent, the parent node triggers a Child Watches.
In addition, if the client is disconnected with ZooKeeper Server, the client will not be able to trigger Watches, unless establish a connection with ZooKeeper Server again.
The dynamic server offline
When the new listener Server nodes offline for some reason can not provide services, zookeeper cluster will notify the client, the client list of changes by listening Server server, retrieve a list of servers and registration
Soft Load Balancing:
Zookeeper will record the number of visits per server, depending on the server performance, so that the minimum number of access servers to handle the latest client requests
common problem:
ZooKeeper why it is recommended to build a service station odd cluster?
ZooKeeper cluster servers generally is odd, if: 1,2,3,4,5 server; then hang up 4,5 two servers, zookeeper cluster service still normal, because cluster as long as more than half of nodes alive, Zookeeper cluster will be able to normal service, if it is an even number of servers, if: 1,2,3,4,5,6; then hang up 4,5.6 three services, Zookeeper cluster can not be normal service
ZooKeeper the election mechanism?
Suppose Zookeeper cluster of five servers, id from their 1-5 start while they are up to date, that is no historical data at this point to store the amount of data is the same.
- 1 Start the server, then it is only one server starts, it sent out a message without any response, so it's been a state election LOOKING state.
- 2 server starts up, it started with the server most of communication, exchange their election results, since both are no historical data, so id value larger servers to 2 win, but because there is no more than than half of the servers it agreed to elect (in this case more than half of 3), so the server 1,2 or remain LOOKING state.
- 3 Start the server, based on previous theoretical analysis, server server 1, 2, 3 become the boss, and the above difference is that this time there are three servers elected it, so it became the Leader of the election.
- 4 Start the server, the foregoing analysis, in theory, should be the server server 4 1,2,3,4 largest, but because there are already more than half of the elected Server 3 server, so it can only be received when the life of brother a.
- 5 server starts, like 4 when the younger brother.
ZooKeeper using a self-defined message protocol atoms, in which the message characteristic atomic layers, to ensure the consistency of the entire data or state node coordinate system. Follower based message protocol ensures that the local data ZooKeeper Leader node synchronization, and to independently provide services based on local storage.
When a node fails Leader failure, failure is failure to respond quickly, the message layer is responsible for re-select a Leader, continue to serve as a central coordinating cluster, handling client write requests, data and ZooKeeper coordination system change synchronization (broadcast) Follower to other nodes.
Write data flow:
- Client write data on the zookeeper Server1, transmits a write request
- If Server1 is not the Leader, it will Server1 received request further forwarded to the Leader, because each Zookeeper's Server there is a Leader. The Leader will be broadcast write requests to each cluster Server, such as Server1 and Server2, each Server write a successful return after notification Leader.
- When the Leader received the majority (more than half) Server data write is successful, then that data write is successful, then Leader will tell Server1 data write success
- Server1 further notice Client data write is successful, then went back to the default of the overall success of the write operation
What principle ZooKeeper is listening?
