[需求设计]从一个小需求感受Redis的独特魅力

分享一个简单的小需求应该怎么设计实现以及有关Redis的使用

Redis在实际应用中使用的非常广泛,本篇文章就从一个简单的需求说起,为你讲述一个需求是如何从头到尾开始做的,又是如何一步步完善的。之前写过一篇《如何实现页面广告随时上下线、过期自动下线及到时自动上线》,也涉及到了Redis在项目中的实际应用,有兴趣的可以看一下。

需求

设定,现在我们有一个APP,产品新提出一个叫“程序员树洞”的功能,具体功能就不说了,其中这个功能有一点需要做的是在使用该功能时,如果是首次进入会展示一个协议页面,用户需要勾选后点确定才能进入功能,此后再进该功能,不再显示协议页直接进入该功能。如下图所示,

原型图

原型图 需求分析

需求就是这么的简单,我们来分析一下。
1、用户点击该功能时前端需要知道该给用户显示哪个页面,这一步需要请求后端接口,后台告诉前端这个用户有没有同意过协议。
2、用户勾选协议点确定,后端需要记录这步操作(记录用户已经同意协议),这一步需在点确定时前端请求后端接口。

概要设计

前面需求分析里说了,后端需要告诉前端用户有没有统一过协议,所以后端需要把这个信息记录下来,最好是记录到数据库保存,那就需要一张表来记录同意过协议的用户。表结构大致是:id,客户号,插入时间。

详细设计

1、记录客户是否已同意过协议并提供查询功能(查询是否同意过协议)
2、没有同意过的和同意过的用户信息怎么存储
3、如何高效的查询是否同意过
4、怎么保证高并发下服务的可用性,数据库的可用性

功能实现

后端提供两个接口,
1、hasAgree(),查询该用户是否已同意协议
2、recordAgree(),记录用户已同意协议

第一版 Just DB

很容易嘛!不就是CRUD吗,小意思。用户进来先查数据库有没有记录,没有返回用户没有同意过协议,前端给用户展示协议页,否则展示功能页;用户点同意后,后台记录用户已点了同意协议,记录到库。一个查询一个插入,5分钟搞定嘛。

[需求设计]从一个小需求感受Redis的独特魅力


[需求设计]从一个小需求感受Redis的独特魅力


直接甩代码

[需求设计]从一个小需求感受Redis的独特魅力


[需求设计]从一个小需求感受Redis的独特魅力


第一版代码如上,我觉得刚入门的程序员都能够写出来。如果用户量不大,该功能的点击量不大的话,这么做还是勉强说得过去。为什么说勉强说得过去,因为存在隐患,你看啊如果每次点击都会去查库,假如有人恶意攻击,仿造高并发,瞬时大量请求过来都去查库,很可能数据库顶不住就挂了。或者就算数据库没挂,每次查库也都是浪费啊。所以这是个隐患,或者潜在的危险,那么第二版我们就去解决这个问题。

 

第二版 引入Redis缓存

考虑到每次查库很浪费,那我们使用缓存好不好?
进来先查缓存有没有对应的数据,缓存里有就直接返回,没有则查库,库里有就存缓存。这样redis就分担了一部分数据库的压力。

[需求设计]从一个小需求感受Redis的独特魅力


代码呈上

[需求设计]从一个小需求感受Redis的独特魅力


[需求设计]从一个小需求感受Redis的独特魅力


这一版好一点了,部分请求分摊到redis了,减轻了数据库的压力。

 

第三版 解决缓存穿透

随着客户量的增加,点击这个功能的次数、频率越来越高,假如有人频繁点击该功能,弹出协议后,退出,再点,再退出…就是不点确定

[需求设计]从一个小需求感受Redis的独特魅力


这样会有啥问题?

 

这样的话后台缓存中没有,数据库中也没有,每次都会走数据库,绕过了缓存,直接都走数据库,这类请求量多了也是个问题,这就是缓存穿透。所以第三版,我们来解决缓存穿透的问题。

[需求设计]从一个小需求感受Redis的独特魅力


解决缓存穿透:
因为是数据库和缓存都没有,我们可以让数据库没有的也存到redis。需要改变redis的数据类型,由set改为map,目的是记录状态值。

[需求设计]从一个小需求感受Redis的独特魅力


[需求设计]从一个小需求感受Redis的独特魅力


可以看到,我们的这个key-field-value没有设置过期时间,因为可以认为这个key是一个热点key,对于热点key我们的处理方式是,永久有效或过期时间尽量长一点。

 

第四版 缓存预热防止缓存击穿

另一个关于缓存的问题,那就是缓存击穿。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wpyyzw.html