深入理解PHP+Redis实现分布式锁的相关问题

后端   2024-03-26 21:43   1137   0  

概念

PHP使用分布式锁,受语言本身的限制,有一些局限性。

  • 通俗理解单机锁问题:自家的锁锁自家的门,只能保证自家的事,管不了别人家不锁门引发的问题,于是有了分布式锁。

  • 分布式锁概念:是针对多个节点的锁。避免出现数据不一致或者并发冲突的问题,让每个节点确保在任意时刻只有一个节点能够对公共资源进行操作,单机的锁只能够单节点使用,多节点防不住。

  • 核心原理:分布式锁的核心原理,就是在每个节点执行时,先去一个公共的地方判断是否持有锁,如果有锁就说明资源被占用,没锁就可以持有该资源。

  • 通俗举例:多个部门,开部门会议,需要占用会议室的位置,发现会议室门关着,不知道里面有没有人,此时门外面有个牌子说明是会议中,还是会议结束,离老远就知道会议室是不是被占用了,避免会议竞争引起的错乱。

应用场景

  • 分布式排它:保证只有一个节点被访问,常用于秒杀,等并发问题的处理。

  • 分布式任务调度:在分布式任务调度系统中,多个节点可能会竞争执行同一个任务,使用分布式锁可以确保只有一个节点能够执行该任务,避免重复执行和冲突。

  • 并发下数据库事务幻读问题:并发下的MySQL事务当中,插入数据前先判断有没有,没有再插入,从而避免重复,但是其它事务未提交,就检测不到(RR的隔离级别导致的),但是插入相同数据,又会导致唯一约束起作用从而报错,添加分布式锁,从而避免报错。(这场景适用于唯一约束冲突报错很多的场景功能,否则使用了会影响性能)。

分布式锁的特点

  1. 互斥性,相同时间,只能有一个节点会获取该锁,其它节点要么等待要么直接返回失败。

  2. 可重入(单个节点可重复获取该锁且不会发生阻塞)。

  3. 安全(获取锁的节点崩溃或失去连接、锁资源会释放)。

可用的存储组件选择

Redis、MySQL(乐观锁、或悲观锁)、ZooKeeper、Etcd、Memcache等存储组件都可以实现分布式锁。
ZooKeeper、Etcd是Java生态,PHP几乎不用。
Memcache很少用了,一般都会用redis。
MySQL性能比不了Redis,高并发过来容易被夯住,数据不会自动过期删除,需要逻辑判断。所以也不用。

分布式锁要求高性能,和自动过期的兜底特性,所以用Redis的set命令刚好。
Redis分布式锁,又称为Redis Distributed Lock,也叫RedLock。

用Redis手动实现分布式锁(示例)

这是花十分钟写出来的例子,不建议商用。

class RedLock {    
    //声明redis
    private $redis; 
       
    /**
     * @function 构造方法初始化redis
     * @other    void
     */
    public function __construct() {        
        $redis = new Redis();        
        $redis->connect('127.0.0.1', 6379);        
        $this->redis = $redis;
    }    
     /**
     * @function 非阻塞分布式锁
     * @param    $key string 锁名称
     * @param    $ttl int    key自动过期时间,单位毫秒
     * @return   array       返回操作的结果
     * @other    void
     */
    public function addLock($lock_name, $ttl = 10000) {        
         $lock_name = 'red_lock_' . $lock_name;        
         $val = base64_encode(openssl_random_pseudo_bytes(32));        
         $set = $this->redis->set($lock_name, $val, ['NX', 'PX' => $ttl]);        
         if($set === false) {            
             return ['status' => false, 'msg' => '锁设置失败', 'key' => '', 'val' => ''];
         }        
         return ['status' => true, 'msg' => '', 'key' => $lock_name, 'val' => $val];
    }    /**
     * @function 阻塞式分布式锁
     * @param    $key string 锁名称
     * @param    $ttl int    key自动过期时间,单位毫秒
     * @param    $ttl int    超时时间,单位毫秒
     * @return   array       成功返回数组,失败返回false
     * @other    void
     */
    public function addLockSpin($lock_name, $ttl = 10000, $timeout = 3000) {        
         $lock_name = 'red_lock_' . $lock_name;        
         $start = bcmul(microtime(true), 1000, 2);        
         $val = base64_encode(openssl_random_pseudo_bytes(32));        
         $set = $this->redis->set($lock_name, $val, ['NX', 'PX' => $ttl]);        
         if($set === false) {            
             while(true) {                
                 //超时
                $start_loop = bcmul(microtime(true), 1000, 2);                
                if(bcadd($start, $timeout, 2) <= $start_loop) {                    
                    return ['status' => false, 'msg' => '超时', 'key' => '', 'val' => ''];
                }
                                    
                //尝试获取锁
                $set_loop = $this->redis->set($lock_name, $val, ['NX', 'PX' => $ttl]);                
                if($set_loop) {                    
                    return ['status' => true, 'msg' => '', 'key' => $lock_name, 'val' => $val];
                }    
                                
                usleep(50000);
            }
        }        
       return ['status' => true, 'msg' => '', 'key' => $lock_name, 'val' => $val];
    }    
     /**
     * @function 释放锁资源
     * @param    $key array 锁资源
     * @return   bool
     * @other    void
     */
    public function unLock($lock) {        
         if($lock['status'] === false) {            
             return false;
         }
                     
         $script = <<<LUA_DEL_LOCK
            if redis.call("GET", KEYS[1]) == ARGV[1] then
                return redis.call("DEL", KEYS[1])
            else
                return 0
            end
        LUA_DEL_LOCK;        
         
        return $this->redis->eval($script, [$lock['key'], $lock['val']], 1) ? true : false;
    }
}
//调用端-------------------------------------------------------------------------------
$redLock = new RedLock();$lock = $redLock->addLockSpin('test_key', 10000, 3000);
if(! $lock['status']) {    
    echo '锁没有抢到,原因:' . $lock['msg'];
} else {    
    echo '抢到锁了,处理一些业务逻辑,然后释放锁资源';    
    $redLock->unLock($lock);
}

