我要评论核心原理
利用redis单线程执行命令、原子性，多个客户端抢占同一个key，抢到key代表获取锁；释放key代表释放锁，以此实现多进程/多机器互斥访问共享资源。
1. 获取锁
错误写法
set lock 1 expire lock 30
两条命令非原子，如果执行完set之后服务宕机，没有设置过期时间，锁会永久死锁。
正确命令（原子操作）
set lock_key unique_value nx ex 30
nx：key不存在才设置，保证互斥；ex 30：锁自动过期时间，防止宕机死锁；unique_value：客户端生成唯一标识（uuid/线程id），用来区分锁是谁加的，不能随便释放别人的锁。
2. 释放锁
重点：不能直接del lock_key，会把别的线程持有的锁删掉。
错误：直接del
如果业务执行慢，锁过期自动释放，别的线程拿到锁，此时当前线程执行del，直接删掉别人的锁。
正确：lua脚本原子释放
-- 判断是自己加的锁，才删除
if redis.call('get',keys[1]) == argv[1] then
return redis.call('del',keys[1])
else
return 0
endlua脚本保证判断+删除是一条原子操作。
3. 锁续期（看门狗机制 watchdog）
- 场景：业务还没执行完，锁快过期了，锁被自动释放，出现并发问题。
- 实现：客户端开启后台线程，检测锁快要过期，如果线程还持有锁，自动延长过期时间。
- redisson已经封装好看门狗，不需要自己手写。
4. 单机redis分布式锁存在的问题
- 主从异步复制问题：客户端在master拿到锁，锁还没同步到slave，master宕机，slave升级为主，锁丢失，出现锁失效。
- 解决方案：redlock红锁，需要多台独立redis节点，半数以上节点加锁成功才算拿到锁；运维成本高，实际线上很少用。
- 工业更常用：zookeeper分布式锁 / 数据库乐观锁做兜底。
5. 实际开发建议
尽量直接使用redisson，不要手写redis分布式锁。
redisson已经封装：
- 原子加锁释放
- 看门狗自动续期
- 可重入锁
- 锁等待、重试机制
总结
- 加锁用
set key value nx ex原子命令，设置唯一value； - 释放锁必须lua脚本校验归属，不能直接del；
- 业务超时要看门狗续期，避免锁提前过期；
- 单机主从切换会丢锁，redlock理论解决，工程优先用redisson。
追问记忆点：原子加锁、唯一标识、lua释放、看门狗续期、主从丢失锁风险。
到此这篇关于redis 中实现分布式锁的文章就介绍到这了,更多相关redis 分布式锁内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！
发表评论