怎么查找网站死链,指数函数和对数函数,建设机械网站公司,平面设计培训机构价位分布式锁概念 在多线程环境下#xff0c;为了保证数据的线程安全#xff0c;锁保证同一时刻#xff0c;只有一个可以访问和更新共享数据。在单机系统我们可以使用 synchronized 锁、Lock 锁保证线程安全。 synchronized 锁是 Java 提供的一种内置锁#xff0c;在单个 JVM … 分布式锁概念 在多线程环境下为了保证数据的线程安全锁保证同一时刻只有一个可以访问和更新共享数据。在单机系统我们可以使用 synchronized 锁、Lock 锁保证线程安全。 synchronized 锁是 Java 提供的一种内置锁在单个 JVM 进程中提供线程之间的锁定机制控制多线程并发。只适用于单机环境下的并发控制。 想要在多个节点中提供锁定在分布式系统并发控制共享资源确保同一时刻只有一个访问可以调用避免多个调用者竞争调用和数据不一致问题保证数据的一致性就需要分布式锁。 分布式锁控制分布式系统不同进程访问共享资源的一种锁的机制。不同进程之间调用需要保持互斥性任意时刻只有一个客户端能持有锁。 共享资源包含 数据库 文件硬盘 共享内存 分布式锁特性 互斥性锁只能被持有的客户端删除不能被其他客户端删除 锁超时释放持有锁超时可以释放防止不必要的资源浪费也可以防止死锁 可重入性一个线程如果获取了锁之后,可以再次对其请求加锁。 高性能和高可用加锁和解锁需要开销尽可能低同时也要保证高可用避免分布式锁失效 安全性锁只能被持有的客户端删除不能被其他客户端删除 创建锁 使用Redis实现分布式锁可以通过setnxset if not exists命令实现但当我们使用setnx创建键值成功时则表中加锁成功否则代码加锁失败实现示例如下 127.0.0.1:6379 setnx lock true (integer) 1#创建锁成功 #逻辑业务处理.. 当我们重复加锁时只有第一次会加锁成功 127.8..1:6379 setnx lock true # 第一次加锁 (integer) 1 127.8.8.1:6379 setnx lock true # 第二次加锁 (integer) 0 从上述命令可以看出我们可以看执行结果返回是不是1就可以看出是否加锁成功 释放分布式锁  127.0.0.1:6379 de1 lock (integer) 1 #释放锁 然而如果使用 setnx ock true 实现分布式锁会存在死锁问题以为 setnx 如未设置过期时间锁忘记删了或加锁线程宕机都会导致死锁也就是分布式锁一直被占用的情况 解决死锁问题 死锁问题可以通过设置超时时间来解决如果超过了超时时间分布锁会自动释放这样就不会存在死锁问题了也就是 setnx和 expire 配合使用在 Redis 2.6.12 版本之后新增了一个强大的功能我们可以使用一个原子操作也就是一条命令来执行 setnx 和expire 操作了实现示例如下:   127.0.0.1:6379 set lock true ex 3 nx OK #创建锁成功 127...1:6379 set lock true ex 3 nx (ni1) #在锁被占用的时候企图获取锁失败 其中ex为设置超时时间 nx 为元素非空判断用来判断是否能正常使用锁的。 因此我们在 Redis 中实现分布式锁最直接的方案就是使用 set key value ex timeout nx 的方式来实现 超卖问题 这是因为在并发环境下多个线程下单操作前面的线程还未更新库存后面的线程已经请求进来并获取到了未更新的库存后续扣减库存都不是扣减最近的库存。线程越多扣减的库存越少。这就是在高并发场景下发生的超卖问题。 很明显上述问题是出现了线程安全的问题我们首先能想到的肯定是给它加 synchronized 锁。 是的没问题但是我们知道synchronized 锁是属于JVM 级别的也就是我们所谓的“单机锁”如果是多机部署的环境中还能保证数据的一致性吗 答案肯定是不能的。这个时候就需要用到了我们 Redis 分布式锁 用 Redis 实现分布式锁的几种方案都是用 SETNX 命令设置 key 等于某 value。只是高阶方案传的参数个数不一样以及考虑了异常情况 4. Redis分布式锁方案三Redisson 4. Redis分布式锁方案三Redisson 方案二还存在问题「锁过期释放业务没执行完」。 如果设置的超时时间比较短而业务执行的时间比较长。比如超时时间设置5s而业务执行需要10s此时业务还未执行完其他请求就会获取到锁两个请求同时请求业务数据不满足分布式锁的互斥性无法保证线程的安全