基于特定条件的事务执行——锁
解决方案
对 key 添加监视锁,在执行exec前如果key发生了变化,终止事务执行
watch key1 [key2......]
取消对所有 key 的监视
unwatch
Tips 18:
redis 应用基于状态控制的批量任务执行
基于特定条件的事务执行——分布式锁
解决方案
使用 setnx 设置一个公共锁
命令: setnx lock-key value 例: set num 123 setnx lock-num 1
利用setnx命令的返回值特征,有值则返回设置失败,无值则返回设置成功
- 对于返回设置成功的,拥有控制权,进行下一步的具体业务操作
- 对于返回设置失败的,不具有控制权,排队或等待
操作完毕通过del操作释放锁
例:
del lock-num
注意: 上述解决方案是一种设计概念,依赖规范保障,具有风险性
Tips 19:
redis 应用基于分布式锁对应的场景控制
业务场景
依赖分布式锁的机制,某个用户操作时对应客户端宕机,且此时已经获取到锁。如何解决?
业务分析
由于锁操作由用户控制加锁解锁,必定会存在加锁后未解锁的风险
需要解锁操作不能仅依赖用户控制,系统级别要给出对应的保底处理方案
基于特定条件的事务执行——分布式锁改良
解决方案
使用 expire 为锁key添加时间限定,到时不释放,放弃锁
命令:
expire lock-key second 秒 pexpire lock-key milliseconds 毫秒
例:
set num 123
setnx lock-num 1
expire lock-num 10/pexpire lock-num 10
由于操作通常都是微秒或毫秒级,因此该锁定时间不宜设置过大。具体时间需要业务测试后确认。
- 例如:持有锁的操作最长执行时间127ms,最短执行时间7ms。
- 测试百万次最长执行时间对应命令的最大耗时,测试百万次网络延迟平均耗时
- 锁时间设定推荐:最大耗时*120%+平均网络延迟*110%
- 如果业务最大耗时<<网络平均延迟,通常为2个数量级,取其中单个耗时较长即可