标签：解答 ref 一致性服务 shu 网上 功能 lua 时间轮 另一个
1. 悲观锁
利用select … where … for update 排他锁
注意: 其他附加功能与实现一基本一致，这里需要注意的是“where name=lock ”，name字段必须要走索引，否则会锁表。有些情况下，比如表不大，mysql优化器会不走这个索引，导致锁表问题。
2. 乐观锁
所谓乐观锁与前边最大区别在于基于CAS思想，是不具有互斥性，不会产生锁等待而消耗资源，操作过程中认为不存在并发冲突，只有update version失败后才能觉察到。我们的抢购、秒杀就是用了这种实现以防止超卖。
通过增加递增的版本号字段实现乐观锁
这个分布式锁有 3 个重要的考量点：
set key value ex 5 nx ZooKeeper是一个为分布式应用提供一致性服务的开源组件，它内部是一个分层的文件系统目录树结构，规定同一个目录下只能有一个唯一文件名。基于ZooKeeper实现分布式锁的步骤如下：
（1）创建一个目录mylock；
（2）线程A想获取锁就在mylock目录下创建临时顺序节点；
（3）获取mylock目录下所有的子节点，然后获取比自己小的兄弟节点，如果不存在，则说明当前线程顺序号最小，获得锁；
（4）线程B获取所有节点，判断自己不是最小节点，设置监听比自己次小的节点；
（5）线程A处理完，删除自己的节点，线程B监听到变更事件，判断自己是不是最小的节点，如果是则获得锁。
这里推荐一个Apache的开源库Curator，它是一个ZooKeeper客户端，Curator提供的InterProcessMutex是分布式锁的实现，acquire方法用于获取锁，release方法用于释放锁。
优点：具备高可用、可重入、阻塞锁特性，可解决失效死锁问题。
缺点：因为需要频繁的创建和删除节点，性能上不如Redis方式。
优点：直接使用数据库，实现方式简单。
缺点：
优点：不需要引入中间件，架构简单
缺点：编写一个可靠、高可用、高效率的分布式锁服务，难度较大
1. redis set px nx + 唯一id + lua脚本
优点：redis本身的读写性能很高，因此基于redis的分布式锁效率比较高
缺点：依赖中间件，分布式环境下可能会有节点数据同步问题，可靠性有一定的影响，如果发生则需要人工介入
2. 基于redis的redlock
优点：可以解决redis集群的同步可用性问题
缺点：
优点：不存在redis的超时、数据同步（zookeeper是同步完以后才返回）、主从切换（zookeeper主从切换的过程中服务是不可用的）的问题，可靠性很高
缺点：依赖中间件，保证了可靠性的同时牺牲了一部分效率（但是依然很高）。性能不如redis。
jdk的方式不太推荐。
标签：解答 ref 一致性服务 shu 网上 功能 lua 时间轮 另一个
原文地址：https://www.cnblogs.com/owenma/p/12355262.html
