With the rapid development of Internet technology, distribution has become an unavoidable topic. In a distributed environment, the scenario of "high concurrent access to shared resources" is not uncommon, and the problems caused are also obvious: Shared resources are in Data inco

With the rapid development of Internet technology, distribution has become an unavoidable topic. In a distributed environment, the scenario of "high concurrent access to shared resources" is not uncommon, and the problems caused are also obvious: Sharing Data inconsistency or unexpected results occur before and after the resource is accessed!!!

In the single era, you can use ReentrantLock or Synchronized provided by the JVM to solve the problem. In the distributed environment, the JVM is a little unable to do what it wants. Ever since, "distributed lock" appeared.

1

What is a distributed lock?

In computer science, locks and mutexes are synchronization mechanisms used to limit resources when many threads are executing.

distributed lock can be understood as controlling the distributed system to operate shared resources in an orderly manner and maintaining consistency through mutual exclusion.

. What characteristics should distributed locks have?

distributed lock is a multi-service shared lock. In a distributed deployment environment, the lock mechanism is used to allow clients to access shared resources mutually exclusive and should have the following characteristics.

Mutual exclusivity: At the same time, it is guaranteed that shared resources can only be accessed by one thread of one client and are exclusive.

Anti-deadlock: After a period of time, the lock will definitely be released (normal release or abnormal release).

High availability: The mechanism for acquiring locks must be highly available and perform well.

blocking lock (optional): The current resource has been locked. Should other clients or threads block and wait, or return immediately.

Reentrant (optional): Whether the holder of the current lock can enter again.

Fairness (optional): Is the locking order consistent with the locking request order, or is the lock snatched randomly.

. What scenarios can distributed locks solve?

distributed lock is used to solve the problem of data inconsistency caused by high concurrent access. Here are several common scenarios.

Multiple users modify the data, resulting in inaccurate data: Multiple requests modify the same data at the same time, resulting in inaccurate data. For example, "place an order to reduce inventory," "Internet flash sales," "grab red envelopes," "grab tickets," "grab coupons," "select an Internet number," "transfer," etc.

Multiple requests, duplicate data: When the request result is not returned yet, multiple operations or retries are performed, resulting in multiple identical requests. If successful without locking, many duplicate records will be generated.

Distributed coordination: In a distributed environment, multiple machines can perform tasks, but only one machine can perform it at a time. It can also be marked with a distributed lock, and only the machine that obtains the lock can perform it.

. What are the implementation methods of distributed locks?

Regarding locks, Java provides a wide variety of locks. Each lock has different characteristics and can show very high efficiency in appropriate scenarios.

"Distributed Lock" is actually a solution, not a proprietary component or class. Implementing this solution still requires additional components or middleware to assist, and even in some cases, it needs to be implemented at the database level. .

Regarding the implementation of distributed locks, there are three popular ones in the industry:

Based on the database: is implemented with the help of database locks. The implementation is simple, but performance is the biggest problem. (Not recommended)

is based on Redis: CAP model belongs to AP, has no consistency algorithm and is fast.(Recommended for high-performance scenarios)

is based on Zookeeper: CAP model belongs to CP, has high reliability and worse performance than Redis. (Recommended for high-reliability scenarios)

In addition, etcd and consul can be used to implement it.

At this point, we have a general understanding of the characteristics, usage scenarios, and implementation methods of distributed locks. So, how should a high-performance distributed lock be designed? please watch the following part.

2

How to design distributed locks in high concurrency scenarios?

Because of the excellent performance of Redis, in high-concurrency environments, the Redis solution is the most used. , are the most complex to implement and the most prone to problems.

Next, use Redis to implement an inventory bonus lock example, and elaborate on the design principles and ideas of distributed locks.

demand scenario: Assume that there are 100 items in stock, and orders are placed through Internet flash sales. It is required that they are sold out and not oversold.

distributed simulation: enables 2 services to simulate a distributed environment, and the front end uses Nginx to distribute requests.

Concurrency tool: Use JMeter to simulate concurrent requests from multiple users concurrently.

, stock reduction without lock

Let’s first take a look at the situation without lock. What problems will there be when placing orders to reduce stock? The specific code is as follows:

Concurrent request simulation:

Test plan - Add thread group (configure thread properties)

Thread group - Add -Sampler -HTTP request (Configure http request address)

HTTP request - Add listener (graphical results, view result tree) )

option - Log Viewer (open the log)

The execution results are as follows:

The problem is obvious. When the inventory is 1, 3 orders were successfully completed. This result is not what we expected.

This is because in a distributed environment, when there is only 1 inventory, 3 threads read the inventory at the same time and complete the order. This problem of inaccurate data caused by multi-user access can be solved with distributed locks.

