《redis入门指南》之事务、缓存、排序、消息通知与空间节约

举报
竹叶青 发表于 2019/12/16 20:37:16 2019/12/16
【摘要】 这一章节收获不少,其中最开眼界的是redis的强大的排序功能,以及如果信手拈来的事务功能。很多时候,技术本身没有问题,但是抽象的过于复杂,使得解决问题往往不是聚焦在问题本身,而是各类周边的工具。Redis在作为一个强有力的解决问题的工具方面,无疑是非常突出的。事务在我固有的印象中,事务是属于sql数据库才专有的特权,不过随着no-sql数据库的逐步成熟,这点确实有所变哈。redis的事务功能...

这一章节收获不少,其中最开眼界的是redis的强大的排序功能,以及如果信手拈来的事务功能。很多时候,技术本身没有问题,但是抽象的过于复杂,使得解决问题往往不是聚焦在问题本身,而是各类周边的工具。Redis在作为一个强有力的解决问题的工具方面,无疑是非常突出的。

事务

在我固有的印象中,事务是属于sql数据库才专有的特权,不过随着no-sql数据库的逐步成熟,这点确实有所变哈。

redis的事务功能,简单、直观,并且能够在实际的业务中发挥作用。一般的事务用法有两种: 1. 使用Multi关键字包裹 使用multi关键字,可以将需要一起执行的语句,保证同时发送到redis-server侧进行处理。如果说语句中存在语法错误,那么会全部终止(redis 2.6.5 以后)。 但是如果在执行的时候出现了运行时错误,比如set了一个哈希map的key,那么这时候就无法进行回滚操作了,这点需要尤其注意。不过一般而言,这类错误应该在测试阶段就能够被发现并规避了。

这里举一个使用redis保存微博中的关注关系的实例: 每个用户都有一个关注的集合followingSet,对应的被关注的用户也有一个被关注的集合followedSet, 那么每次有关注关系发生的时候,绑定关系一定要是双向的:

$ret = $redis->multi()
    ->SADD("{$userIdA}:followingSet",userIdB)
    ->SADD("{$userIdB}followedSet",userIdA)
    ->exec();
  1. 使用watch关键字 很多时候我们希望对一些独占的变量进行修改的过程中,不希望被打断,因为一旦变量的值被他人更改,很容易出现不一致的问题。这在一些抢占***、领礼券等常见的业务场景中都有需求。所以这个时候一般就会使用watch与multi关键字结合。

举一个领礼券的例子:

// 假设有100个礼物 关注礼物数量这个key$redis->watch("giftcnt");// 用户领一个礼物,礼物数量减1,同时标识用户已经领过礼物了$ret = $redis->multi()
    ->incrBy("giftcnt",-1)
    ->set("user:hasgift",1)
    ->exec();

假如说出现了静态条件,用户A在进行执行事务操作的时候,发现giftcnt已经不是自己获取的那个了,那么他的操作就需要终止,从而保证数量和表示状态的一致性。 Watch的思想,即是乐观锁,重试一次,希望不再遇到静态条件。一般事务成功的执行了之后,那么watch的过程也就完成了。

过期时间

在过期时间这个点上,最能体现redis作为缓存的功用。这也是我在深入了解redis之前唯一有概念的点。由于之前一直在用腾讯自研的CKV,其中用到最多的,确实也是这个expire的特性。

应该说,key的expire特性最能够体现大家使用缓存的普遍方式。那就是被动缓存,数据落地在mysql,同时缓存一份有过期时间的在redis,一旦过期之后,client再重新获取,继而写入到缓存中。一旦数据变更,则写入mysql,再写入缓存。 不过根据左耳朵耗子在博客中的分享,这种做法尽管能够满足一些常见的访问量不高的场景,但是在高并发的情况下是有问题的。设想client A访问cache,发现miss了,读取mysql,写入cache。但是与此同时,client B写入了mysql,而这个时间是在A已经把旧的数据灌入cache之后的。这就出现了问题。关于这个问题,不再深究,但是可以看看http://coolshell.cn/articles/17416.html 这篇文章。

redis中expire命令,针对string类型的键: EXPIRE key seconds PEXPIRE key miliseconds

也可以使用PERSIST/SET key命令把key恢复成永久。

