从一个小需求感受Redis的独特魅力分享一个简单的小需求应该怎

分享一个简单的小需求应该怎么设计实现以及有关Redis的使用
Redis在实际应用中使用的非常广泛，本篇文章就从一个简单的需求说起，为你讲述一个需求是如何从头到尾开始做的，又是如何一步步完善的。
需求设定，现在我们有一个APP ，产品新提出一个叫“程序员树洞”的功能，具体功能就不说了，其中这个功能有一点需要做的是在使用该功能时，如果是首次进入会展示一个协议页面，用户需要勾选后点确定才能进入功能，此后再进该功能，不再显示协议页直接进入该功能。如下图所示，
文章插图
原型图
需求分析需求就是这么的简单，我们来分析一下。 1、用户点击该功能时前端需要知道该给用户显示哪个页面，这一步需要请求后端接口，后台告诉前端这个用户有没有同意过协议。 2、用户勾选协议点确定，后端需要记录这步操作(记录用户已经同意协议) ，这一步需在点确定时前端请求后端接口。
概要设计
前面需求分析里说了，后端需要告诉前端用户有没有统一过协议，所以后端需要把这个信息记录下来，最好是记录到数据库保存，那就需要一张表来记录同意过协议的用户。表结构大致是：id ，客户号，插入时间。
详细设计
1、记录客户是否已同意过协议并提供查询功能（查询是否同意过协议）2、没有同意过的和同意过的用户信息怎么存储3、如何高效的查询是否同意过4、怎么保证高并发下服务的可用性，数据库的可用性
功能实现
后端提供两个接口， 1、hasAgree() ，查询该用户是否已同意协议2、recordAgree() ，记录用户已同意协议
第一版 Just DB
很容易嘛！不就是CRUD吗，小意思。用户进来先查数据库有没有记录，没有返回用户没有同意过协议，前端给用户展示协议页，否则展示功能页；用户点同意后，后台记录用户已点了同意协议，记录到库。一个查询一个插入， 5分钟搞定嘛。
文章插图
文章插图
直接甩代码
文章插图
文章插图
第一版代码如上，我觉得刚入门的程序员都能够写出来。如果用户量不大，该功能的点击量不大的话，这么做还是勉强说得过去。为什么说勉强说得过去，因为存在隐患，你看啊如果每次点击都会去查库，假如有人恶意攻击，仿造高并发，瞬时大量请求过来都去查库，很可能数据库顶不住就挂了。或者就算数据库没挂，每次查库也都是浪费啊。所以这是个隐患，或者潜在的危险，那么第二版我们就去解决这个问题。
第二版引入Redis缓存
考虑到每次查库很浪费，那我们使用缓存好不好?进来先查缓存有没有对应的数据，缓存里有就直接返回，没有则查库，库里有就存缓存。这样redis就分担了一部分数据库的压力。
文章插图
代码呈上
文章插图
文章插图
这一版好一点了，部分请求分摊到redis了，减轻了数据库的压力。
第三版解决缓存穿透
随着客户量的增加，点击这个功能的次数、频率越来越高，假如有人频繁点击该功能，弹出协议后，退出，再点，再退出…就是不点确定
文章插图
这样会有啥问题？
这样的话后台缓存中没有，数据库中也没有，每次都会走数据库，绕过了缓存，直接都走数据库，这类请求量多了也是个问题，这就是缓存穿透。所以第三版，我们来解决缓存穿透的问题。
文章插图
解决缓存穿透：因为是数据库和缓存都没有，我们可以让数据库没有的也存到redis 。需要改变redis的数据类型，由set改为map ，目的是记录状态值。
文章插图