“This is the 27th day of my participation in the First Challenge 2022. For details: First Challenge 2022”

What can Zookeeper do

1. Zookeeper Unfair lock, fair lock, or shared lock

2. Application of Leader election in distributed scenario

3. Spring Cloud Zookeeper registry

Distributed lock of ZooKeeper

Not fair lock

What is an unfair lock? A metaphor, is the ticket window, only to stand in the channel, to buy tickets. The first person to go should have the right of first refusal, but the following group of people rush to buy tickets, without any restriction, crowded to the ticket window, resulting in the weak N was pushed to the back, the strong X occupied the ticket booth (create-e /exclusive/lock). Priority purchase is available. Isn’t that unfair to N. In the process of buying tickets at number X, the rest of the people are staring at number X (get-W /exclusive/lock), as soon as number X has bought a ticket (delete /exclusive/lock), the rest of the people are crowding again, Preempt the ticket purchase channel (create-E/EXCLUSIVE /lock) to preempt the ticket purchase right.This is an unfair lock, known as:Herd effect

The process is as follows:As implemented in concurrency issues more serious cases, the comparison of performance will decline, the main reason is that all connections are listening to the same node, when the server detected to delete the event, to inform all connections, all connections at the same time receive events, concurrent competitive again, this is herd behaviour. This type of locking is an implementation of unfair locking: to avoid it, look at the following.

Fair lock

The ticket office was reported that the order of ticket sales was too disorderly and needed to be cleaned up, and then the plan came to make everyone queue up in order, first come, first buy. Then thought a method, each comes a person to send a number to him according to the order, the number in front of the row is the smallest, the number in the future is bigger, so the person who holds the number, as long as the front number of the ticket buyer on the line, as long as the front of the ticket purchase personnel to leave the ticket channel that is his next.

The flow chart is as follows

As mentioned above, with the help of temporary sequential nodes, concurrent lock contention of multiple nodes can be avoided and the server pressure is relieved. This way all lock requests are queued, yesFair lockThe concrete implementation of.

A Shared lock

This ticket office is also unlucky, and soon suffered a complaint, the reason is: some people idle nothing, although not buy a ticket, but also in the queue, want to ask the window row to his time there is no ticket (really think of what scene, just do), the masses have ideas, must solve is not.

Internal meetings were held to discuss the issue

1. Inconsistent reading and writing

As shown in the figure above, three threads come in at the same time, but each thread executes at different times for various reasons.

1, thread 1, write to database 10, delete cache

2, thread 3, read cache no data, and then query the database, start to do their own business logic

Thread 2 updates the database to 6 and removes the cache

4, thread 3, after doing its own logic, update cache to 10 (previously read 10)

This also results in cache accuracy.

2, double write inconsistent

Thread 1 updates the database, but for some reason the cache is not updated in time.

Thread 2 comes in and updates the data, and then updates the cache.

3, thread 3, execute logic, update cache, at this time thread 2’s cache update

This makes the cache inaccurate.

3. Realization principle of shared lock

The above two locking methods have a common characteristic, that is, they are mutually exclusive, can only be occupied by one request at a time, if a large number of concurrent, performance will be dramatically reduced, all requests have to lock, is it true that all requests need to lock? The answer is no, for example, if the data has not been modified, there is no need to lock, but if the read request is not finished, then a write request is received, what happens? You can’t write data when someone is already reading it, otherwise the data will be incorrect. A write request cannot be executed until all previous read locks are released, so a read request needs to be identified (read locks) to let the write request know that the data cannot be modified at this time. Otherwise the data would be inconsistent. If data is already being written, another data write request is not allowed. In this case, data inconsistency may occur. Therefore, a write lock is required for all write requests to avoid simultaneous write operations on shared data.

As shown in the figure above, if there is a write request, he only needs to watch the nearest node in order before him. If there are multiple read requests between two write requests, the last read request does not need to listen for the previous read request, but only for the previous read request. Once the write request is complete, the read operation can be performed. So that’s oneA Shared lock.