Shulou(Shulou.com)06/03 Report--

A Survey of typical Application scenarios of ZooKeeper

Data publish and subscribe (configuration Center)

Publish and subscribe model, the so-called configuration center, as the name implies, is that publishers publish data to ZK nodes for subscribers to obtain data dynamically, and achieve centralized management and dynamic update of configuration information. For example, the global configuration information, the service address list of the service framework, etc., are very suitable for use.

Some configuration information used in the application is put on ZK for centralized management. This kind of scenario usually goes like this: when the application starts, it will actively obtain the configuration, and at the same time, register a Watcher on the node, so that every time there is an update in the configuration, it will notify the subscribing client in real time, thus achieving the goal of obtaining the latest configuration information.

In the distributed search service, the meta-information of the index and the node state of the server cluster machine are stored in some designated nodes of the ZK for each client subscription.

Distributed log collection system. The core job of this system is to collect logs distributed on different machines. The collector usually allocates the collection task unit according to the application, so it is necessary to create a node P with the application name as path on the ZK, and register all the machine ip of the application on the node P in the form of child nodes, so that when the machine changes, it can notify the collector to adjust the task assignment in real time.

Some information in the system needs to be obtained dynamically, and there will be manual questions to modify this information. Usually an interface, such as the JMX interface, is exposed to get some information about the runtime. With the introduction of ZK, you don't have to implement your own solution, just store the information on the specified ZK node.

Note: in the above-mentioned application scenarios, there is a default premise: scenarios where the amount of data is small, but the data may be updated quickly.

Load balancing

Load balancing here refers to soft load balancing. In a distributed environment, in order to ensure high availability, the same application or provider of the same service will usually deploy multiple copies to achieve peer-to-peer services. Consumers have to choose one of these peer-to-peer servers to execute the relevant business logic, among which the typical one is the producer and consumer load balance in message middleware.

The load balancing of publishers and subscribers in message middleware, linkedin's open source KafkaMQ and Ali's open source metaq all achieve the load balance between producers and consumers through zookeeper. Let's take metaq as an example:

Producer load balancing: when metaq sends messages, producers must select a partition on a broker to send messages. Therefore, metaq will register all broker and corresponding partition information on ZK designated nodes during operation. The default policy is a sequential polling process. Producers obtain the partition list through ZK. It is organized into an ordered list of partitions in the order of brokerId and partition, and a partition is selected to send the message in a cyclic manner from beginning to end.

Consumption load balancing:

During the consumption process, a consumer will consume messages in one or more partitions, but a partition will only be consumed by one consumer. MetaQ's consumption strategy is:

Each partition mounts only one consumer for the same group.

If the number of consumers in the same group is greater than the number of divisions, the extra consumers will not participate in the consumption.

If the number of consumers in the same group is less than the number of divisions, some consumers need to take on additional consumption tasks.

In the event of a consumer failure or restart, other consumers will perceive the change (through the zookeeper watch consumer list) and then rebalance the load to ensure that consumers are available for consumption in all sectors.

Naming Service (Naming Service)

Naming service is also a common scenario in distributed systems. In a distributed system, by using naming services, client applications can obtain information such as the address and provider of resources or services according to the specified name. Named entities can usually be machines in a cluster, service addresses provided, remote objects, and so on-all of which we can collectively call names (Name). One of the more common is the list of service addresses in some distributed service frameworks. By calling the API provided by ZK to create the node, you can easily create a globally unique path, which can be used as a name.

Alibaba Group's open source distributed service framework Dubbo uses ZooKeeper as its naming service to maintain a global list of service addresses. Click here to view the Dubbo open source project. In the Dubbo implementation:

Upon startup, the service provider writes its URL address to the specified node / dubbo/$ {serviceName} / providers directory on the ZK, which completes the publication of the service.

When the service consumer starts, subscribe to the provider URL address in the / dubbo/$ {serviceName} / providers directory and write its own URL address to the / dubbo/$ {serviceName} / consumers directory.

Note that all addresses registered with ZK are temporary nodes, which ensures that service providers and consumers are automatically aware of changes in resources.

In addition, Dubbo has monitoring for service granularity by subscribing to the information of all providers and consumers under the / dubbo/$ {serviceName} directory.

Distributed notification / coordination

ZooKeeper has a unique watcher registration and asynchronous notification mechanism, which can well realize the notification and coordination between different systems in the distributed environment, and realize the real-time processing of data changes. The method of use is usually that different systems register the same znode on the ZK and listen for changes in the znode (including the contents of the znode itself and its child nodes). If one system update the znode, the other system can receive the notification and deal with it accordingly.

Another heartbeat detection mechanism: the detection system and the detected system are not directly related, but through the association of a node on the zk, the system coupling is greatly reduced.

Another system scheduling mode: a system consists of a console and a push system, and the duty of the console is to control the push system to carry out the corresponding push work. Some of the operations that managers do in the console actually modify the status of some nodes on the ZK, and ZK notifies them of these changes to the client that registers Watcher, that is, the push system, and then makes the corresponding push task.

Another work reporting mode: some similar to the task distribution system, after the sub-task starts, register a temporary node to zk, and report their progress regularly (write the progress back to this temporary node), so that the task manager can know the progress of the task in real time.

