分布式锁【数据库乐观锁实现的分布式锁、Zookeeper分布式锁原理、Redis实现的分布式锁】(三)-全面详解（学习总结---从入门到深化）（上）：https://developer.aliyun.com/article/1420037
分布式锁解决方案_Zookeeper分布式锁原理
公平锁和可重入锁的原理
这种排队取水模型，就是一种锁的模型。
什么是可重入锁呢？
创建临时顺序节点
[zk: localhost:2181(CONNECTED) 1] create -e -s /test 123
ZK分布式锁的实现原理
当第一个客户端请求过来时，Zookeeper 客户端会创建一个持久节 点 locks。如果它（Client1）想获得锁，需要在 locks 节点下创建 一个顺序节点 lock1。
接着，客户端 Client1 会查找 locks 下面的所有临时顺序子节点，判 断自己的节点 lock1 是不是排序最小的那一个，如果是，则成功获得锁。
这时候如果又来一个客户端 client2 前来尝试获得锁，它会在 locks 下再创建一个临时节点 lock2。
客户端 client2 一样也会查找 locks 下面的所有临时顺序子节点，判 断自己的节点 lock2 是不是最小的，此时，发现 lock1 才是最小 的，于是获取锁失败。获取锁失败，它是不会甘心的，client2 向它 排序靠前的节点 lock1 注册 Watcher 事件，用来监听 lock1 是否存 在，也就是说 client2 抢锁失败进入等待状态。
此时，如果再来一个客户端Client3来尝试获取锁，它会在 locks 下 再创建一个临时节点 lock3。
同样的，client3 一样也会查找 locks 下面的所有临时顺序子节点， 判断自己的节点 lock3 是不是最小的，发现自己不是最小的，就获 取锁失败。它也是不会甘心的，它会向在它前面的节点 lock2 注册 Watcher 事件，以监听 lock2 节点是否存在。
释放锁
如果是任务完成，Client1 会显式调用删除 lock1 的指令。
如果是客户端故障了，根据临时节点得特性，lock1 是会自动删除的。
lock1 节点被删除后，Client2 可开心了，因为它一直监听着 lock1。lock1 节点删除，Client2 立刻收到通知，也会查找 locks 下面的所有临时顺序子节点，发下 lock2 是最小，就获得锁。
同理，Client2 获得锁之后，Client3 也对它虎视眈眈：
分布式锁解决方案_基于Zookeeper实现分布式锁
简介
Apache Curator是一个比较完善的ZooKeeper客户端框架，通过封 装的一套高级API 简化了ZooKeeper的操作。
引入Curator依赖
<dependency> <groupId>org.apache.curator</groupId> <artifactId>curator-framework</artifactId> <version>5.2.0</version> </dependency> <dependency> <groupId>org.apache.curator</groupId> <artifactId>curator-recipes</artifactId> <version>5.2.0</version> </dependency> <dependency> <groupId>org.apache.curator</groupId> <artifactId>curator-client</artifactId> <version>5.2.0</version> </dependency>
编写Zookeeper配置
@Configuration public class ZookeeperConfig { @Bean public CuratorFramework zookeeperClient() { CuratorFramework client = CuratorFrameworkFactory.builder() .connectString("127.0.0.1:2181") .sessionTimeoutMs(5000) .connectionTimeoutMs(5000) .retryPolicy(new ExponentialBackoffRetry(1000, 3)) //.namespace("test") .build(); client.start(); return client; } }
编写创建订单接口实现
使用InterProcessMutex的acquire和release方法，来获取和释放锁。
@Autowired CuratorFramework client; @Override public String createOrderZookeeper(Integer productId, Integer count) throws Exception { // client cruator中zk客户端对象 path 抢锁路径同一个锁path需要一致 InterProcessMutex lock = new InterProcessMutex(client, "/lockPath"); //第一个属性:定时的时间数字 //第二个属性:定义时间的单位 if (lock.acquire(3, TimeUnit.SECONDS)) { try { // 1、根据商品id查询商品信息 Product product = productMapper.selectById(productId); // 2、判断商品是否存在 if (product == null) { throw new RuntimeException("购买商品不存在:" + productId + "不存在"); } // 3、校验库存 if (count > product.getCount()) { throw new RuntimeException("商品" + productId + "仅剩" + product.getCount() + "件,无法购买"); } // 4、计算库存 Integer leftCount = product.getCount() - count; // 5、更新库存 product.setCount(leftCount); productMapper.updateById(product); // 6、 创建订单 TOrder order = new TOrder(); order.setOrderStatus(1);//待处理 order.setReceiverName("张三"); order.setReceiverMobile("18587781068"); order.setOrderAmount(product.getPrice().multiply(new BigDecimal(count)));//订单价格 baseMapper.insert(order); // 7、 创建订单和商品关系数据 OrderItem orderItem = new OrderItem(); orderItem.setOrderId(order.getId()); orderItem.setProduceId(product.getId()); orderItem.setPurchasePrice(product.getPrice()); orderItem.setPurchaseNum(count); orderItemMapper.insert(orderItem); return order.getId(); } finally { lock.release(); } } return "创建失败"; }
三种分布式锁对比
数据库分布式锁实现
优点：简单，使用方便，不需要引入 Redis、Zookeeper 等中间件。
缺点：1、不适合高并发的场景 2、db 操作性能较差
Redis 分布式锁实现
优点：1、性能好，适合高并发场景 2、较轻量级 3、有较好的框架支持，如 Redisson
缺点：1、过期时间不好控制 2、需要考虑锁被别的线程误删场景
Zookeeper 分布式锁实现
优点：1、有较好的性能和可靠性 2、有封装较好的框架，如 Curator
缺点：1、性能不如 Redis 实现的分布式锁 2、比较重的分布式锁。
汇总对比
1、从性能角度：Redis > Zookeeper >= 数据库
2、从实现的复杂性角度：Zookeeper > Redis > 数据库
3、从可靠性角度：Zookeeper > Redis > 数据库