Next, let’s see how to implement distributed locks using Redis.

, distributed lock implementation (junior version)

According to the previous introduction, distributed locks must have the following three characteristics:

Mutual exclusivity: Only the thread that obtains the lock can access.

anti-deadlock: Set automatic deletion upon expiration to achieve deadlock caused by interpretation failure.

high availability: guaranteed by the high availability of Redis Cluster. The implementation idea of ​​

is very simple: before accessing the inventory, write a lock flag to Redis. After the access is completed, the lock is deleted. Only those who have obtained the lock can access.

sets the expiration time to clean up locks that have not been successfully deleted.

sets the identity of the locked person to prevent accidental deletion by others.

Redis provides rich command operation functions. JAVA can be operated with RedisTemplate. The code is as follows:

Let’s take a look at the result again:

. The execution result is normal. At this point, a simple distributed lock is completed.As a rigorous programmer, you may still have many questions: What if the lock is set successfully but the expiration time fails? What should I do if the expiration time comes and the business is not completed? If the lock is not acquired and you want to wait for the lock to be free before acquiring it, how to achieve this? What should I do if the locking method calls other methods, and other methods call the locking method and need to enter the lock multiple times? For production-level use of

, you also need to implement: atomic operations, renewal, blocking acquisition, and support for reentrant . Please read on for the specific implementation method of

.

, distributed lock implementation (advanced version)

Based on the above problems, you may have thought of a solution, such as:

Atomic operation: It can be implemented through the Lua script function provided by Redis.

renewal: You can use an asynchronous thread to automatically renew, or you can explicitly call the renewal method.

blocking acquisition: Set the waiting time when acquiring the lock, and internally use loop spin to acquire the lock until timeout.

re-entry: It can be stored through the Redis Hash structure, recording key and value at the same time, and entering value+1 each time.

Let’s briefly introduce the Lua script:

Redis Lua script

launched the script function from redis 2.6.0, allowing developers to write scripts in Lua language and pass them to Redis for execution. Benefits of using scripts:

- Reduce network overhead

- Atomic operation

- Replace Redis's transaction function

Next, we analyze the complete process of locking, re-entry, and unlocking.

Locking (renewal) principle

Reentrancy principle

The data structure is similar to Java's Map key, Mapkey1, value type, where key is the lock name, key1 is the client information, and value is the number of reentries.

data structure design: project name+keyName, hostaddress+uuid: thread ID, number of re-entries. Every time

re-enters, the value is +1.

Unlocking principle

When unlocking, first determine the thread information (only the lock of the current thread can be operated), then reduce the number of locks by 1, and delete the lock when the number is 0.

locked and reentrant Lua script:

Redis command explanation:

EXISTS key: check Whether the given key exists, returns 1 if it exists, 0 otherwise.

HSET key field value : Set the value of field field in hash table key to value.

PEXPIRE key milliseconds : Set the key's survival time in milliseconds.

HEXISTS key field: Check whether the given field field exists in the hash table key.

HINCRBY key field increment: adds increment to the value of field field in hash table key.

PTTL key : Returns the remaining survival time of the key in milliseconds.

Unlock Lua script:

Script execution:

Execute Lua script through the following two methods (load once, execute multiple times).

String hash = redisCluster .scriptLoad( script , key);

Object result = redisCluster .evalsha( hash , keys, args);

implements the above functions, and an enterprise-level high-availability distributed lock is basically completed.

Of course, during the implementation process, many details need to be considered, such as: retrying if script loading fails, Redis cluster routing, retrying if script execution fails, etc.

By the way, the full version of "lock-sdk" has been released in the company's maven repository and can be used directly. The high-performance version of Redis implements CashCloud access internally and uses locks in the annotation method. A high-reliability version of Zookeeper will also be implemented in the future.

The last words

This article introduces the characteristics, application scenarios, and implementation methods of distributed locks. It also uses an example of designing distributed locks based on Redis to introduce the design principles and ideas of distributed locks. I hope it will help everyone understand distributed locks. Locks have a newer understanding.

Redis is only one of the solutions, and it cannot guarantee 100% consistency. For example, if the Redis cluster Master is successfully locked, the Master hangs up before it can be synchronized to the Slave node. In this scenario, data inconsistency will also occur. question. If you have higher requirements for reliability, you can choose the Zookeeper implementation. For another example, the Internet flash sale scenario cannot be fully supported based only on a distributed lock. A segmented inventory lock mechanism may need to be introduced to achieve this.

No technology is omnipotent. No technical solution can solve the problems of all business scenarios. I hope everyone can choose the appropriate technical solution according to the business scenario!

Hope the above content can be helpful to those in need