现有的解决方案

java实现分布式锁有redisson,PHP也有自己的包。
看过一些博主的用PHP实现分布式锁,好多没有使用Lua,这没办法保证多条Redis语句原子性的执行。
项目中能用到这种东西的,对于高可用、原子性、稳定性有很强的依赖,所以推荐使用成熟的扩展包。

composer require signe/redlock-php
文档:https://packagist.org/packages/signe/redlock-php
执行之后看使用redis的monitor指令查看,发现用了Lua,说明这个包,兼顾了原子性的操作。
我这个是示例,记得无论最后执行成功还是失败,都记得及时释放锁资源。

非自旋写法
$server = new \Redis;
$server->connect('127.0.0.1', 6379);
$servers = [$server,];

$redLock = new \RedLock\RedLock($servers);
$lock = $redLock->lock('my_resource_name', 10000);

if($lock) {    
    echo '加锁成功';    
    $redLock->unlock($lock);
} else {    
    echo '加锁失败';
}


自旋写法
$server = new \Redis;
$server->connect('127.0.0.1', 6379);
$servers = [$server,];

$redLock = new \RedLock\RedLock($servers);
$lock = $redLock->lock('my_resource_name', 10000);

if($lock) {    
    echo '加锁成功';
    //    $redLock->unlock($lock);
} else {    
    while(true) {        
        $lock2 = $redLock->lock('my_resource_name', 10000);        
        if($lock2) {            
            echo '加锁成功2';            
            //运行某些代码
            $redLock->unlock($lock2);            
            return '';
        } 
    }
}

如果需要:拿到锁后,释放锁前,业务逻辑代码块再对拿到锁的分布式锁续期。
因为redis的key与val值都不变,只变动过期时间,所以使用PEXPIRE指令,也可使用PSETEX指令。
又需要防止这个锁自动过期,已经被其它节点占用,已经改成了其它节点的数据,所以value值需要验证是不是当前锁的value值。
两个操作为了保证原子性,就用到了Lua。

//$redLock = new \RedLock\RedLock($servers);
//$lock = $redLock->lock('my_resource_name', 20000);

$script = '
            if redis.call("GET", KEYS[1]) == ARGV[1] then
            	return redis.call("PEXPIRE", KEYS[1], KEYS[2])
            else
                return 0
            end
        ';
$server->eval($script, [$lock['resource'], '毫秒过期时间', $lock['token']], 2);

PHP使用分布式锁的局限性问

  • 超时问题没有监控机制:没有像redisson一样的watch dog看门狗的机制,去监控业务执行过长导致redis分布式锁自动释放,被其它锁占用的问题。 可能需要Swoole的异步才支持
    PHP使用分布式锁,有种照猫画虎的感觉。

为什么加锁时set指令要加NX

set指令加nx表示,只有在key不存在的情况下才能设置键值对。
多个节点加锁,获取分布式锁资源,实质就是在redis中设置一条值。因为分布式锁的排它性,同一时间内只能有一个节点可以拿到该锁。
若用set,不加nx,就会产生覆盖,造成业务错乱。

