分布式锁特点：1)互斥性、2)可重入锁（避免死锁，加过期时间/版本号）；3)获取/释放锁性能好；4)最好阻塞锁（根据业务需求考虑要不要）5)容错性：只要大部分节点存活，Client 就可加/解锁。高可用、持久化
1、数据库锁：简单、增加数据库负担。
2、redis：性能高，实现方便。缺点：不是十分可靠，超时锁失效。
3、zk锁：1)可靠性高，不依靠超时时间释放；缺点：1)如中间长作业严重阻塞，2)性能比不上redis，要过半写，频繁创建、删除节点。但redis异步复制，故障转移可能丢数据，如用红锁，性能下降许，故障转移策略还要调整，不如直接上zk
性能要求不高场景(如MQ消费)，用zk安全。
复杂性（从低到高）: Zookeeper >= redis > 数据库
性能（从高到低）: redis > Zookeeper >= 数据库
可靠性（从高到低）: Zookeeper > redis > 数据库
一、数据库锁
1.1基于数据库表
创建锁表，要锁住某个方法或资源，就表中增加记录，删除这条记录释放锁。
锁住：insert into methodLock(method_name,desc) values (‘method_name’,‘desc’) 对method_name做唯一性约束，多个请求只有一个成功
释放锁：delete from methodLock where method_name ='method_name'
问题：
1、依赖db，db是单点挂掉，导致业务系统不可用。
2、锁没有失效时间，失败一直在数据库，其他线程无法再获得到锁。
3、只能非阻塞，insert失败直接报错。没获得锁线程不会进排队队列，再次获得锁，就再次触发获得锁操作。
4、非重入，同一个线程在没释放锁前，无法再次获得该锁。因为数据中数据已存在。
解决：
1.两个数据库，双向同步
2.定时任务，超时数据清理。
3.搞while循环，直到insert成功再返回成功。
4.非重入？表中加个字段，记录当前获得锁的机器的主机信息和线程信息，那么下次再获取锁的时候先查询数据库，如果当前机器的主机信息和线程信息在数据库可以查到的话，直接把锁分配给他就可以了。
1.2基于数据库的排它锁
数据库自带的锁：查询后加for update，给表增加排他锁。某条记录加上排他锁后，无法再增加排他锁。
public void unlock(){
connection.commit(); //释放锁。解决上面问题:
}
(1)无法释放锁(服务宕机数据库自己释放)
(2)阻塞锁(for update成功后立即返回，失败一直阻塞状态，直到成功)
二、基于redis的分布式锁
性能好。可集群部署，同时满足四个条件,确保分布式锁可用：
1.互斥性。
2.不会死锁(即使崩溃没主动解锁，其他能加锁)。
3.容错性。大部分Redis节点正常运行，可加、解锁。
4.加锁和解锁必须是同一个客户端。
加锁：jedis.set(String key, String value, String nxxx, String expx, int time)，五个形参：2，3，4，5保证可靠性
(1)key，当锁，唯一。
(2)requestId，解铃还须系铃人，用UUID.randomUUID().toString()生成。
(3)NX，SET IF NOT EXIST，key不存在set；已经存在不做任何操作；
(4)PX，key过期设置
(5)key，过期时间
错误实例：jedis.setnx()和jedis.expire()组合实现加锁
expire()方法就是给锁加过期时间。两条Redis命令，不具有原子性，setnx()后崩溃，没有设过期时间。死锁。
