Use the service governance to achieve service registration and discovery
Client-based service registration and discovery Apache Zookeeper
Based on the service end of the service registration and discovery Netflix Eureka
Zookeeper distributed coordination framework
Distributed coordination control technology is mainly used to solve the synchronization between the distributed environment among multiple processes, allowing them to access some kind of orderly critical resources, prevent the consequences of "dirty data".
Zookeeper is a distributed coordination service for managing mainframe. In a distributed environment, coordination and management services is a complex process. ZooKeeper solve this problem through its simple architecture and API. ZooKeeper allows developers to focus on core application logic without having to worry about the distributed nature of applications.
Zookeeper data model
Among the data model like Zookeeper tree data structure, much like a file system directory also. Tree is composed of nodes, the Zookeeper data storage is also based on the node (znode), but is different from the tree nodes, znode reference path is the reference, similar to a file path.
There are four types of znode:
-
PERSISTENT- lasting node
The default node type, node after creating the client and Zookeeper disconnected, the node still exists
-
PERSISTENT_SEQUENTIAL- persistent node order of the nodes
When you create a node, Zookeeper numbered according to the node name created in chronological order
-
EPHEMERAL- temporary node
When you create a client node with the zookeeper disconnected temporarily node will be deleted
-
EPHEMERAL_SEQUENTIAL- temporary order of nodes
When you create a client node with the zookeeper disconnected temporarily node will be deleted, but Zookeeper numbered sequentially to the node name
Znode element
data: data storage Znode.
ACL: access Znode record, that is who or what can access this IP node.
stat: Znode containing various metadata, such as transaction ID, version number, timestamp, size, etc.
child: the child of the current node reference.
Note: Zookeeper for reading and writing little scene design. Znode is not used to store massive business data, but are used to store a small amount of status and configuration information, the maximum data for each node can not exceed 1MB.
The basic operation of Zookeeper
Create a node create
Delete nodes delete
Determining whether there exists a node
GetData node acquiring data
A setting data node setData
Gets all the child nodes under the node getChildren
Zookeeper event notification
exists, getData, getChildren read operation belongs. Zookeeper client when requesting a read operation, you can select whether to set Watch.
Watch can be understood as a specific Znode registered on the trigger. When this Znode change, which is called create, delete, setData method when will trigger the corresponding event registration on Znode, Watch the request of the client will receive asynchronous notifications.
Zookeeper consistency
In order to prevent a stand-alone hang, Zookeeper maintains a cluster. Zookeeper Service cluster is a master multi-slave structure. When updating data, the first update to the master node (here refers to a server node, not znode), re-synchronization to the node. When reading data, read directly from any node. To ensure data consistency from the master node, using the Zookeeper ZAB protocol that is very similar to and consistent Paxos algorithm Raft.
ZAB(Zookeeper Atomic Broadcast)
ZAB agreement effective solution Zookeeper cluster crash recovery, as well as master-slave synchronization issues of data.
Three kinds of node status ZAB protocol definition: Looking (node election), Following (the state in which the node), Leading (the state in which the master node)
The maximum ZXID: local node of the latest transaction number, and counting two parts contain epoch, epoch era is the meaning of the equivalent Raft algorithm selected when the primary term.
ZAB four stages
1 election: Looking states elected Leader node, Leader of lastZXID always up to date
2 found: Follower Leader node to the registration push FOllOWERINFO, which contains information on a period of the epoch, the receiving quasi Leader NEWLEADER instruction newEpoch validity check, the quasi-Leader to ensure Follower ZXID less than or equal to the epoch itself.
3 Sync: Leader of the Follower and data synchronization, initiated by the Leader synchronous instruction, most overall consistency of the data cluster
Broadcast 4: Leader broadcast Proposal and Commit, Follower Proposal and receiving the Commit;
election
1, each sends to other nodes Follower votes Vote Leader is selected as the request, waits for a reply;
2, Follower received Vote if newer than their ZXID the vote, and update their Vote, or refuse to vote;
3, each Follower maintains a voting record in the table, when a node receives more than half the vote, the polls closed and the Follower elected Leader, the polls closed;
Recovery (discovery and synchronization)
Find
1, leader zxid and generate new epoch, receiving the transmitted FOllOWERINFO follower (containing the current node LastZXID)
2, leader to send NEWLEADER follower; Leader sends an update instruction to update policy Follower according to the data sent by The LastZXID follower;
Synchronize
1, SNAP: if the data is too old follower, epoch still on the last round, leader sends instructions to the follower snap snapshot synchronization
2, DIFF: normal synchronization phase
3, TRUNC: Follower is a minority if the last round (by contrast ztid), send TRUNC command lets follower discard this data
broadcast
Into the normal leader commit phase, resulting in increasing zxid, after receiving half of the voting, then submit.