从使用场景上面来看的话,比较常见的场景之一,就是实现访问的频率控制。针对唯一的用户+接口,我们希望限制他的访问频率在每分钟固定次数,比如100次。那么就可以通过如下的方式实现:

$listLength = LLEN rate.limiting:$IPif $listLength < 100
    LPUSH rate.limiting:$IP, noew()else 
    $time = LINDEX rate.limiting:$IP, -1 
    if now() - $time < 60
        print "访问频率超过限制"
    else 
        MULTI
        LPUSH rate.limiting:$IP, now()
        LTRIM rate.limiting:$IP, 0, 99   
        EXEC

另外非常常见的场景,就是用作纯粹的缓存,这里需要注意两点: 缓存时间的设置expire命令需要单独执行,并非原子操作,最好使用事务进行包装 在用作缓存服务器的时候,必须限制redis使用的最大内存,并且使用一定的策略进行键值的淘汰,从而实现内存利用的最大化 maxmemory memory-policy

排序

说老实话,在接触这部分内容之前,我以为redis的排序仅仅是使用有序集合来进行排列。但是其实redis内置了非常强大的SORT等命令,来完成各种排序,尤其是连接查询排序的功能。

如果我们相对包含了所有文章id的有序集合排序,那么就可以直接使用: SORT articles:score DESC LIMIT 1 2 这样不但能够根据文章id的大小降序排列,还能limit返回的数量来方便翻页。

而对于更复杂的排序需求,则就需要使用BY关键字了。假如说,我们需要按照article的时间排序,那么就需要用到article的hashmap的结构了: SORT articles:score BY article:*->time DESC 其中的*号就会被集合中的元素来替代,你可以理解成对articles:score做了一个foreach,然后被通配符*给替代了。这个用法确实令人耳目一新。

而除了使用哈希表中的元素,一个字符串类型的键同样也能被用作排序的key。

另外一个使用排序经常关心的问题,就是返回的结果的格式。按照上文中SORT的用法,会返回一系列排序好的文章id,然后需要手动的去hget其中的数据。而GET关键字就能够解决这个问题:

SORT articles:score BY article:*->time DESC GET article"*->title GET article"*->time GET # #号表示获取id。

如果想把返回的结果以列表的形式存储,那么可以使用: SORT articles:score BY article:*->time DESC GET article"*->title GET article"*->time GET # STORE sort.result

再配合EXPIRE命令,就可以进行缓存,从而保证SORT这类高耗时的操作不那么频繁的执行。

从性能来来讲,SORT的时间复杂度是O(n+mlog(m)), 同时redis也会提前建立一个长度为n的容器来存储待排序的元素。所以使用时一定注意: 尽可能减少待排序键中元素的数量(减少N) 使用LIMIT参数只获取需要的数据(减少M) * 充分利用STORE命令进行必要的缓存

消息通知

除了缓存,另外一个redis被流传最广的用法就是实现一个简易的队列。尽管从业界的使用来看,越来越专业的如rabbitMQ、rocketMQ、CMQ、KAFUKA等队列实现方案已经越来越成熟了。但是redis用作队列的简洁高效,仍然是很多队列处理能力要求不高的场景下的不二之选。

一个比较常见的场景是用户注册后,发送验证的邮件。那么定义一个队列 queue:verifymail,那么只需要开一个进程,阻塞的去等待队列,然后决定如何处理即可: BRPOP queue:verifymail 0

但是有的时候,队列也会分优先级,比如找回密码的邮件和注册成功的通知邮件,其实优先级不同。所以可以进行优先级队列的阻塞等待: BRPOP queue:findpassword queue:verifymail 0

除了实现队列任务之外,redis还可以用来实现不同频道的发布与订阅,从而实现后台任务更加顺畅的流转。 而对于发布者和订阅者的定义就是使用PUBLISH和SUBSCRIBE。而不同的频道则可以实现业务的隔离。

比如定义个一个频道是用户发评论,那么可能有积分服务、审核服务等都订阅了这个频道,那么在收到相应的通知之后,就可以进行相应的操作了,比如进行审核,或者是增加用户的积分等等。

本文转载自异步社区

原文链接:

https://www.epubit.com/articleDetails?id=NC7E3EF939CF000016CC51F101CB02360


【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

举报
请填写举报理由
0/200