(3)三种分布式锁对比

分布式锁特点：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()后崩溃，没有设过期时间。死锁。