1. Introduction to distributed locks
1.1 What is distributed lock
In stand-alone applications, Java's built-in lock mechanisms (such as synchronized, ReentrantLock, etc.) can be used to achieve synchronization between threads. However, in a distributed environment, since the application is deployed on multiple servers, traditional stand-alone locks cannot meet the needs, and distributed locks are needed.
Distributed lockIt is a cross-JVM and cross-server lock mechanism. It can perform mutually exclusive access control of shared resources in a distributed system, ensuring that only one client can obtain the lock and perform operations at the same time.
1.2 Distributed lock application scenarios
- Prevent repeated orders: In the e-commerce system, prevent users from submitting orders repeatedly
- Flash kill system: Control concurrent access to commodity inventory and avoid overselling
- Timing tasks: Ensure that in the cluster environment, the timing tasks are executed by only one node
- Data consistency protection: Protect data consistency across systems
1.3 Core requirements for distributed locks
- Mutual Exclusion: At any time, only one client can hold the lock
- Reentrability: The same client can acquire the same lock multiple times
- Deadlock: Even if the client crashes, the lock should be automatically released after a certain period of time.
- Highly available: Distributed lock service should not become a single point of failure of the system
- performance: The lock operation should have high performance and low latency characteristics
2. Introduction to Redisson
2.1 What is Redisson
Redisson is a Java in-memory data grid implemented on Redis. It provides distributed and extensible Java data structures, including distributed locks, distributed collections, distributed objects and other functions.
2.2 Comparison between Redisson and Jedis and Lettuce
- Jedis: Redis's Java client, which provides the basic encapsulation of Redis commands. The API is simple and intuitive, but the functions are relatively basic
- Lettuce: Advanced Redis client, based on Netty, supports asynchronous operation, and performs better than Jedis
- Redisson: Not only provides Redis client functions, but also provides more advanced distributed features such as distributed locks and distributed collections, making them more friendly to distributed development
2.3 Redisson's main functions
- Distributed locks and synchronizers: distributed lock, read and write lock, semaphore, lock, etc.
- Distributed Collections: Distributed implementation of data structures such as Map, Set, List, etc.
- Distributed Services: Remote service, real-time object service, etc.
- Distributed execution services: distributed execution services, scheduling task services, etc.
3. The implementation principle of Redisson distributed lock
3.1 Redis-based lock implementation
Redisson's distributed lock is based on RedisEVALCommand (execute Lua script) implementation. It uses a Redis key-value pair to represent the lock, the key is the name of the lock, and the value contains the lock's holder information and expiration time.
Basic process:
- Get the lock: Try to set a key-value pair in Redis through Lua script, and get successful if the key does not exist.
- Holding of locks: Set the expiration time for this key (avoid deadlock)
- Release of lock: Delete the corresponding key by executing the Lua script
- Renewal of lock: Extend the expiration time of the lock through the watchdog mechanism
3.2 Lock implementation plan
Redisson provides a variety of lock implementation solutions:
- Normal reentrant lock (RLock): The most basic distributed lock implementation, supports reentrant
- Fair Lock (RFairLock): Obtain locks in order of request
- Read and write lock (RReadWriteLock): Read lock sharing, write lock exclusive
- Multi-Lock (RedissonMultiLock): Multiple locks can be combined into one lock
- Red Lock (Redisson RedLock): High reliability lock implementation based on Redis cluster, can resist some node failures
3.3 Lock acquisition and release process
Lock acquisition：
-- KEYS[1] is the key of the lock, ARGV[1] is the thread identifier, ARGV[2] is the expiration time
if (('exists', KEYS[1]) == 0) or (('hexists', KEYS[1], ARGV[1]) == 1) then
('hincrby', KEYS[1], ARGV[1], 1);
('pexpire', KEYS[1], ARGV[2]);
return nil;
end;
return ('pttl', KEYS[1]);Release of lock：
-- KEYS[1] is the key of the lock, and ARGV[1] is the thread identifier
if (('hexists', KEYS[1], ARGV[1]) == 0) then
return nil;
end;
local counter = ('hincrby', KEYS[1], ARGV[1], -1);
if (counter > 0) then
return 0;
else
('del', KEYS[1]);
return 1;
end;4. Use of Redisson distributed locks
4.1 Maven dependency configuration
<dependency>
<groupId></groupId>
<artifactId>redisson</artifactId>
<version>3.23.3</version>
</dependency>
4.2 Basic configuration
@Configuration
public class RedissonConfig {
@Value("${}")
private String host;
@Value("${}")
private int port;
@Value("${}")
private String password;
@Value("${}")
private int database;
@Bean
public RedissonClient redissonClient() {
Config config = new Config();
()
.setAddress("redis://" + host + ":" + port)
.setDatabase(database);
if (password != null && !()) {
().setPassword(password);
}
return (config);
}
}
4.3 Use of basic locks
@Service
public class LockService {
@Resource
private RedissonClient redissonClient;
public void doSomething() {
RLock lock = ("myLock");
try {
// Try to acquire the lock, wait for up to 100 seconds, the lock validity period is 30 seconds
boolean isLocked = (100, 30, );
if (isLocked) {
// Business processing
("Execute business logic");
}
} catch (InterruptedException e) {
().interrupt();
} finally {
// Release the lock
if (()) {
();
}
}
}
}4.4 Use of different types of locks
- Reentrable lock (RLock)
RLock lock = ("myLock");
();
try {
try {
();
} finally {
();
}
} finally {
();
}
- Fair Lock (RFairLock)
RLock fairLock = ("myFairLock");
();
try {
// Business processing
} finally {
();
}- Read and write lock (RReadWriteLock)
RReadWriteLock rwLock = ("myRWLock");
// Read lock (shared)
RLock readLock = ();
();
try {
// Read operation
} finally {
();
}
// Write lock (exclusive)
RLock writeLock = ();
();
try {
// Write operation
} finally {
();
}- Multi-Lock (RedissonMultiLock)
RLock lock1 = ("lock1");
RLock lock2 = ("lock2");
RLock lock3 = ("lock3");
// Combine multiple locks
RedissonMultiLock multiLock = new RedissonMultiLock(lock1, lock2, lock3);
();
try {
// Business processing
} finally {
();
}5. Detailed explanation of the watchdog mechanism
5.1 What is the watchdog mechanism
Watchdog mechanismIt is an automatic renewal function provided by Redisson for distributed locks. It can automatically extend the validity period of the lock during the client's lock holding period, preventing the lock from expired and being acquired by other clients due to the long execution time, thereby destroying mutex.
5.2 How the Watchdog works
- When the client calls
lock()When the method acquires the lock (no expiration time is set), Redisson will set a 30-second lock validity period by default. - At the same time, it will start a timed task, which will check every 10 seconds by default (1/3 of the lock validity period)
- If the client still holds the lock, the timed task will automatically refresh the lock for 30 seconds.
- This process will continue until the client releases the lock automatically, or the client crashes (the watchdog stops working and the lock will be automatically released after 30 seconds)
5.3 Key source code analysis of watchdogs
The core implementation of watchdogs in Redisson isIn class:
// Automatic renewal logic of lock
private void scheduleExpirationRenewal(long threadId) {
ExpirationEntry entry = new ExpirationEntry();
ExpirationEntry oldEntry = EXPIRATION_RENEWAL_MAP.putIfAbsent(getEntryName(), entry);
if (oldEntry != null) {
(threadId);
} else {
(threadId);
renewExpiration();
}
}
// Renewal timed tasks
private void renewExpiration() {
Timeout task = ().newTimeout(new TimerTask() {
@Override
public void run(Timeout timeout) throws Exception {
// Renewal logic
// ...
// After every internalLockLeaseTime/3 time, recheck and renew
().newTimeout(this,
internalLockLeaseTime / 3, );
}
}, internalLockLeaseTime / 3, );
}5.4 Enable and turn off the watchdog mechanism
Enable the watchdog mechanism(default):
// No expiration time is specified, the watchdog mechanism is enabled by default
();Disable the watchdog mechanism：
// Clearly specify the expiration time, the watchdog mechanism will be disabled
(10, 30, );5.5 Watchdog configuration parameters
The default behavior of the watchdog can be modified by configuration:
// Set the default expiration time of the lock (the watchdog renewal interval is 1/3 of this value)
Config config = new Config();
(30000); // 30 seconds
RedissonClient redisson = (config);6. Best practices for distributed locks
6.1 Rational use of watchdog mechanism
- For tasks with uncertain execution time, it is recommended to use the watchdog mechanism
- For tasks with a short execution time, the expiration time can be clearly set and the watchdog can be turned off.
6.2 Selection of the granularity of the lock
- Minimize the granularity of the lock, such as locking a specific object instead of the entire method
- Use different lock names to distinguish different business operations
6.3 Lock release guarantee
- Always release the lock in the finally block
- Check whether the current thread holds a lock before release (isHeldByCurrentThread)
try {
// Business logic
} finally {
if (()) {
();
}
}6.4 Failed to retrieve the lock
- Set reasonable waiting time
- Implement the retry mechanism
- Provide a downgrade strategy
int retryCount = 3;
while (retryCount > 0) {
boolean locked = (5, );
if (locked) {
try {
// Business logic
return result;
} finally {
();
}
}
retryCount--;
(1000);
}
// downgrade processing
return fallbackMethod();7. Comparison of Redisson distributed locks and other implementations
7.1 Comparison with Redis native command implementation
Redis native commands (SETNX + EXPIRE):
- Advantages: Simple implementation, no dependency on extra libraries
- Disadvantages: It is difficult to ensure atomicity, cannot solve the problem of lock expiration, and does not support reentry
Redisson：
- Advantages: It realizes advanced features such as reentry, automatic renewal, and fair locking.
- Disadvantages: Additional dependencies, certain learning costs
7.2 Comparison with Zookeeper implementation
Zookeeper：
- Advantages: Strong consistency guarantee, automatic release of temporary node mechanism, orderly support
- Disadvantages: Low performance, suitable for high-reliable low-frequency operation
Redisson：
- Advantages: High performance, rich functions, suitable for high-frequency operation
- Disadvantages: In some extreme cases, the consistency is not as good as Zookeeper
7.3 Applicable scenarios for various implementations
- Redisson: Suitable for high-performance scenarios, the consistency requirements are not very high but the requirements are low latency
- Zookeeper: Suitable for high reliability scenarios, low performance requirements but strong consistency
- Database lock: Suitable for scenarios that are closely integrated with data operations
- etcd: Suitable for medium performance scenarios with high requirements for reliability and consistency
8. Frequently Asked Questions and Solutions
8.1 The problem of error deletion of locks
question: One client releases locks held by other clients
Solution：
- Redisson stores thread identifiers in lock value to ensure that only threads holding locks can be released.
- Passed when released
isHeldByCurrentThread()Method Check
8.2 Lock expiration issue
question: The business execution time exceeds the validity period of the lock
Solution：
- Automatic renewal using watchdog mechanism
- Rationally evaluate business execution time and set sufficient lock validity period
8.3 Cache Crash and Recovery
question: Redis server failure or restart
Solution：
- Improve availability with Redis clusters
- Use RedissonRedLock in critical business
- Implement business compensation mechanism
8.4 Performance optimization
- Reduce locking particle size
- Set the lock waiting timeout appropriately
- Avoid long-term lock holding
- Use read and write lock to separate read and write operations