PHP实现Redis分布式锁

 锁在我们的日常开发可谓用得比较多。通常用来解决资源并发的问题。特别是多机集群情况下,资源争抢的问题。但是,很多新手在锁的处理上常常会犯一些问题。今天我们来深入理解锁。

一、Redis 锁错误使用之一
我曾经见过有的项目把查询结果存储到 Redis 当中时的伪代码如下:

$redis    = new \Redis(‘127.0.0.1‘, 6379);

$cacheKey = ‘query_cache‘;

$result   = $redis->get($cacheKey);

if ($result) { // 缓存有效则直接返回。

return $result;

} else { // 缓存失效则重新获取并存储到 Redis。

$mysqlResult = [];

$redis->set($cacheKey, json_encode($mysqlResult), 3600);

return $mysqlResult;

}

初看代码并不会发现问题所在。通常情况下,当服务器资源压力非常小的时候,这段代码不会有任何问题。并且,真的可以提升服务器吞吐性能。

假如,这个位置的代码出现了单点压力呢?比如,这个功能是统计结果,查询数据库需要花 5s。而且,由于该功能比较常用,单位时间内达到了 1000 次/秒。

这时就会出现并发穿透问题。

1000 个请求同时到达这个程序位置,都去读取缓存是否存在。假如此时缓存不存在。这 1000 个请求都会得到不存在的结果。并且都会执行到去数据库取缓存结果的步骤。同时也会把结果重写到 Redis。

那就导致了这一瞬间单点压力导致穿透到数据库,造成数据库压力瞬间到达峰值。如果我们的数据库的性能处理不了这么大的压力,就会导致数据库服务器 CPU 直接爆满。响应给前端的数据就会陷入停顿状态。

所以,这段代码是不正确的锁使用。

二、Redis 锁错误使用之二
在第一点中,我们发现了问题。于是,就有人想着去优化它。于是就有了下面的代码:

$redis    = new \Redis(‘127.0.0.1‘, 6379);

$lockKey  = ‘query_cache_lock‘; // 锁专用的 KEY。

$cacheKey = ‘query_cache‘; // 存储查询结果的 KEY。

$result   = $redis->get($cacheKey);

if ($result) { // 缓存有效则直接返回。

return $result;

} else { // 缓存失效则重新获取并存储到 Redis。

if ($redis->setNx($lockKey) === false) {

throw new \Exception("服务器火爆,请稍候重试");

} else {

$mysqlResult = [];

$redis->set($cacheKey, json_encode($mysqlResult), 3600);

$redis->delete($lockKey); // 锁用完了要解锁。删掉就是解锁。

return $mysqlResult;

}

}

这段代码就完全避免了第一点中的并发穿透的问题。但是,相对第一点,代码也多增加了几行。不过性能依然强劲。

即使如此,这段代码依然存在三个问题:
1)并发越大,第一个取到锁的请求能正常响应,后续的请求就会得到一个“服务器火爆,请稍候重试”的异常提示。
2)没办法对后续请求取锁失效加一个等待时间。
3)如果代码执行到 $redis->delete($lockKey) 之前程序异常了。那么锁就不能正常释放。后续的锁也无法正常取到锁了。

针对第 1) 点,这个是用户体验极差的。
针对第 2) 点,它是解决第一点的方案。
针对第 3) 点,它是我们必须解决的问题。否则,我们的分布式锁将无法正常使用。

三、正确的分布式锁
正常的分布式锁要满足以下几点要求:
1)能解决并发时资源争抢。这是最核心的需求。
2)锁能正常添加与释放。不能出现死锁。
3)锁能实现等待,否则不能最大保证用户的体验。

针对以上三点,得出 Redis 分布式锁示例

class RedisMutexLock

