一、基于redis分布式锁设计
1、实现方式：setnx key value expire time
2、存在问题：
a、单实例：高可用不能满足
b、主从：主加锁后，尚未同步到从，主宕机，锁不存在，会出现重复加锁问题
3、官方建议：使用redlock算法来保证，利用多数成功才算加锁成功，需要至少三个redis主从实例来实现，成本较高。
问题本质：分布式锁要求CP模型，redis集群是AP模型！
二、分布式锁要求
1、强一致性
2、服务高可用
3、宕机锁能自动释放，能够续约
4、可视化管理、监控
三、分布式锁方案对比
| redis | zookeeper | etcd | |
| 一致性算法 | 无 | paxos | raft |
| CAP | AP | CP | CP/AP |
| 高可用 | 主从 | 超半数可用 | 超半数可用 |
| 接口类型 | 客户端 | 客户端 | http/grpc |
| 实现 | setnx | createEphemeral临时节点 | restful API |
1、redis无法保证数据一致性
2、zookeeper对锁实现采用：创建临时节点和watch机制，执行效率、扩展能力、社区活跃度低于etcd
3、建议选择etcd实现