Two types of locks:
1. JVM lock
2. Distributed microservice architecture, a kind of lock added between each microservice after splitting to avoid conflicts and database failures, distributed lock.
Between multiple services + guarantee in the same time period + the same user can only have one request (to prevent data conflicts and concurrency errors in key services)
The formula for creating microservices:
1. Build Module
2. Change pom
3. Write yaml
4. Main start
5. Write business
6. Small test
Synchronized: Either the thread releases the lock or reports an error, which may cause a large backlog of threads.
ReentrantLock: Give up if the lock is not obtained within the specified time.
The problem of tryLock distributed locking:
1. If you lock each service, but only lock the service, you may still be oversold.
SetIfAbsent (the name of the lock, the fixed sign) After the
lock is successful, the operation is completed Perform the corresponding delete lock operation for the corresponding task.
1. Ensure that the lock can be deleted even if an exception occurs, so use try-catch-finally
2. The program is down and may not be able to go to the finally method, so the lock cannot be deleted. At this time, you need to add an expiration time to limit the key usage: RedisTemple.expire(key,10L,TimeUtil.SECONDS) Set 10 seconds
3. If redis lock and set expiration time are separated, it is not atomic. In order to ensure atomicity, use IfAbsent to set the key and expiration time.
4. The thread running time is greater than the expiration time: the thread that went first may delete the lock of the subsequent thread, and the data is inconsistent. Therefore, before deleting the lock, judge the lock to determine whether the value of the lock is the current value. If it is not, the key will not be deleted.
5. Finally and del are not atomic: the solution is to use the lua script if the lua script does not use the lua script. Use redis' own transaction
Redis transaction: redis transaction
multi: start a transaction, either succeed at the same time or fail at the same time.
exec: Submit the transaction
WATCH key: It means that other processes cannot modify the key, otherwise the modification will fail
. 6. Use JedisPool
7. How to ensure that the expiration time of redis is greater than the business execution time, and how to renew the redis distributed lock.
8. Redis AP: lock loss caused by asynchronous replication For
example: the master node has not had time to transfer the newly set data to the slave node, and hangs the
cp of zookeep:
redis lock: redis lock interprets redisson to
avoid unlocking exception: the solution is not your current lock