1. redis 加锁分类
redis 能用的的加锁命令分表是 INCR,SETNX,SET
2. 第一种锁命令 INCR
这种加锁的思路是, key 不存在, 那么 key 的值会先被初始化为 0 , 然后再执行 INCR 操作进行加一.
然后其它用户在执行 INCR 操作进行加一时, 如果返回的数大于 1 , 说明这个锁正在被使用当中.
1, 客户端 A 请求服务器获取 key 的值为 1 表示获取了锁
2, 客户端 B 也去请求服务器获取 key 的值为 2 表示获取锁失败
3, 客户端 A 执行代码完成, 删除锁
4, 客户端 B 在等待一段时间后在去请求的时候获取 key 的值为 1 表示获取锁成功
5, 客户端 B 执行代码完成, 删除锁
- $redis->incr($key);
- $redis->expire($key, $ttl); // 设置生成时间为 1 秒
3. 第二种锁 SETNX
这种加锁的思路是, 如果 key 不存在, 将 key 设置为 value
如果 key 已存在, 则 SETNX 不做任何动作
1, 客户端 A 请求服务器设置 key 的值, 如果设置成功就表示加锁成功
2, 客户端 B 也去请求服务器设置 key 的值, 如果返回失败, 那么就代表加锁失败
3, 客户端 A 执行代码完成, 删除锁
4, 客户端 B 在等待一段时间后在去请求设置 key 的值, 设置成功
5, 客户端 B 执行代码完成, 删除锁
- $redis->setNX($key, $value);
- $redis->expire($key, $ttl);
4. 第三种锁 SET
上面两种方法都有一个问题, 会发现, 都需要设置 key 过期. 那么为什么要设置 key 过期呢? 如果请求执行因为某些原因意外退出了, 导致创建了锁但是没有删除锁, 那么这个锁将一直存在, 以至于以后缓存再也得不到更新. 于是乎我们需要给锁加一个过期时间以防不测.
但是借助 Expire 来设置就不是原子性操作了. 所以还可以通过事务来确保原子性, 但是还是有些问题, 所以官方就引用了另外一个, 使用 SET 命令本身已经从版本 2.6.12 开始包含了设置过期时间的功能.
1, 客户端 A 请求服务器设置 key 的值, 如果设置成功就表示加锁成功
2, 客户端 B 也去请求服务器设置 key 的值, 如果返回失败, 那么就代表加锁失败
3, 客户端 A 执行代码完成, 删除锁
4, 客户端 B 在等待一段时间后在去请求设置 key 的值, 设置成功
5, 客户端 B 执行代码完成, 删除锁
$redis->set($key, $value, array('nx', 'ex' => $ttl)); //ex 表示秒
5. 其它问题
虽然上面一步已经满足了我们的需求, 但是还是要考虑其它问题?
1, redis 发现锁失败了要怎么办? 中断请求还是循环请求?
2, 循环请求的话, 如果有一个获取了锁, 其它的在去获取锁的时候, 是不是容易发生抢锁的可能?
3, 锁提前过期后, 客户端 A 还没执行完, 然后客户端 B 获取到了锁, 这时候客户端 A 执行完了, 会不会在删锁的时候把 B 的锁给删掉?
6. 解决办法
针对问题 1: 使用循环请求, 循环请求去获取锁
针对问题 2: 针对第二个问题, 在循环请求获取锁的时候, 加入睡眠功能, 等待几毫秒在执行循环
针对问题 3: 在加锁的时候存入的 key 是随机的. 这样的话, 每次在删除 key 的时候判断下存入的 key 里的 value 和自己存的是否一样
- do { // 针对问题 1, 使用循环
- $timeout = 10;
- $roomid = 10001;
- $key = 'room_lock';
- $value = 'room_'.$roomid; // 分配一个随机的值针对问题 3
- $isLock = Redis::set($key, $value, 'ex', $timeout, 'nx');//ex 秒
- if ($isLock) {
- if (Redis::get($key) == $value) { // 防止提前过期, 误删其它请求创建的锁
- // 执行内部代码
- Redis::del($key);
- continue;// 执行成功删除 key 并跳出循环
- }
- } else {
- usleep(5000); // 睡眠, 降低抢锁频率, 缓解 redis 压力, 针对问题 2
- }
- } while(!$isLock);
来源: http://www.bubuko.com/infodetail-2770752.html