Simplify complex problems
Zookeeper is a streamlined file manager, each of his nodes is like a file or folder.
High Availability: ZooKeeper can run on a group of servers, and they are designed to be highly available, avoiding a single point of failure for your application.
Zookeeper is simply a znode node.
Each Znode consists of 3 parts:
① stat: This is status information, describing the version, permissions and other information of the Znode
② data: data associated with the Znode
③ children: child nodes under the Znode
Znodes are further divided into two types: temporary nodes and permanent nodes.
① Temporary nodes: The life cycle of the nodes depends on the session that created them. Once the session (Session) ends, the temporary node will be automatically deleted, of course, it can also be deleted manually. Although each ephemeral Znode is bound to a client session, they are still visible to all clients. Additionally, ZooKeeper ephemeral nodes are not allowed to have children.
② Permanent nodes: The life cycle of the nodes does not depend on the session, and they can only be deleted when the client displays the delete operation.
Let's talk about some features of zookeeper.
Zookeeper is deployed in a distributed manner, that is, it is deployed on multiple machines, which means that a certain machine is down, and it has no effect. Feature 2 When the client establishes a connection with the zookeeper service, a temporary node can be created, but after disconnecting from the service, the node will be automatically deleted.
Implement a simple master service with these features
That is to say, to prevent the server from going down, use multiple servers to publish services. But only one server provides services at the same time. When the main service fails, the standby server will take over immediately.
Here's a simple definition
server A, server B
Client A
At the beginning, server A and server B are connected to the zookeeper server at the same time.
Annotate a temporary node respectively.
Suppose that server A registers znode1 first, and server B registers znode2 later.
This is through the zookeeper sorting mechanism to obtain the first node znode1 and set it as the master node (permanent node, which contains the configuration information of the server). The client obtains the master node, connects to the master server through the information inside, and requests services.
Suppose this is the server Adown. Thinking that this will disconnect him from zookeeper, and the znode1 node will be automatically deleted. At the same time, the watch event is started, and the master will be re-elected, that is, znode2. When server A returns to normal, it will connect to the zookeeper server and register node znode3 again. Waiting to participate in the election. Suppose that the server is suddenly disconnected from zookeeper due to network reasons at this time, but it is not actually down. At this point, zonde2 will also be deleted, and then the master node will be re-elected. This will make it unnecessary to switch the master. How to solve this problem? That is to say, when the master hangs up, the master node is elected. The last master node has priority. How to achieve it? When electing a node, determine whether the current node is the last master node, and if so, elect immediately. Otherwise, wait 5 seconds before participating in the election. In this way, unnecessary overhead caused by network interruption and switching service area will not be caused.