客户端宕机导致锁资源无法释放的死锁问题

redis单线程通常不会发生死锁问题。
Redis在客户端挂掉的情况的情况,会导致分布式锁锁资源无法及时释放,这可能会导致其它节点无法加锁从而阻塞,类似死锁的效果。
添加过期时间做兜底即可。

对高可用:MySQL可以主从,Redis也可以,从而保证分布式锁存储的高可用性。

分布式锁redis操作的原子性问题

用redis做抢购秒杀仍旧超卖,问题也是出在这里。你写的多条redis,看起来是针对同一条数据的操作,其实在并发情况下,是有间隙的
就算是redis事务(multi)也是弱事务,仍旧会出现并发安全问题,最好使用Lua+Redis的方式去实现原子性的分布式锁,这会把一些指令集当做一个任务队列去处理,保证原子性。
注意这里说的原子性,不是Redis事务的原子性,而是说操作同一数据要么都成功或者都失败,没有lua的加持,高并发情况下,分布式锁的释放,无法保证get和del的是同一条数据。
若不用Lua,举个例子:
高并发情况下:
get库存为10, decr库存你以为是9,实际上可能小于9,因为你get之后再decr库存,中间有间隙,可能已经被其它并发过来的请求decr过了,超卖的实质就是这样产生的。
用Lua写成一个整体,则可以保证这两个语句没有间隙。至于,成功则都成功,失败则都失败的原子性,靠的是Lua脚本的判断逻辑。

难道Redis事务没办法保证ACID吗,非要用Lua

无法保证。
redis的事务是弱事务BASE,ACID无法保证。
multi声明的事务,我认为叫批量执行命令(批处理)更好。官方给他起了个名称,叫管道(避免频繁的命令往来,造成的性能问题)。
管道的极简类比:买10瓶水,去10次超市,1次买1瓶的开销。和一次性买10瓶水,只去1次的开销。如果不利用管道,redis需要多次io,用户态到内核态的转变,对于进程上下文有影响,管道用来解决这个问题。
把multi当做乐观锁来用,那就是弱事务,当做批处理来用,那就是管道。

从底层分析MySQL与Redis事务:

  • 原子性(A):MySQL是由undo log实现的,也叫做回滚日志,支持原子性。Redis事务不支持(multi中遇到语法错误会整体回滚,但是遇到执行错误,例如incr string就不会全部回滚,正确的语句仍执行)。

  • 一致性(C):一致性是指从一个合法的状态变为另一个合法的状态,执行自增10,不会变成11,12,这一点MySQL可以保证,redis可以保证。

  • 隔离性(I):多个事务可以并发执行,各个事务之间的操作互相隔离。MySQL有MVCC机制对4种隔离级别提供的底层支撑,所以有快照读和当前读之分。Redis只有Watch实现的乐观锁可以保证,没有隔离级别的概念。

  • 持久性(D):MySQL持久化数据,数据是持久化到了页上,为了保证高可用出现了redo log(重做日志)机制,而redis虽然有AOF和RDB,但持久化机制不是实时的,实时对持久化是高可用,但会降低性能,而redis就是为了快,所以持久性有,无法保证高可用。

如何设置拿到锁资源后的超时时间

对于Java,redisson有watch dog的自动监控机制,但是PHP没有。
PHP也很难实现,原因有2:

  • 不知道自动续期的时机:业务流程没走完,分布式锁临近过期才续期,业务流程走完了还续什么期?这个时机,高并发场景下难以获取,净增加复杂度。

  • PHP语言本身缺少锁机制:就算知道了要续期,加锁与续期监控,缺少锁机制的强关联,加锁一个进程,监控又一个进程,进程间通信是一个问题,PHP进程间通信与Redis操作无法原子执行又是一个问题,也就是说就算被通知要续期了,再续期时,锁资源超时自动释放后,可能都被别的节点占用了。

PHP能做的只能是设置更多的超时时间,来防止锁资源自动释放被其它节点抢走。
缺点也很明显,一旦这个节点挂掉,锁资源需要很长时间才能释放,这个时间段的分布式锁无法被任意一个节点使用。

锁资源的错误释放问题

时序图:

步骤客户端1客户端2补充
1获取锁成功//
2执行中获取锁失败客户端1的锁阻塞了客户端2
3执行中获取锁失败客户端2自旋,不断尝试获取锁
4锁资源到期自动释放获取锁成功由于客户端1的锁资源过期,才导致客户端2拿到的分布式锁
5释放锁执行中这一步才是客户端1真正释放(删)锁的时刻,但是由于没做验证,这个释放(删)的过程,会把会话2创建的锁给释放(删)掉,造成误删除

