微服务-分布式锁方案选型

Redis分布式锁实现的缺点：

    1 锁删除失败 过期时间不好控制

        1.1 释放锁之前宕机，suo 不能释放

        1.2 增加过期时间，客户端未宕机(GC或业务处理超时) 被释放，导致两个进程后去锁

    2非阻塞，操作失败后，需要轮询，占用cpu资源;

3、Redis非强一致性Zab协议，主从异步复制如果宕机，切换从服务器导致部分锁数据丢失，导致多个进程获取同一把锁

ZK分布式锁实现的缺点：

1、性能问题：性能不如redis实现，主要原因是写操作（获取锁释放锁）都需要在Leader上执行，然后同步到follower。高并发下 zk QPS不够

2、如果探测到宕机(实际为网络原因，FullGC等) 为误判，释放掉锁后被另一个进程拿到，导致两个进程拿到同一把锁，产生脑裂

总之，ZooKeeper有较好的性能和可靠性。

综合对比

    从理解的难易程度角度（从低到高）：数据库 > 缓存 > Zookeeper

    （2）从实现的复杂性角度（从低到高）：Zookeeper >= 缓存 > 数据库

    （3）从性能角度（从高到低）：缓存 > Zookeeper >= 数据库

    （4）从可靠性角度（从高到低）：Zookeeper > 缓存 > 数据库

用MySQL锁与Redis相同

使用RedLock问题

实际业务避免分布式锁，串行化，弱一致性等策略

若需要，对问题有补偿策略，保证最终一致性