public function getRedis()
{
$redis = new \Redis();
$redis->connect(env("REDIS_MASTER",'127.0.0.1'),6379);
$redis->auth(env('REDIS_AUTH','123456'));
return $redis;
}
$redis = $this->getRedis();
复制代码
$key = 'str:name';
// 字符串缓存实战
$redis->set($key, 'WXiangQian');
$name = $redis->get($key);
echo $name; // WXiangQian
$redis->expire($strCacheKey, 30); # 设置30秒后过时
复制代码
$key = 'hset:name'
$uid = 1;
$redis->hSet($key, $uid, 'WXiangQian');
$data = $redis->hGet($key, 1);
print_r($data); //输出数据
复制代码
$strKey = 'zset:ranking_list';
//存储数据
$redis->zadd($strKey, '50', json_encode(['name' => 'Tom']));
$redis->zadd($strKey, '70', json_encode(['name' => 'John']));
$redis->zadd($strKey, '90', json_encode(['name' => 'Jerry']));
$redis->zadd($strKey, '30', json_encode(['name' => 'Job']));
$redis->zadd($strKey, '100', json_encode(['name' => 'LiMing']));
$dataOne = $redis->ZREVRANGE($strKey, 0, -1, true);
echo "---- {$strKey}由大到小的排序 ---- <br /><br />";
print_r($dataOne);
$dataTwo = $redis->ZRANGE($strKey, 0, -1, true);
echo "<br /><br />---- {$strKey}由小到大的排序 ---- <br /><br />";
print_r($dataTwo);
复制代码
解释:悲观锁(Pessimistic Lock), 顾名思义,就是很悲观。php
每次去拿数据的时候都认为别人会修改,因此每次在拿数据的时候都会上锁。redis
场景:若是项目中使用了缓存且对缓存设置了超时时间。数据库
当并发量比较大的时候,若是没有锁机制,那么缓存过时的瞬间,json
大量并发请求会穿透缓存直接查询数据库,形成雪崩效应。缓存
/**
* 获取锁
* @param String $key 锁标识
* @param Int $expire 锁过时时间
* @return Boolean
*/
public function lock($key = '', $expire = 5) {
$is_lock = $this->_redis->setnx($key, time()+$expire);
//不能获取锁
if(!$is_lock){
//判断锁是否过时
$lock_time = $this->_redis->get($key);
//锁已过时,删除锁,从新获取
if (time() > $lock_time) {
unlock($key);
$is_lock = $this->_redis->setnx($key, time() + $expire);
}
}
return $is_lock? true : false;
}
/**
* 释放锁
* @param String $key 锁标识
* @return Boolean
*/
public function unlock($key = ''){
return $this->_redis->del($key);
}
// 定义锁标识
$key = 'str:lock';
// 获取锁
$is_lock = lock($key, 10);
if ($is_lock) {
echo 'get lock success<br>';
echo 'do sth..<br>';
sleep(5);
echo 'success<br>';
unlock($key);
} else { //获取锁失败
echo 'request too frequently<br>';
}
复制代码
解释:乐观锁(Optimistic Lock), 顾名思义,就是很乐观。bash
每次去拿数据的时候都认为别人不会修改,因此不会上锁。并发
watch命令会监视给定的key,当exec时候若是监视的key从调用watch后发生过变化,则整个事务会失败。post
也能够调用watch屡次监视多个key。这样就能够对指定的key加乐观锁了。性能
注意watch的key是对整个链接有效的,事务也同样。ui
若是链接断开,监视和事务都会被自动清除。
固然了exec,discard,unwatch命令都会清除链接中的全部监视。
$strKey = 'str:age';
$redis->set($strKey,10);
$age = $redis->get($strKey);
echo "---- Current Age:{$age} ---- <br/><br/>"; // 10
$redis->watch($strKey);
// 开启事务
$redis->multi();
//-------------------------------
/**
* 在这个时候新开了一个新会话执行
*
* redis-cli 执行 $redis->set($strKey,30); //新会话 模拟其余终端
* 这时候$age=30; //30
*/
//-------------------------------
$redis->set($strKey,20);
$redis->exec();
$age = $redis->get($strKey);
echo "---- Current Age:{$age} ---- <br/><br/>"; //30
//当exec时候若是监视的key从调用watch后发生过变化,则整个事务会失败
复制代码
悲观锁:比较适合写入操做比较频繁的场景,若是出现大量的读取操做,每次读取的时候都会进行加锁,这样会增长大量的锁的开销,下降了系统的吞吐量。
乐观锁:比较适合读取操做比较频繁的场景,若是出现大量的写入操做,数据发生冲突的可能性就会增大,为了保证数据的一致性,应用层须要不断的从新获取数据,这样会增长大量的查询操做,下降了系统的吞吐量。
总结:两种所各有优缺点,读取频繁使用乐观锁,写入频繁使用悲观锁。
像乐观锁适用于写比较少的状况下,即冲突真的不多发生的时候,这样能够省去了锁的开销,加大了系统的整个吞吐量。但若是常常产生冲突,上层应用会不断的进行retry,这样反却是下降了性能,因此这种状况下用悲观锁就比较合适,之因此用悲观锁就是由于两个用户更新同一条数据的几率高,也就是冲突比较严重的状况下,因此才用悲观锁.
悲观锁比较适合强一致性的场景,但效率比较低,特别是读的并发低。乐观锁则适用于读多写少,并发冲突少的场景