经验首页 前端设计 程序设计 Java相关 移动开发 数据库/运维 软件/图像 大数据/云计算 其他经验
当前位置:技术经验 » 数据库/运维 » Redis » 查看文章
Redis全方位详解--数据类型使用场景和redis分布式锁的正确姿势
来源:cnblogs  作者:JohnsonChung  时间:2018/10/22 16:17:59  对本文有异议

 

一、Redis数据类型

  1.string

    string是Redis的最基本数据类型,一个key对应一个value,每个value最大可存储512M。string一半用来存图片或者序列化的数据。

  2.hash

    相当于一个string类型的映射表。特别适合用来存储对象。例如可以存储用户信息,用户ID作为hash类型里的每一个key。

    案例:我们这边需要对接微信粉丝的数据到我们自己的平台上,但微信提供的接口只支持单天查询,那么如果我们想要查看最近一个月微信粉丝的状况,就需要循环30次调用微信的接口。一个月勉强还可以接受,那么如果想要查半年,甚至一年呢?那么我们的接口里就需要循环365次调微信的接口,这就会使我们的接口变得非常慢,甚至超时。还有这些数据,比如单天新增粉丝数,是不会变得,而且每天都有一个数据,这样就特别适合存在redis的hash类型里,以日期(2018-10-10)作为hash的key。

  3.list

    list类型是简单的字符串列表,每个列表可以存储232 - 1 个值。可以从头部或者尾部顺序插入数据。list类型可以用来做电商里的秒杀营销系统或关注列表。

  4.set

    set是string类型的无序集合。该集合是通过哈希实现的,添加、删除的复杂度都是O(1),所以查找非常快。

    案例:我们这边是以手机号为唯一标示符,防止重复用户注册,会判断该手机号有没有注册过,那么如果用set类型存储注册过的用户手机号,就会很快判断出该用户是否注册过,而不用去查数据库了。

  5.zset

    和set一样,但zset多了一个score来让set变得有序,且不允许有重复的成员。

    案例:我们这边有一个账户记录需要按记录时间排序,那么就可以将时间戳当作score存储zset中。

 

二、redis分布式锁

  网上很多redis分布式锁的实现方式不能说错误的,但至少不够严谨,在某些极端情况下是会出问题的。一旦出现问题,还是挺麻烦的事情,所以我们要知道redis分布式锁的正确姿势。

  其实很简单,利用redis的原子性。关于原子性,官方的一段描述为:

  大概意思就是redis执行lua脚本的时候,会被当成一条命令执行,在此期间,不会执行其他命令,所以lua脚本尽量是快脚本而不是慢脚本。

  所以,正确的姿势是:

  1. public function getDistributeLock($redis, string $key, int $userId, int $expire)
  2. {
  3. $luaScript = <<<LUA
  4. if (redis.call('exists', KEYS[1]) == 0) and redis.call('setex', KEYS[1], ARGV[1], ARGV[2])
  5. then
  6. return 1
  7. else
  8. return 0
  9. end
  10. LUA;
  11. return $redis->eval($luaScript, 1, $key, $expire, $userId) > 0 ? true : false;
  12. }

 

  这里我们把一段lua脚本放到redis的eval方法里执行,这样就可以保证这一段命令的原子性。

  那么如果不用lua脚本,姿势应该是这样的:

  1. public function wrongGetDistributeLock($redis, string $key, int $userId, int $expire)
  2. {
  3. // 若锁不存在,则加锁
  4. if(!$redis->exists($key) && ($redis->setex($key, $expire, $userId) == 'OK')) {
  5. return true;
  6. }
  7. return false;
  8. }

  前面提到过,这种姿势在某些情况下会出问题:如果同时好几个客户端同时请求,同时通过了上面if条件的第一层,那么这时候就会出现多个同时拿到锁,并且前面人的锁会被覆盖。

 

  然后,正确的解锁姿势是:

  1. public function releaseDistributeLock($redis, string $key, int $userId)
  2. {
  3. $luaScript = <<<LUA
  4. if redis.call('get', KEYS[1]) == ARGV[1]
  5. then
  6. return redis.call('del', KEYS[1])
  7. else
  8. return 0
  9. end
  10. LUA;
  11. $redis->eval($luaScript, 1, $key, $userId);
  12. }

  同样需要使用lua脚本来达到原子性。那么如果不使用lua脚本的姿势是:

  1. public function wrongReleaseLock($redis, string $key, int $userId)
  2. {
  3. if($userId == $redis->get($key)) {
  4. $redis->del($key);
  5. }
  6. }

  会有这样一种情况:A请求通过if语句后,这时候这个redis的key刚好过期了,然后B客户端加锁成功,这时候A请求就会把客户端B刚加的锁给解除了。

  虽然我上面提到的两种情况都是很极端、很少出现的。但如果可以用很简单的方法避免掉,so why not?

  上面提到的redis分布式锁,满足了三个特性:

  • 互斥性。同时只能又一个客户端拥有锁
  • 不会发生死锁。 
  • 加锁和解锁的必须是同一个客户端。

  童鞋们,有什么疑问,可以在地下留言哦。

 

 友情链接:直通硅谷  点职佳  北美留学生论坛

本站QQ群:前端 618073944 | Java 606181507 | Python 626812652 | C/C++ 612253063 | 微信 634508462 | 苹果 692586424 | C#/.net 182808419 | PHP 305140648 | 运维 608723728

W3xue 的所有内容仅供测试,对任何法律问题及风险不承担任何责任。通过使用本站内容随之而来的风险与本站无关。
关于我们  |  意见建议  |  捐助我们  |  报错有奖  |  广告合作、友情链接(目前9元/月)请联系QQ:27243702 沸活量
皖ICP备17017327号-2 皖公网安备34020702000426号