分布式锁（redis锁和zk锁）

锁：
synchronized
    在单JVM环境下没问题，在分布式环境下有问题
使用redis加锁可能出现的问题：

1）业务代码报错导致的redis锁没有释放
    解决方案：把释放锁的代码放到finally中执行
2）业务工程宕机导致redis锁没有释放
    解决方案：增加超时时间。超时时间要使用redis自带的超时时间的方法，如果单独设置了锁后再设置超时时间，有可能这中间宕机导致锁释放不了
3）业务执行时间超出锁的超时时间，导致锁失效问题（锁超时设置10秒，A线程进入方法，业务需要15秒，执行到11秒的时候锁已经失效了，此时B线程执行后加了锁，A执行结束时把B的锁释放了）
    解决方案：给每个线程设置一个参数，放到缓存中，释放锁时判断，只能释放当前线程的锁。
4）锁的超时时间设置大小问题，设置的太小解决不了问题，设置的太大，万一出现宕机，会阻塞很长时间
    解决方案1：单独起一个子线程，给线程中的锁刷新时间
    解决方案2：使用redission。redission就是基于方案一实现的。增加锁后，注册一个监听，当进行到超时时间三分之一时刷新超时时间。所有加同一个锁的线程获取不到就自旋，直到获取到锁。
5）redission由于是加锁串行，所以会使高可用变得有性能问题。
    解决方案：分段锁，可以把要执行的锁分成多个key，也可以分到不同的redis上。
6）redission如果使用的是主从，还可能有问题。因为redis master加锁成功后就给客户端返回成功标识了，而不是等到同步完slave再发。如果slave还没同步完成，此时maste宕机了，就会有问题。如果要保证完全一致性，可以使用zookeeper锁，CP，能够保证绝对一致，但是性能没有redis高。

redis 锁和 zookeeper锁的区别：
    CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾
    
    redis AP    
    zookeeper  CP 
    master加锁成功后就给客户端返回成功标识了，而不是等到同步完slave再发。如果slave还没同步完成，此时maste宕机了，就会有问题。如果要保证完全一致性，可以使用zookeeper锁，CP，能够保证绝对一致，但是性能没有redis高。
    zookeeper是master节点加锁后，把状态也同步到了另外的节点成功后才给客户端返回成功标识。