First, what is the zookeeper
ZooKeeper is a distributed, open-source coordination service for distributed applications, is an open source implementation of Google's Chubby, is a key component of Hadoop and Hbase. It is to provide a consistent service for distributed applications, provides features include: configuration maintenance, domain name service, distributed synchronization, group services.
In simple terms, zookeeper = + monitor file system notification mechanism
Second, the file system
zookeeper has with linux file system similar, the difference is, linux directory is a directory, the file is the file. The zookeeper only one znode concept itself can serve as a "file" to store certain data, but also as a "directory" exist.
/* +---+ |/ | +-+-+ | | +------+ +--|config| | +--+---+ | | +-----+ | +-----|ip | | | +-----+ | | +-----+ | +-----|port | | +-----+ | | +------+ +--|apps | +--+---+ | +-----+ +-----|app1 | | +-----+ | +-----+ +-----|app2 | +-----+ */
znode divided into four categories:
1, PERSISTENT- persistence directory node
This node after the client disconnects from the zookeeper, still need to take the initiative to delete.
2, PERSISTENT_SEQUENTIAL- persistent directory node sequence number
Similarly, such nodes also need to take the initiative to remove, it will not end with the client disconnected and removed. The difference is that with PERSISTENT, zookeeper such nodes will be numbered. Such as: app0000003362.0000003362 for the zookeeper to the number automatically increments.
3, EPHEMERAL- temporary directory node
PERSISTENT the difference is that these nodes will be deleted after the client disconnects from the zookeeper.
4, EPHEMERAL_SEQUENTIAL- temporary directory node sequentially numbered
And PERSISTENT_SEQUENTIAL similar number have automatic zookeeper, the difference will be deleted after the client and the zookeeper disconnected.
It is noteworthy that, under the same path, the same name znode can only be created once. And each znode can store a maximum of 1M data.
Third, listen notification mechanism
The client registers its concern to monitor directory node, when the node directory changes (change data is deleted, delete the subdirectory node increases), zookeeper will notify the client.
Fourth, practical application
Based on the file system and monitor notification mechanism, zookeeper has many application scenarios.
1. Naming Service (based on the file system)
In the name of all computer systems plays an important role, they are used to share resources, to uniquely identify the entity, point location. Named object can have many types and can be used to access a number of different services. Name server can be the address of a given resource or object names locate and obtain information about the property. (Baidu Encyclopedia)
Simply put, to get the corresponding resource / service address by name. The only use of znode can create a global node, corresponding information is recorded in the znode. We need to use the corresponding resource services directly to get information to this node.
2, Configuration Management (based on the file system and monitor notification mechanism)
The service has its own configuration, but with a multi-service deployments. If the form of the profile, modify the configuration at the time, need to synchronize all the files to the machine, and then notify the extent of dynamic loading, or simply reboot. If this is the case, there is a whole backstage share configuration (routing information, etc.), but in a modified, only need to be synchronized to a service (expansion, increase downstream nodes, etc.). After a long time, there will be different configuration different service conditions (although they are up to date for the departments they are using). At this point can solve this problem by configuring the center, all configurations are read from the configuration center, unified management.
To achieve their own distribution center, after all, it comes at a price. The use zookeeper, fully functional configuration of the center can be achieved. Corresponding information stored in the corresponding znode, the service only need to listen to configure their own concern (znode). Once znode changes, notify all listeners use this znode watcher client (for zookeeper, the service of his client), so as to update the configuration.
3, cluster management (based on the file system and monitor notification mechanism)
When a service is deployed to the cluster, there will be two issues: the machine to join and exit, master election. You can create zookeeper in a persistent znode A, then let all of this cluster of services to create a temporary znode B in A, need to know the service to listen to this cluster A. When adding new machines, creating a new B, leaving the old machine (downtime, volume reduction, etc.), automatically deleted B. Whether to create, or delete, A have changed, use watcher notifies all listeners. So we all know that the situation in this cluster.
For the master election, the same can also create a persistent znode C in the zookeeper, and then a sequential number for all services to create a temporary directory in C node. Each time you select No maximum or minimum as a master. As the number interim order catalog node number is incremented, if selected as the greatest master, when a new machine is added, the new machine will be the master. And select the minimum number as master, as long as it does not quit (znode not deleted), you will not have to switch master of the situation, the data is the most secure.
4, distributed lock (based on the file system and monitor notification mechanism)
There is a program, there are two threads, have carried 100w times ++ operations on the same variables. Without being locked, and the result is not the 200w. Similarly, in a cluster, if you modify the same resources at the same time, the situation would appear to cover each other. At this point, it is necessary to use a distributed lock to deal with such problems. To modify this resource before beginning, first obtain a lock. You can be modified after the operation to succeed. Due to the zookeeper, znode uniqueness, you can use it to implement distributed lock service. When the need to acquire a lock, create znode (non-automatic numbering) in the specified path, when the need to release, remove this znode. If the creation fails, the other services that the current has to grab the lock.
If znode non-automatic numbering created, there will be a problem. Every time the cluster lock all competing for the same service, there will be a service to grab the situation several times, while other services are not a success. In this case it may be modified to znode automatic numbering and the parent znode snoop. Each time you need to lock automatically create a numbered znode. If you have created znode the smallest number in all znode, I think they grab the lock. After unlocking (delete znode), will inform the entire cluster. This will not only achieve a distributed lock, and for everyone, in an orderly manner.
Fifth, reference links
https://blog.csdn.net/u010963948/article/details/83381757
https://www.cnblogs.com/lfs2640666960/p/11104838.html
https://blog.csdn.net/java_66666/article/details/81015302
https://blog.csdn.net/chunqiu3351/article/details/100762270
https://www.jianshu.com/p/d4fb16fafc2e