（重点）锁：分布式锁、数据库锁

一、分布式锁

1、分布式锁应该是怎样的：

（1）互斥性：分布式部署的应用集群中，一个方法只能被一台机器上 的一个线程执行

（2）这把锁要是可重入的，避免死锁

（3）有高可用的获取锁和释放锁功能，性能要好

2、分布式锁的三种方式：

（1）基于数据库实现分布式锁

   悲观锁：实现方式是独占数据，其他线程等待，不会出现修改冲突，对于数据敏感且读取频率低的场景用

　　　　　利用select ...where ...for update排他锁

　　　　　注意：where name = lock,name字段必须要走索引，否则会锁表。有些情况下如表不大，MySQL优化器会不走这个索引，导致锁表问题

   乐观锁：通过增加递增的版本号字段实现。

　　　　　乐观锁认为数据一般不冲突，只有在提交更新时才会检测冲突，适用于读取频率高而修改少的场景

　　　　　乐观锁与前边最大的区别在于基于CAS思想，是不具有互斥性，不会产生锁等待而消耗资源，操作过程中认为不存在并发冲突，只有update version失败后才能察觉到。抢购、秒杀就是用了这种实现来防止超卖。

（2）基于缓存（redis等）实现分布式锁

　　在使用redis实现分布式锁时，主要会使用到以下三个命令：

　　　　SETNX: SETNX key Val:当且仅当key不存在时，set一个key为Val的字符串，返回1，若key存在则什么都不做返回0；

　　　　expire: expire key timeout:为key设置一个超时时间，单位second，超过这个时间锁就会自动释放，避免死锁。

　　　　delete：delete key删除key

　　实现思想：

　　　　获取锁的时候，使用SETNX加锁，并使用expire命令为锁添加一个超时时间，超过该时间就自动释放锁，锁的value值为一个随机生成的UUID，通过此在释放锁的时候进行判断；

　　　　获取锁的时候还设置一个获取的超时时间，若超过这个时间就放弃获取锁；

　　　　释放锁的时候通过UUID判断是不是该锁，若是，则执行delete进行释放锁。

（3）基于zookeeper实现分布式锁

　　主体描述：客户端对某个方法加锁是，在zk上与该方法对应的指定节点的目录下生成唯一的瞬时有序节点，判断是否获取锁只需要判断有序节点中序号最小的一个，释放锁时删除瞬时节点

　　zookeeper是一个为分布式应用提供一致性服务的开源组件，内部是一个分层的文件系统目录树结构，规定同一个目录下只能有一个唯一文件名

　　zookeeper实现分布式锁的步骤如下：

　　　　1-创建一个目录mylock

　　　　2-线程A项获取锁，就在mylock目录下创建临时顺序节点

　　　　3-获取mylock目录下所有子节点，然后获取比自己小的兄弟节点，如果不存在，则说明当前线程顺序号最小，获得锁

　　　　4-线程B获取所有节点，判断自己不是最小节点，设置监听比自己小的节点

　　　　5-线程A处理完，删除自己的节点，线程B监听到变更事件，判断自己是不是最小的节点，如果是则获得锁；

　　推荐：Apache的开源库Curator,是一个zookeeper客户端，curator提供的interProcessMutex是分布式锁的实现，Acquire方法用户获取锁，release方法用于释放锁。

3、以上三种分布式锁实现的对比：

数据库分布式锁实现的缺点：（1）db操作性能较差，并且有锁表的风险；（2）非阻塞，操作失败后，需要轮询，占用cpu资源；（3）长时间不commit或者长时间轮询可能会占用较多的连接资源

redis缓存分布式锁实现的缺点：（1）锁删除失败 过期时间不好控制；（2）非阻塞，操作失败后需要轮询，占用CPU资源

zookeeper分布式锁实现的缺点：性能不如redis实现，主要原因是写操作（获取锁释放锁）都需要在leader上执行，然后同步到follower

二、数据库锁级别

1、行级锁：特点与表锁刚好相反

Record locks 记录锁，对索引项加锁

Gap lock 间隙锁，锁定一个范围，不包含记录本身：select c1 from t1 where c1 between 10 and 20 for update

Next-key 锁是记录锁+间隙锁，锁定一个范围且锁定记录本身

2、表级锁：锁整张表，开销小，加锁快，不会出现死锁，锁粒度大，发生锁冲突概率最高

3、三级封锁协议

一级：修改数据加x排他锁直到事务结束才释放

二级：在一级基础上，事务读数据之前先加s锁，读完释放s锁（防止丢失修改且防止读'脏'数据），不能保证可重复读

三级：在二级基础上，事务读数据前加s锁，直到事务结束才释放锁，解决可重复读问题；