Distributed Lock usage scenarios
- Idempotency solve business layer, to prevent double-clicks (such as update interface)
- Ensure that only one end of the settlement process the message MQ consumer acceptance of multi-terminal end of the same message
- When performing regular tasks using the schedule, when the multi-instance deployment is only one example of mission
Redis
Feature
- Single-threaded serial processing
- Acquiring the lock particularly good performance
- setnx there is no success or failure is set
- No heartbeat mechanism needs to be set expiration time
- AP model of the CAP, because using a gossip protocol, so it is not strong consistency
Acquire the lock multiple business scenarios
Lock expiration time setup issues
After locking the 10s expired, but the business performed 30s (likely to encounter fullgc, the cycle of death and other scenes).
Master-slave switch problem
1 acquire service from the main lock, the main hang up at this time, mainly from the promotion, never happens at this time the lock synchronization value.
Zookeeper
Feature
- Ordered nodes, the nodes are ordered by name
- Temporary node, the client is disconnected automatically disappear
- Event monitoring, event notification when the next node will update occurs
- ZAB agreement, strong consistency, belong to CP model
- After zk cluster increases, performance continued to decline
Acquire the lock multiple business scenarios
The client or hang suspended animation
The client will temporarily disconnect delete nodes, lock it with the release. Another business can acquire a lock.
But in fact, the client did not hang, just to maintain the interruption of the heartbeat. There are a lot of reasons, such as fullgc, network problems (redis network problems encountered get up to lock failure) and so on.
Etcd
Feature
- Key exists if it can not be written, it means you can not get to the lock, if the cluster, you can write Key, it means get to get a lock.
- Raft ensure the consistency, strong consistency of the cluster, and the data can be persisted
- No heartbeat mechanism needs to be set expiration time
Acquire the lock multiple business scenarios
Lock expiration time setup issues
After locking the 10s expired, but the business performed 30s (likely to encounter fullgc, the cycle of death and other scenes).
Failure to use the time to renew the lock time problem
Acquiring business to lock the thread, you can turn a child thread in rotation and to maintain the effective time of the lock, the lock and the timing of these were renewals.
Business thread gets to assume a lock, the lock Expire time is 10s, the business will open a thread child thread lock to be put in rotation by way of renewal every two seconds, each time the lock Expire to restore 10s .
Problems
- Business infinite loop
- Business fullgc
These problems can lead to renew the thread can not be performed, resulting in premature failure of the lock.