In short, using zookeeper for distributed notification and coordination can greatly reduce the coupling between systems.

Cluster Management and Master Election

Cluster machine monitoring: this is usually used in scenarios with high requirements for the status and online rate of machines in the cluster, and can quickly respond to machine changes in the cluster. In such scenarios, there is often a monitoring system that detects the survival of cluster machines in real time. In the past, the monitoring system used to regularly detect each machine through some means (such as ping), or each machine regularly reported to the monitoring system, "I am still alive." This is possible, but there are two obvious problems:

When there are changes in the machines in the cluster, there are more things that are involved and modified.

There is a certain delay.

Taking advantage of the two features of ZooKeeper, you can monitor the viability of another cluster machine in real time:

If the client registers a Watcher on node x, then what if x? The client is notified when the child node of the

Create a node of type EPHEMERAL that disappears once the client and server session ends or expires.

For example, the monitoring system registers a Watcher on the / clusterServers node and creates an EPHEMERAL node under / clusterServers: / clusterServers/ {hostname} each time the machine is added dynamically. In this way, the monitoring system can know the increase and decrease of the machine in real time, and the follow-up processing is the business of the monitoring system.

Master election is the most classic application scenario in zookeeper.

In a distributed environment, the same business applications are distributed on different machines, and some business logic (for example, some time-consuming computing, network I and O processing) often only need to be executed by one machine in the whole cluster, and the rest of the machines can share this result, which can greatly reduce repetitive work and improve performance, so the master election is the main problem encountered in this scenario.

Using the strong consistency of ZooKeeper, we can ensure the global uniqueness of node creation in the case of distributed high concurrency, that is, there are multiple client requests to create / currentMaster nodes at the same time, and only one client request can be created successfully. With this feature, cluster selection can be easily carried out in a distributed environment.

In addition, this scenario evolves to be dynamic Master elections. This is going to use the features of the EPHEMERAL_SEQUENTIAL type node.

As mentioned above, only one of all client creation requests can be created successfully. With a slight change here, all requests are allowed to be created successfully, but there must be a creation order, so there is a possibility that all requests will eventually create results on ZK: / currentMaster/ {sessionId}-1,? / currentMaster/ {sessionId}-2,? / currentMaster/ {sessionId}-3... .. Every time the machine with the lowest serial number is selected as the Master, if the machine dies, because the node it creates will be hourly immediately, then the smallest machine after that will be Master.

In the search system, if each machine in the cluster generates a full index, it is not only time-consuming, but also can not guarantee that the index data is consistent with each other. So let the Master in the cluster generate the full index and then synchronize it to other machines in the cluster. In addition, the disaster recovery measure of Master election is that master can be specified manually at any time, that is, when zk is unable to obtain master information, it can obtain master from a place through, for example, http.

In Hbase, ZooKeeper is also used to implement dynamic HMaster elections. In the implementation of Hbase, some addresses of ROOT table and HMaster will be stored on ZK, and HRegionServer will register itself in Zookeeper as a temporary node (Ephemeral), so that HMaster can sense the survival status of each HRegionServer at any time. At the same time, if there is a problem with HMaster, it will re-elect a HMaster to run, thus avoiding the single point of HMaster problem.

Distributed lock

Distributed lock, which is mainly due to the fact that ZooKeeper ensures strong data consistency for us. Lock services can be divided into two categories, one is to keep exclusive, the other is to control the timing.

Maintaining exclusivity means that only one client who tries to acquire the lock can successfully acquire the lock. The usual practice is to treat a znode on zk as a lock, which is implemented by create znode. All clients create the / distribute_lock node, and the client that is successfully created owns the lock.

Control timing, that is, all the views to acquire the lock of the client, will eventually be scheduled to execute, but there is a global timing. The practice is similar to the above, except that / distribute_lock already exists here, and the client creates a temporary ordered node under it (this can be specified by the node's attribute control: CreateMode.EPHEMERAL_SEQUENTIAL). The parent node (/ distribute_lock) of the Zk maintains a copy of the sequence, which ensures the timing of the creation of the child nodes, thus forming the global timing of each client.

Distributed queue

In terms of queues, there are two kinds of queues, one is the conventional first-in-first-out queue, and the other is to wait for the queue members to gather before they are executed in order. For the first FIFO queue, which is consistent with the basic principle of the control timing scenario in the distributed lock service, I will not repeat it here.

The second queue is actually an enhancement based on the FIFO queue. Usually, you can set up a / queue/num node in advance under the znode of / queue, and assign a value of n (or directly assign n to / queue) to indicate the queue size. After that, each time a queue member joins, you can determine whether the queue size has reached the queue size and decide whether execution can begin. A typical scenario for this usage is that in a distributed environment, a large task Task A can only be done when many subtasks are completed (or conditionally ready). At this time, when one of the subtasks is completed (ready), then set up your own temporary timing node (CreateMode.EPHEMERAL_SEQUENTIAL) under / taskList. When / taskList finds that the number of child nodes below it meets the specified number, it can proceed to the next step in sequence processing. Last sentence, share my Redis cache technology exchange group: 1903832579

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.