为了避免这个问题,val值可设置为节点标识。
所以redis在get值的时候,需要判断,val值是不是当前的节点标识。
为了保证原子性,查询和删除两个操作需要用Lua脚本。

其次要注意,不管节点程序执行成功或者失败,只要该走的流程走完了,都需要及时释放锁。

分布式锁的可重入问题

  • 极简概括:单个进程(或线程),单节点可重复上锁,不用等待,避免死锁。这种机制是为了避免,在循环或者递归获取锁时,第一层循环成功,之后失败的问题。(大部分场景不需要这个重入性,某些场景才需要)。

  • 动作分析:看我自行封装的的代码,假设同一个节点,递归或循环获取分布式锁,就算是同一节点,获取分布式锁后,再次获取分布式锁,也得自旋,等自家节点的分布锁释放后,再获取锁,这个地方可以改进。

  • 实现思路:重入问题,还需要再维持一个redis hash,key为锁名,field为节点的唯一标识,value为重入次数,重入1次次数加1,释放重入1次次数减1,为了避免因业务逻辑耗时而导致锁过期,还需要给当前的锁续期。期间的多个操作,也需要在Lua脚本中执行。

不过对于PHP而言,以当前的认知来看,重入性用不上。 因为重入,相当于在获取锁的情况下,多次获取同一把锁,那直接在if(拿到锁){}这里写逻辑就行了是不是,何必多次拿到一样的锁。

分布式锁的自旋机制

自旋可以理解为内部死循环,内部不断重试,直到满足条件,直观感受就是被阻塞。
如果没有自旋,10个节点,只有1个能加锁成功,其余9个失败,如果这9个全部失败掉,看起来差点意思。

因此可以选择被阻塞,期间不断重试,所谓的自旋方案,其实很好理解,重试伪代码如下:

while(加锁失败) {	
    usleep(10000);
	重新尝试加锁代码	
    if(加锁成功) {		
        return '加锁成功';
    }
}

此处也可以添加一个次数限制,防止永久死循环的兜底策略
$retry_count = 0;
while(true) {    
    $retry_count ++;    
    if('加锁成功') {        
        return '加锁成功';
    }    
    
    if($retry_count > 20) {        
        echo 1;        
        return '重试次数过多';
    }    
    usleep(30000);
}

也可以根据时间去做限制,防止永久死循环的兜底策略
$start_time = microtime(true);
while(true) {    
    if($start_time + 5 <= microtime(true)) {		
        return '超时';	
    }    
        	
    if('加锁成功') {		
        return '加锁成功';
        }	
    usleep(30000);
}

Redis主从架构对分布式锁的高可用问题

节点1再master上获取到了分布式锁,叫lock1,此时master还没有同步到slave,结果master挂掉了。
此时故障转移,slave做顶梁柱,节点2也获取到了slave的分布式锁,也叫lock1。
这种情况违背了分布式锁的排它性。概率很小,但是有可能发生。
setnx无法解决分布式场景下的锁排它性问题。
这个是运维层面要考虑的东西。

手动实现分布式锁容易被忽略的问题

分布式锁这种工程化的东西,每个零件都有用,虽然RedLock底层用redis set指令实现。

  • 若忘记加超时时间:上锁的节点挂掉没有释放锁资源,其它节点会一直拿不到锁,严重影响业务。

  • 若忘记加value值判断去释放锁:A节点在执行业务逻辑超时,自动释放锁资源被B节点抢去,等A节点执行完业务代码后释放锁,会把B节点的锁删除。

  • 若忘记用Lua脚本:这导致redis在执行任务期间,同一客户端的多个脚本不会在一个Redis内置的任务队列处理,保证不了原子性,超卖的并发安全问题就是这样产生的。

  • 覆盖问题:redis分布式锁设置值时,用的setnx思想(有值则不设置,避免覆盖),若用set,整不好把原先的覆盖掉了。

  • 可能缺少过期锁自动续期机制:就对PHP而言,手动实现可能缺少key的监控过期,毕竟PHP没有像Java Redisson中那样的watch dog机制。

  • 若忘记重入性问题:这会导致多节点多次添加分布式锁,有阻塞或者失败的可能。


博客评论
还没有人评论,赶紧抢个沙发~
发表评论
说明:请文明发言,共建和谐网络,您的个人信息不会被公开显示。