First, based on a distributed lock design redis
1, implementation: setnx key value expire time
2, there is a problem:
a, single-instance: high availability can not meet the
b, master-slave: the main lock has not been synchronized to the slave, the master goes down, there is no lock, the lock will repeat problem
3, the official suggested: using redlock algorithm to ensure, using the most successful lock considered successful, at least three main redis be realized from an instance, the higher the cost.
The essential problem: Distributed Lock requires CP model, redis cluster is the AP model!
Second, distributed lock requirement
1, strong consistency
2, service availability
3, downtime can automatically lock release can be renewed
4, visual management, monitoring
Third, the program distributed lock contrast
| repeat | zookeeper | etcd | |
| Consensus algorithm | no | paxos | raft |
| CAP | Of | CP | Cf / off |
| High Availability | Master-slave | Ultra-half for Allowed | Ultra-half for Allowed |
| Interface Type | Client | Client | http/grpc |
| achieve | setnx | createEphemeral temporary node | restful API |
1, redis can not guarantee data consistency
2, zookeeper to achieve lock using: Create a temporary nodes and watch mechanisms, efficiency, scalability, community activists lower than etcd
3, the proposed option to achieve etcd