总结

实现的复杂性或者难度角度：Zookeeper > Redis > 数据库

实际性能角度：Redis > Zookeeper > 数据库

可靠性角度：Zookeeper > Redis = 数据库

这三种方式都不是尽善尽美，我们可以根据实际业务情况选择最适合的方案：

• 如果追求极致性能可以选择：Redis 方案

• 如果追求可靠性可以选择：Zookeeper，但是大多数情况下还是会使用 Redis，因为大部分项目中还是会用到缓存机制，所以会引入 Redis，不太会因为一个分布式锁的实线去多引入一个 Zookeeper。

常见锁分类

悲观锁：具有强烈的独占和排他特性，在整个数据处理过程中，将数据处于锁定状态。适合于写比较多，会阻塞读操作。
乐观锁：采取了更加宽松的加锁机制，大多是基于数据版本（ Version ）及时间戳来实现。。适合于读比较多，不会阻塞读

独占锁、互斥锁、排他锁：保证在任一时刻，只能被一个线程独占排他持有。synchronized、ReentrantLock
共享锁：可同时被多个线程共享持有。CountDownLatch 到计数器、Semaphore 信号量

可重入锁：又名递归锁。同一个线程在外层方法获取锁的时候，在进入内层方法时会自动获取锁。
不可重入锁：例如早期的 synchronized

公平锁：有优先级的锁，先来先得，谁先申请锁就先获取到锁
非公平锁：无优先级的锁，后来者也有机会先获取到锁

自旋锁：当线程尝试获取锁失败时（锁已经被其它线程占用了），无限循环重试尝试获取锁
阻塞锁：当线程尝试获取锁失败时，线程进入阻塞状态，直到接收信号后被唤醒。在竞争激烈情况下，性能较高

读锁：共享锁
写锁：独占排他锁

偏向锁：一直被一个线程所访问，那么该线程会自动获取锁
轻量级锁（CAS）：当锁是偏向锁的时候，被另一个线程所访问，偏向锁就会升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，不会阻塞，提高性能。
重量级锁：当锁为轻量级锁的时候，另一个线程虽然是自旋，但自旋不会一直持续下去，当自旋一定次数的时候（10 次），还没有获取到锁，就会进入阻塞，该锁膨胀为重量级锁。重量级锁会让他申请的线程进入阻塞，性能降低。

以上其实也是 synchronized 的锁升级过程

​

表级锁：对整张表加锁，加锁快开销小，不会出现死锁，但并发度低，会增加锁冲突的概率
行级锁：是 mysql 粒度最小的锁，只针对操作行，可大大减少锁冲突概率，并发度高，但加锁慢，开销大，会出现死锁