The role of zookeeper monitoring

When more and more services, the size of the larger, the corresponding number of machines is also growing, relying on manual to manage and maintain service and address configuration address information, has been very difficult, and, Relying on a single hardware load balancing device or using software schemes such as Lvs.nginx for routing and load balancing scheduling, the problem of single points of failure is also beginning to highlight, once the service routing or Load balancing server down, all services that depend on him will be invalidated,

At this point, you need a place where you can dynamically register and get service information. To unify the management Service name and its corresponding server list information, called the Service Configuration Center, when the service provider starts, it registers the service name, the server address, and the service configuration new, and the service consumer obtains a list of machines for the service to be called through the Service configuration center. Through the corresponding load balancing algorithm, select one of the servers to make the call. When the server is down or offline, the corresponding machine needs to be able to dynamically overflow from the service configuration center, and inform the corresponding service consumers, otherwise the service consumers may be called to the service has failed to make a mistake, in this process, the service consumers only the first call to service needs to query the service configuration center, The queried information is then cached locally, and subsequent calls directly use the locally cached service address list information without having to re-initiate the request-Path service configuration Center to obtain the corresponding list of service addresses until the address list of the service is changed (machine-on-line or offline). This unstructured structure solves the single point of failure problems caused by previous load balancing devices and greatly reduces the pressure on the service configuration center

Based on zookeeper persistent and non-persistent nodes, we are able to perceive the status of back-end servers in near real-time (on-line, offline, down) through the Zab protocol between clusters, so that service configuration information can be consistent. But zookeeper's fault-tolerant characteristic and leader election mechanism can guarantee our convenience to enlarge and realize the dynamic registration of service through zookeeper. Machine on-line and offline dynamic sensing, easy to expand, fault-tolerant, and the non-centralized structure can solve the problem of the single point of failure before using the Load Balancer device, only when the configuration information is updated to get the latest service address list on zookeeper, other times using local cache.

Once the server and the zookeeper cluster disconnected, the node will not exist, by registering the corresponding watcher, the service consumer can first know the service provider machine information changes, using its znode characteristics and watcher mechanism, As a configuration center for dynamically registering and acquiring service information, the unified Management Service name and its corresponding server list information, we are able to perceive the status of the backend server in near real-time (on-line, offline, Downtime). Zookeeper between clusters through the Zab protocol, the service configuration information can be consistent, and zookeeper itself fault-tolerant characteristics and leader election mechanism, can guarantee our convenient expansion.

--from "Large-scale distributed Web site architecture design and Practice"

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

The role of zookeeper monitoring