Redis
Version a: Redis determine whether the value is no bonus
cause problems: 1, 2 atomic operation is not a lock, if the lock down, system deadlock
Version two: redis locking atomic operations (setnx), plus lock expiration time
cause problems: 1, if set the expiration time 2s, program execution 3s, the release of someone else's lock
Version three: put a value on the random redis lock, and then determine a random value to delete lock
cause problems: 1, deletion is not an atomic operation, delete the situation there will be someone else's lock
Version four: redis remove the lock by lua script to achieve (judgment equal deleted)
remaining issues: the above problems are for a single node in terms of the actual production is redis clusters, redis master-slave replication is asynchronous.
database
Main library from the library database and inconsistent, so there are several common optimization:
(1) business can be accepted, the system does not optimize
(2) reads the main force, the main library availability, increase read performance by caching
(3) recording which records write request occurred in the cache, to route read or read from the master
Here, it is about the best solution, but also redis officially recommended Redisson
Config config = new Config();
config.useClusterServers()
.addNodeAddress("redis://192.168.31.101:7001")
.addNodeAddress("redis://192.168.31.101:7002")
.addNodeAddress("redis://192.168.31.101:7003")
.addNodeAddress("redis://192.168.31.102:7001")
.addNodeAddress("redis://192.168.31.102:7002")
.addNodeAddress("redis://192.168.31.102:7003");
RedissonClient redisson = Redisson.create(config);
RLock lock = redisson.getLock("anyLock");
lock.lock();
lock.unlock();
It is that simple, we only need to complete the distributed lock through its api in the lock and unlock, he helped us a lot of details to consider:
- redisson all instructions are executed, redis support lua lua script by script execution atomicity
- redisson a key set of default expiration time for the 30s, if a client holds a lock exceeds the 30s how to do?
- redisson in the concept of a watchdog, which translates to the watchdog, it will lock after you get, every 10 seconds to help you put the key timeout to 30s
- In this case, even if the lock would not have been holding key has expired, other threads to acquire a lock problem.
- redisson of "watchdog" logic ensures that no deadlock occurs.
(If the machine is down, the watchdog also gone. At this point it will not extend the expiration date of the key, to automatically expire after 30s, other threads can get to lock)
The following article was written well, look at this record
https://baijiahao.baidu.com/s?id=1623086259657780069&wfr=spider&for=pc&isFailFlag=1
https://blog.csdn.net/john1337/article/details/98850192
HTTP: //blog.itpub.net/29715045/viewspace-2650976/
