The following scenarios are where I think zookeeper might come into play.
Scenario 1: Configuration additions and updates
We can deploy zookeeper as a configuration service to implement functions such as configuration storage and publishing.
The specific principle is: zookeeper can store data in a tree-like structure, and all clients can subscribe to zookeeper's data changes. If zookeeper's data is updated or deleted, all subscriptions will get a message to re-acquire the updated data. So that the first time to know the changes.
Challenges:
1. Can zookeeper withstand the reading of a large number of clients?
2. The client usually needs to cache the configuration locally, which can greatly reduce the network overhead, and only needs to be re-pulled when the data changes. The challenge brought by this is how to ensure data consistency. Some machines have learned the latest configuration, and some machines have not learned the latest configuration, which is not allowed by the business side. Consistency guarantees are a difficult problem.
Scenario 2: Cluster Network Management
As an intermediate coordinator, zookeeper can know the status of all machines in the cluster, synchronize the status to the central control machine (typically LVS), and notify all machines in the cluster if necessary.