Redis分布式锁实现原理

命令

SET key value [NX] [XX] [EX <seconds>] [PX [millseconds]]

必选参数说明

  • SET:命令
  • key:待设置的key
  • value: 设置的key的value

可选参数说明

  • NX:表示key不存在才设置,如果存在则返回NULL
  • XX:表示key存在时才设置,如果不存在则返回NULL
  • EX seconds:设置过期时间,过期时间精确为秒
  • PX millseconds:设置过期时间,过期时间精确为毫秒

以上set 代替了 setnx + expire 需要分2次执行命令操作的方式,保证了原子性。

原理

setnx大致原理,主要依托了它的key不存在才能set成功的特性,进程A拿到锁,在没有删除锁的Key时,进程B自然获取锁就失败了。

解决死锁

情况1

如果进程A直接挂了,直接原地把锁带走了,导致系统中谁也拿不到锁,这样我们设置的过期时间就派上用场,等待锁过期其他进程就能获取锁。

情况2

进程A的操作时间超过了我们设置锁的过期时间,那么就会导致其他进程拿到锁,等进程A回来了,回手就是把其他进程的锁删了。

所以在用setnx的时候,key虽然是主要作用,但是value也不能闲着,可以设置一个唯一的客户端ID,或者用UUID这种随机数。
当解锁的时候,先获取value判断是否是当前进程加的锁,再去删除。

String uuid = xxxx;
set Test uuid NX PX 3000
try{
// biz handle....
} finally {
    // unlock
    if(uuid.equals(redisTool.get('Test')){
        redisTool.del('Test');
    }}

通过lua脚本能保证原子性的原因说的通俗一点:
就算你在lua里写出花,执行也是一个命令(eval/evalsha)去执行的,一条命令没执行完,其他客户端是看不到的。
那么既然这么麻烦,有没有比较好的工具呢?就要说到redisson了。这个工具咱们有时间再介绍。

暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