在多任务环境下解决并发场景的数据竞争问题
我们可以根据锁是否包含某一特性来进行分组归类
在单机应用的环境下，所有线程运行在同一个jvm进程中，使用Java中自带的锁足以控制并发；但是在分布式场景下，多个线程运行在不同的机器（jvm进程）上，就需要分布式锁来解决问题了
分布式锁是控制分布式系统不同进程并发访问共享资源的一种锁的实现。如果不同主机之间共享了某个临界资源（例如数据库中的数据），往往需要互斥来防止彼此干扰，以保证一致性。
作用：分布式集群中多个服务请求同一方法或者同一个业务操作（比如秒杀）的情况下，对应的业务逻辑只能被一台机器上的一个线程执行，避免出现并发安全问题。
利用select...for update，数据库行锁来实现悲观锁。注意：如果查询条件用了索引/主键，那么select … for update就会进行行锁；如果是普通字段(没有索引/主键)，那么select … for update就会进行锁表。
获取锁方法需要声明事务，加数据行锁，事务结束则释放行锁，释放锁的操作应放在finally中
伪代码如下：
//整体流程
try {
if(lock(keyResource)){//加锁
process();//业务逻辑处理
}
} finally {
unlock(keyResource);//释放
}
//锁方法实现
//获取锁
public boolean lock(String keyResource){
resLock = 'select * from resource_lock where key_resource = '#{keySource}' for update';
if(resLock != null && resLock.getLockFlag == 1){
return false;
}
resLock.setLockFlag(1);//上锁
insertOrUpdate(resLock);//提交
return true;
}
//释放锁
public void unlock(String keyResource){
resourceLock.setLockFlag(0);//解锁
update(resourceLock);//提交
}
基于CAS思想，在数据库表中添加version字段。
使用时，带着条件去更新(判断version)
mybatis-plus已支持自动配置
使用SETNX命令，SETNX 即 SET if Not eXists (对应 Java 中的 setIfAbsent 方法)，如果 key 不存在的话，才会设置 key 的值，返回1。如果 key 已经存在， SETNX 啥也不做，返回0。
expire KEY seconds设置key的过期时间，如果key已过期，将会被自动删除。
del KEY删除key
伪代码如下：
//setnx加锁
if(jedis.setnx(key,lock_value) == 1){
//设定锁过期时间
expire(key,10);
try{
//业务处理
do();
} catch(){
}finally{
//释放锁
jedis.del(key);
}
}
在这个原始方案中，setnx和expire是两个分开的操作而不是原子操作。如果执行完setnx操作后，在执行expire设置过期时间之前进程挂了，那这个锁就无法释放，其他线程也获取不到锁了。
使用redis拓展命令SET key value[EX seconds][PX milliseconds][NX|XX]
其中各个参数的含义如下：
key: 要设置的键名。value: 要设置的值。EX seconds: 可选参数，表示设置键的过期时间（以秒为单位）。PX milliseconds: 可选参数，表示设置键的过期时间（以毫秒为单位）。NX: 可选参数，表示只在键不存在时才设置值。XX: 可选参数，表示只在键已经存在时才设置值。举例如下：
SET username alice
这将设置键名为 “username” 的值为 “alice”。
SET session_token 123456 EX 3600
这将设置键名为 “session_token” 的值为 “123456”，并且该键将在 3600 秒（1 小时）后过期。
SET cache_key data123 PX 5000
这将设置键名为 “cache_key” 的值为 “data123”，并且该键将在 5000 毫秒（5 秒）后过期。
SET order_status pending NX
如果键名 “order_status” 不存在，那么它将被设置为 “pending”。如果键名已经存在，则不进行任何操作。
SET login_attempts 3 XX
如果键名 “login_attempts” 已经存在，它的值将被设置为 “3”。如果键名不存在，则不进行任何操作。
了解完这条命令，我们就可以用它来构建分布式锁了
伪代码如下：
if(jedis.set(key,lock_value,"NX","EX",10s) == 1){
try{
do();
}catch(){
}finally{
jedis.del(key);
}
}
这种操作保证了set和expire的原子性，但是仍有其他问题：
有的同学就要问了，既然锁可以被其他线程误删，那我们给他加一个唯一标识可以吗？总的来说思路上是没有问题的，但是不能简单的在Java中进行处理
如果我们在Java中进行判断，伪代码如下：
//加锁时设置一个随机id来作为标识，如果释放锁时还是这个id即证明释放了自己的锁（实际上是有逻辑错误的）
if(jedis.set(key,randomId,"NX","EX",10s) == 1){
try{
do();
}catch(){
}finally{
//从redis获取randomId，如果是期望值则释放
if(randomId.equals(jedis.get(key))){
jedis.del(key);
}
}
}
看起来好像没什么问题，但是这里又会出现不是原子操作导致的问题：如果在刚判断完randomId是期望值后，锁过期了，第二个线程创建了自己的锁，这时由于第一个线程已经通过了randomId的判断，那么它还是会释放线程二刚刚创建的锁，锁误删的问题仍然存在…
好消息是，我们还有其他解决方案。
在redis 2.6版本后，允许开发者使用Lua编写脚本来传到redis执行，这样做的好处如下：
Redis Eval 命令基本语法如下
EVAL script numkeys key [key ...] arg [arg ...]
#实例 eval 引号中是脚本内容 key的个数 key[...] arg[...]
127.0.0.1:6379> eval "return {KEYS[1],KEYS[2],ARGV[1],ARGV[2]}" 2 username age jack 20
1) "username"
2) "age"
3) "jack"
4) "20"
这时候我们就可以用Lua脚本来保证操作的原子性了
lua脚本：
if redis.call('get',KEYS[1])==ARGV[1] then
return redis.call('del',KEYS[1])
else
return 0
end;
在redis中：
EVAL "if redis.call('get',KEYS[1])==ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end" 1 key value
在Java中：
String key = "key";
String value = "value";
// 定义 Lua 脚本
String luaScript = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
// 执行 Lua 脚本
Object result = jedis.eval(luaScript, 1, key, value);
到这里，我们就可以解决锁误删的情况了，但是还有另外的一个问题没有解决，锁过期释放了但是业务还没有执行完怎么办？
Redisson和Jedis类似，是Java操作Redis的客户端，他在解决分布式场景问题比Jedis更加好用，提供了各种分布式对象、分布式锁、分布式同步器、分布式服务等等
Redission分布式锁的实现流程如下
Redisson实现自动续约的实现思路即源码如下：
private void renewExpiration() {
// 获取当前锁的过期时间续约条目
RedissonBaseLock.ExpirationEntry ee = (RedissonBaseLock.ExpirationEntry) EXPIRATION_RENEWAL_MAP.get(this.getEntryName());
// 如果存在续约条目
if (ee != null) {
// 创建定时任务，定时执行续约操作
Timeout task = this.commandExecutor.getConnectionManager().newTimeout(new TimerTask() {
public void run(Timeout timeout) throws Exception {
// 获取续约条目
RedissonBaseLock.ExpirationEntry ent = (RedissonBaseLock.ExpirationEntry) EXPIRATION_RENEWAL_MAP.get(RedissonBaseLock.this.getEntryName());
// 如果续约条目存在
if (ent != null) {
Long threadId = ent.getFirstThreadId();
// 如果存在线程ID
if (threadId != null) {
// 异步执行续约操作
CompletionStage<Boolean> future = RedissonBaseLock.this.renewExpirationAsync(threadId);
// 当异步操作完成时
future.whenComplete((res, e) -> {
if (e != null) {
// 发生错误时，记录日志并移除续约条目
RedissonBaseLock.log.error("Can't update lock " + RedissonBaseLock.this.getRawName() + " expiration", e);
RedissonBaseLock.EXPIRATION_RENEWAL_MAP.remove(RedissonBaseLock.this.getEntryName());
} else {
// 如果续约成功，递归调用续约操作
if (res) {
RedissonBaseLock.this.renewExpiration();
} else {
// 如果无法续约，取消续约操作
RedissonBaseLock.this.cancelExpirationRenewal((Long)null);
}
}
});
}
}
}
}, this.internalLockLeaseTime / 3L, TimeUnit.MILLISECONDS);
// 设置定时任务到续约条目
ee.setTimeout(task);
}
}
protected CompletionStage<Boolean> renewExpirationAsync(long threadId) {
// 使用 evalWriteAsync 方法执行 Lua 脚本
// 这个脚本会检查锁是否仍然由给定的线程持有，如果是则更新锁的过期时间
return this.evalWriteAsync(
this.getRawName(), // 锁的键名
LongCodec.INSTANCE, // 键的编码器
RedisCommands.EVAL_BOOLEAN, // 使用 EVAL 命令并返回布尔值
"if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then redis.call('pexpire', KEYS[1], ARGV[1]); return 1; end; return 0;",
Collections.singletonList(this.getRawName()), // 键名作为 KEYS[1]
this.internalLockLeaseTime, // 锁的过期时间（毫秒）
this.getLockName(threadId) // 获取锁的名称，用于验证锁的持有者
);
}
总结：
Redisson的RLock接口继承了JUC的lock接口，所以他是符合Java中的Lock接口规范的，同时Redisson还提供了多种分布式锁的实现类（例如：RedissonFairLock、RedissonRedLock等）可供大家选择
在部署redis时，为了避免单点问题，我们通常会采用集群方式部署，由于redis集群的数据同步是异步操作，在主节点加锁后就会返回加锁成功；如果一个线程在master节点上拿到了锁，但是加锁的key还没同步到slave节点时master节点就发生了故障，一个slave节点就会升级成master节点，其他线程就也可以获取同个key的锁，又一次相当于没加锁
redis的作者提出了一种高级的分布式锁算法：Redlock，来解决这个问题
Redlock核心思想
搞多个Redis master部署，以保证它们不会同时宕掉。并且这些master节点是完全相互独立的，相互之间不存在数据同步。同时，需要确保在这多个master实例上，是在与Redis单实例使用相同方法来获取和释放锁。
Redlock流程步骤
1、按顺序向多个master节点（如上图5个）请求加锁
2、根据设置的超时时间来判断，是不是要跳过该master节点；
3、如果有半数以上节点加锁成功(右图3个成功即可)，并且使用的时间小于锁的有效期（设置单个节点超时时间），即可认定加锁成功；
4、如果获取锁失败，给所有的master节点解锁
这个之前已经写过博客辣，大家直接点击链接跳转即可~
基于ZooKeeper临时顺序节点的分布式锁实现_❀always❀的博客-CSDN博客
实现思路如下：
| 方案 | 思路 | 优点 | 缺点 | 典型场景 |
|---|---|---|---|---|
| mysql | 悲观锁、乐观锁 | 实现简单、稳定可靠 | 性能差，不适合高并发 | 分布式定时任务 |
| redis | 基于SETNX和Lua脚本保证缓存操作原子化 | 性能好（AP） | 实现相对复杂，不是100%可靠 | 秒杀、抢购、大型抽奖 |
| zookeeper | 基于ZK的节点特性和Watcher机制 | 可靠性高（CP） | 实现相对复杂，性能略差 | 秒杀、抢购、大型抽奖 |
从设计角度来看，分布式锁和高并发本身是矛盾的：分布式锁实际是将并行代码串行化来解决并发问题，对性能是有影响的，但是可以进行优化。
主要方案有：
某事件发生后需要发短信提醒用户，且两小时之内多次发生该事件只在第一次提醒用户
实现思路：在每次发短信之前先获取分布式锁，设定过期时间为2h，若2h内事件再次发生则无法获取到相同的分布式锁，自动跳过发送短信的流程即可
保证某表中以 id+当日时间 为唯一标识的数据只有一条
实现思路：在插入或更新时，先获取到分布式锁，成功插入后解锁
抢购某总量限定的奖品
实现思路：每个线程抢占分布式锁，抢占成功后判断剩余数量是否满足所需数量，若满足，则抢购成功并释放锁