{

/**

* 缓存 Redis 连接。

*

* @return void

*/

public static function getRedis()

{

// 这行代码请根据自己项目替换为自己的获取 Redis 连接。

return YCache::getRedisClient();

}

/**

* 获得锁,如果锁被占用,阻塞,直到获得锁或者超时。

* -- 1、如果 $timeout 参数为 0,则立即返回锁。

* -- 2、建议 timeout 设置为 0,避免 redis 因为阻塞导致性能下降。请根据实际需求进行设置。

*

* @param  string  $key         缓存KEY。

* @param  int     $timeout     取锁超时时间。单位(秒)。等于0,如果当前锁被占用,则立即返回失败。如果大于0,则反复尝试获取锁直到达到该超时时间。

* @param  int     $lockSecond  锁定时间。单位(秒)。

* @param  int     $sleep       取锁间隔时间。单位(微秒)。当锁为占用状态时。每隔多久尝试去取锁。默认 0.1 秒一次取锁。

* @return bool 成功:true、失败:false

*/

public static function lock($key, $timeout = 0, $lockSecond = 20, $sleep = 100000)

{

if (strlen($key) === 0) {

// 项目抛异常方法

YCore::exception(500, ‘缓存KEY没有设置‘);

}

$start = self::getMicroTime();

$redis = self::getRedis();

do {

// [1] 锁的 KEY 不存在时设置其值并把过期时间设置为指定的时间。锁的值并不重要。重要的是利用 Redis 的特性。

$acquired = $redis->set("Lock:{$key}", 1, [‘NX‘, ‘EX‘ => $lockSecond]);

if ($acquired) {

break;

}

if ($timeout === 0) {

break;

}

usleep($sleep);

} while (!is_numeric($timeout) || (self::getMicroTime()) < ($start + ($timeout * 1000000)));

return $acquired ? true : false;

}

/**

* 释放锁

*

* @param  mixed  $key  被加锁的KEY。

* @return void

*/

public static function release($key)

{

if (strlen($key) === 0) {

// 项目抛异常方法

YCore::exception(500, ‘缓存KEY没有设置‘);

}

$redis = self::getRedis();

$redis->del("Lock:{$key}");

}

/**

* 获取当前微秒。

*

* @return bigint

*/

protected static function getMicroTime()

{

return bcmul(microtime(true), 1000000);

}

}
以上是在项目中一些的用到的之处,大家可以更换为自己项目

原文地址:https://www.cnblogs.com/starluke/p/11733220.html

时间: 2024-10-02 08:28:12

PHP实现Redis分布式锁的相关文章

Redis分布式锁实现

