php实习redis锁机制

<?php

class Redis_lock
{

    public static function getRedis()
    {
        $redis = new redis();
        $redis->connect(‘182.254.208.72‘, 3838, 0);
        $redis->auth(‘eh.123‘);
        return $redis;
    }

    public static function lock($key, $expire = 60)
    {
        if(!$key) {
            return false;
        }
        $redis = self::getRedis();
        do {
            if($acquired = ($redis->setnx("Lock:{$key}", time()))) { // 如果redis不存在,则成功
                $redis->expire($key, $expire);
                break;
            }

            usleep($expire);

        } while (true);

        return true;
    }

    //释放锁
    public static function release($key)
    {
        if(!$key) {
            return false;
        }
        $redis = self::getRedis();
        $redis->del("Lock:{$key}");
        $redis->close();
    }

}

$redis = Redis_lock::getRedis();
Redis_lock::lock(‘lock‘);
$re = $redis->get(‘Sentiger‘);
$re--;
$redis->set(‘Sentiger‘, $re);
Redis_lock::release(‘lock‘);

?>

测试可以 用ab测试工具测试

时间: 2024-10-20 13:26:36

php实习redis锁机制的相关文章

Redis 利用锁机制来防止缓存过期产生的惊群现象-转载自 http://my.oschina.net/u/1156660/blog/360552

首先,所谓的缓存过期引起的“惊群”现象是指,在大并发情况下,我们通常会用缓存来给数据库分压,但是会有这么一种情况发生,那就是在一定时间 内生成大量的缓存,然后当缓存到期之后又有大量的缓存失效,导致后端数据库的压力突然增大,这种现象就可以称为“缓存过期产生的惊群现象”! 以下代码的思路,就是利用“锁机制”来防止惊群现象.先看代码: class KomaRedis{ private $redis; //redis对象 private static $_instance = null; private

【连载】redis库存操作,分布式锁的四种实现方式[三]--基于Redis watch机制实现分布式锁

一.redis的事务介绍 1. Redis保证一个事务中的所有命令要么都执行,要么都不执行.如果在发送EXEC命令前客户端断线了,则Redis会清空事务队列,事务中的所有命令都不会执行.而一旦客户端发送了EXEC命令,所有的命令就都会被执行,即使此后客户端断线也没关系,因为Redis中已经记录了所有要执行的命令. 2. 除此之外,Redis的事务还能保证一个事务内的命令依次执行而不被其他命令插入.试想客户端A需要执行几条命令,同时客户端B发送了一条命令,如果不使用事务,则客户端B的命令可能会插入

高并发情况利用锁机制处理缓存未命中

关于缓存的使用,个人经验还是比较欠缺,对于缓存在应用系统中的使用也只是前几个月在公司实习的时候,简单的使用过,且使用的都是人家把框架搭建好的,至于缓存在并发情况下会产生的一系列问题都已经被框架处理好了,我所做的只是set和get,至于使用时缓存在并发情况下到底会出现什么样的问题,该如何去解决和避免这些问题,没有去深究. 秉着"学而时习之"的态度(T_T自己太懒,厚着脸皮),这两天在鼓捣redis,至于redis的基本使用还是挺简单的,今天要说的是我在这个过程中看到网上博客一直提的关于缓

SqlServer锁机制与实践

在如今这个云计算,大数据,移动互联网大行其道的时代,各种NoSQL数据库MongoDb.redis.HBase等使用的越来越广泛,大有替代关系型数据库的趋势.但是关系型数据库真的已经落伍了吗?答案是否定的.非关系型数据库不支持ACID属性,不支持事务,无法适应复杂查询的缺点.关系型数据库凭借其强一致性的特点,注定了在类似银行转账,订单支付等场景中,还是唯一的选择.众所周知,SQLSERVER通过锁来提供ACID属性,处理并发访问,本文尝试通过对锁机制的一些学习,让我们明白数据库查询超时,死锁等问

基于Oracle数据库锁机制,解决集群中的并发访问问题

1.需求 应用场景是这样的: 使用Oracle数据保存待办任务,使用状态字段区分任务是否已经被执行.多个Worker线程同时执行任务,执行成功或失败后,修改状态字段的值. 假设数据库表结构如下所示. create table Task( id varchar2(32), name varchar2(32), flag varchar2(1), worker varchar2(32) ); flag 可取的值包括:0-待办,1-已办,-1-失败待重试. 需要避免的问题: 多个Worker同时工作时

REDIS 事务机制

基本事务操作: 任何数据库都必须要保证一种原子执行操作:最基本的原子执行操作肯定是需要提供: 举一个例子来说明: 当对某个Key 做一个统计: 可能不同的Client做它那部分的统计,一段时间后,服务器端需要得出那个key的具体值 Client1: GET number number = number +N1; SET number number+N1; Client2: GET number number = number +N2; SET number number+N2; 原本来讲 ,期望

Java开源生鲜电商平台-OMS订单系统中并发问题和锁机制的探讨与解决方案(源码可下载)

Java开源生鲜电商平台-OMS订单系统中并发问题和锁机制的探讨与解决方案(源码可下载) 说明:Java开源生鲜电商中OMS订单系统中并发问题和锁机制的探讨与解决方案: 问题由来     假设在一个订单系统中(以火车票订单系统为例),用户A,用户B都要预定从成都到北京的火车票,A.B在不同的售票窗口均同时查询到了某车厢卧铺中.下铺位有空位.用户A正在犹豫订中铺还是下铺,这时用户B果断订购了下铺.当用户A决定订下铺时,系统提示下铺已经被预订,请重新选择铺位.在这个系统场景中,我们来探讨一下,火车票

分布式锁机制

大多数互联网系统都是分布式部署的,分布式部署确实能带来性能和效率上的提升,但为此,我们就需要多解决一个分布式环境下,数据一致性的问题. 当某个资源在多系统之间,具有共享性的时候,为了保证大家访问这个资源数据是一致的,那么就必须要求在同一时刻只能被一个客户端处理,不能并发的执行,否者就会出现同一时刻有人写有人读,大家访问到的数据就不一致了. 一.我们为什么需要分布式锁? 在单机时代,虽然不需要分布式锁,但也面临过类似的问题,只不过在单机的情况下,如果有多个线程要同时访问某个共享资源的时候,我们可以

redis锁的进化历程

日常工作中总是会有高并发的场景,需要实现锁机制来保证序列性,接下来我们一步一步实现一个 单机Redis下完全可靠的Redis锁(ps: 如果是Redis集群的话,就存在主从切换锁失效的问题,解决这个问题的话就比较麻烦了,这里不做讨论,现有的解决方案有redlock,大家可以看下它的实现原理) Redis锁 第一版(php实现): //加锁 public function lock($key) { $redisConnect = Redis::connection(); $v = $redisCo