基于redis的分布式锁跟基于zk的分布式锁该怎么选？
分布式锁在日常开发过程中用的还是比较多的，尤其是分布式环境下，只要涉及到了资源的争抢，不管是不是高并发都得上分布式锁。因为要保证数据的安全，要保证不能超卖，保证数据的一致性等等，这些场景处处离不开分布式锁。
常见的分布式锁很多，比如像redis分布式锁，还有ZK分布式锁，还有基于数据版本号version number的乐观锁等等。对于应用层面的并发控制，要么会选择redis锁，要么就选择ZK锁，zookeeper锁基本上就是两个老演员。
它们之间有什么区别？
·从常规的技术选型来看，一般会选择redis分布式锁，因为它简单，实践起来也比较容易，基本上一个SETNX命令就可以搞定，而且不需要集成，只要不是太low的系统基本上都会有redis。从这点来看，redis确实是用的最广泛的分布式锁，对于ZK来说可能就稍微麻烦一点了。
·从学习的成本上来看，它的API概念相对来说比较复杂，可能需要投入更多的精力来学习。
·从性能上来看更就更不用说了，redis是基于内存的访问，它的读写性能相对来说比较高。ZK就不一样了，因为它需要去做持久化，要持久化到磁盘上面，所以相对来说性能就会稍微差一点，系统开销可能就会更大一点。
基于ZK的分布式锁的核心的卖点就是它的可靠性和数据一致性方面的管控。即使部分的节点的宕机，只要剩余节点数超过了半数，那么服务仍然可以正常运行。而且ZK的临时节点特性可以在客户端、会话结束时或者发生故障时就自动删除了，避免了锁问题。这一点上如果用的是redis锁，只能等待key的超时才能够释放锁，所以可靠性方面ZK是各胜一筹的。
redis锁的不可靠的点主要是在它的集群模式下面，数据分布在多个节点上面，每一个节点都有可能有自己的锁状态和数据副本。这可能会导致在并发情况下，不同的客户端从不同的节点获取锁的状态时有可能不一致的情况发生，因为数据同步可能会出现延迟，这个应该大家都能理解。
所以这种极端的场景下，如果出现了一个客户端在一个节点上成功获取了锁，但是其他节点上面该锁可能仍然会被认为是可用的，就会发生了数据一致性的问题。
所以综合起来来看，如果应用的场景对于一些一致性、可靠性要求比较高，就可以选用ZK分布式锁。如果其他的场景，就可以无脑的选择redis锁就行了。目前一般是选用redisson，基本上一些看门狗Watch dog都帮你做了，就不用再重复造轮子了。
本期的视频就是这了，如果对本期内容有何疑问，欢迎来到本期区给我留言，谢谢大家。