直接上代码: 1 package cn.wywk.yac.comm.redis; 2 3 import org.slf4j.Logger; 4 import org.slf4j.LoggerFactory; 5 6 import redis.clients.jedis.Jedis; 7 8 /** 9 * ClassName: redis分布式锁实现 <br/> 10 * date: 2017年2月17日 上午10:23:24 <br/> 11 * 12 * @author 134

redis分布式锁和消息队列

最近博主在看redis的时候发现了两种redis使用方式,与之前redis作为缓存不同,利用的是redis可设置key的有效时间和redis的BRPOP命令. 分布式锁 由于目前一些编程语言,如PHP等,不能在内存中使用锁,或者如Java这样的,需要一下更为简单的锁校验的时候,redis分布式锁的使用就足够满足了.redis的分布式锁其实就是基于setnx方法和redis对key可设置有效时间的功能来实现的.基本用法比较简单. public boolean tryLock(String lock

RedLock.Net - 基于Redis分布式锁的开源实现

工作中,经常会遇到分布式环境中资源访问冲突问题,比如商城的库存数量处理,或者某个事件的原子性操作,都需要确保某个时间段内只有一个线程在访问或处理资源. 因此现在网上也有很多的分布式锁的解决方案,有数据库.MemCache.ZoopKeeper等等的方式. 这次,我们要学习的是一个基于Redis分布式锁的插件,RedLock.Net. 首先必须要有一个Redis服务来支持此分布式锁,其次就当然是要获取此插件了. 可以从Nuget中获取,也可以直接去Github下载   https://github

redis分布式锁小试

一.场景 项目A监听mq中的其他项目的部署消息(包括push_seq, status, environment,timestamp等),然后将部署消息同步到数据库中(项目X在对应环境[environment]上部署的push_seq[项目X的版本]).那么问题来了,mq中加入包含了两个部署消息 dm1 和 dm2,dm2的push_seq > dm1的push_seq,在分布式的情况下,dm1 和 dm2可能会分别被消费(也就是并行),那么在同步数据库的时候可能会发生 dm1 的数据保存 后于

Memcached 和 Redis 分布式锁方案

分布式缓存,能解决单台服务器内存不能无限扩张的瓶颈.在分布式缓存的应用中,会遇到多个客户端同时争用的问题.这个时候,需要用到分布式锁,得到锁的客户端才有操作权限. Memcached 和 Redis 是常用的分布式缓存构建方案,下面列举下基于Memcached 和 Redis 分布式锁的实现方法. Memcached 分布式锁 Memcached 可以使用 add 命令,该命令只有KEY不存在时,才进行添加,或者不会处理.Memcached 所有命令都是原子性的,并发下add 同一个KEY ,只

spring boot redis分布式锁

随着现在分布式架构越来越盛行,在很多场景下需要使用到分布式锁.分布式锁的实现有很多种,比如基于数据库. zookeeper 等,本文主要介绍使用 Redis 做分布式锁的方式,并封装成spring boot starter,方便使用 一. Redis 分布式锁的实现以及存在的问题 锁是针对某个资源,保证其访问的互斥性,在实际使用当中,这个资源一般是一个字符串.使用 Redis 实现锁,主要是将资源放到 Redis 当中,利用其原子性,当其他线程访问时,如果 Redis 中已经存在这个资源,就不允

Redis分布式锁解决抢购问题

首先分享一个业务场景-抢购.一个典型的高并发问题,所需的最关键字段就是库存,在高并发的情况下每次都去数据库查询显然是不合适的,因此把库存信息存入Redis中,利用redis的锁机制来控制并发访问,是一个不错的解决方案. 首先是一段业务代码: @Transactional public void orderProductMockDiffUser(String productId){ //1.查库存 int stockNum = stock.get(productId); if(stocknum =

Redis分布式锁的try-with-resources实现

Redis分布式锁的try-with-resources实现 一.简介 在当今这个时代,单体应用(standalone)已经很少了,java提供的synchronized已经不能满足需求,大家自然 而然的想到了分布式锁.谈到分布式锁,比较流行的方法有3中: 基于数据库实现的 基于redis实现的 基于zookeeper实现的 今天我们重点说一下基于redis的分布式锁,redis分布式锁的实现我们可以参照redis的官方文档. 实现Redis分布式锁的最简单的方法就是在Redis中创建一个key

Redis分布式锁

转自:https://www.cnblogs.com/linjiqin/p/8003838.html 前言 分布式锁一般有三种实现方式:1. 数据库乐观锁:2. 基于Redis的分布式锁:3. 基于ZooKeeper的分布式锁.本篇博客将介绍第二种方式,基于Redis实现分布式锁.虽然网上已经有各种介绍Redis分布式锁实现的博客,然而他们的实现却有着各种各样的问题,为了避免误人子弟,本篇博客将详细介绍如何正确地实现Redis分布式锁. 可靠性 首先,为了确保分布式锁可用,我们至少要确保锁的实现

Redis分布式锁的正确实现方式

前言 分布式锁一般有三种实现方式:1. 数据库乐观锁:2. 基于Redis的分布式锁:3. 基于ZooKeeper的分布式锁.本篇博客将介绍第二种方式,基于Redis实现分布式锁.虽然网上已经有各种介绍Redis分布式锁实现的博客,然而他们的实现却有着各种各样的问题,为了避免误人子弟,本篇博客将详细介绍如何正确地实现Redis分布式锁. 可靠性 首先,为了确保分布式锁可用,我们至少要确保锁的实现同时满足以下四个条件: 互斥性.在任意时刻,只有一个客户端能持有锁. 不会发生死锁.即使有一个客户端在