Redis应用场景举例

面对越来越多的高并发场景，限流显示的尤为重要。

限流

      当然，限流有许多种实现的方式，Redis具有很强大的功能，我用Redis实践了三种的实现方式，可以较为简单的实现其方式。Redis不仅仅是可以做限流，还可以做数据统计，附近的人等功能，这些可能会后续写到。

第一种：基于Redis的setnx的操作

      我们在使用Redis的分布式锁的时候，大家都知道是依靠了setnx的指令，在CAS（Compare and swap）的操作的时候，同时给指定的key设置了过期实践（expire），我们在限流的主要目的就是为了在单位时间内，有且仅有N数量的请求能够访问我的代码程序。所以依靠setnx可以很轻松的做到这方面的功能。

     比如我们需要在10秒内限定20个请求，那么我们在setnx的时候可以设置过期时间10，当请求的setnx数量达到20时候即达到了限流效果。代码比较简单就不做展示了。

   当然这种做法的弊端是很多的，比如当统计1-10秒的时候，无法统计2-11秒之内，如果需要统计N秒内的M个请求，那么我们的Redis中需要保持N个key等等问题

第二种：基于Redis的数据结构zset

     其实限流涉及的最主要的就是滑动窗口，上面也提到1-10怎么变成2-11。其实也就是起始值和末端值都各+1即可。

    而我们如果用Redis的list数据结构可以轻而易举的实现该功能

    我们可以将请求打造成一个zset数组，当每一次请求进来的时候，value保持唯一，可以用UUID生成，而score可以用当前时间戳表示，因为score我们可以用来计算当前时间戳之内有多少的请求数量。而zset数据结构也提供了range方法让我们可以很轻易的获取到2个时间戳内有多少请求

   
   上述可以做到滑动窗口的效果，并且能保证每N秒内至多M个请求，缺点就是zset的数据结构会越来越大。实现方式相对也是比较简单的。

第三种：基于Redis的令牌桶算法

    提到限流就不得不提到令牌桶算法了。具体可以参照度娘的解释  令牌桶算法

    令牌桶算法提及到输入速率和输出速率，当输出速率大于输入速率，那么就是超出流量限制了。

    也就是说我们每访问一次请求的时候，可以从Redis中获取一个令牌，如果拿到令牌了，那就说明没超出限制，而如果拿不到，则结果相反。

    依靠上述的思想，我们可以结合Redis的List数据结构很轻易的做到这样的代码，只是简单实现

    依靠List的leftPop来获取令牌
   再依靠定时任务，定时往List中rightPush令牌，当然令牌也需要唯一性，所以我这里还是用UUID进行了生成

统计UV

如果统计 PV，那非常好办，给每个网页配一个独立的 Redis 计数器就可以了，把这个计数器的 key后缀加上当天的日期。这样来一个请求，执行 incrby 指令一次，最终就可以统计出所有的 PV 数据。但是 UV 不一样，它要去重，同一个用户一天之内的多次访问请求只能计数一次。这就要求每一个网页请求都需要带上用户的 ID，无论是登录用户还是未登录用户都需要一个唯一 ID 来标识。你也许已经想到了一个简单的方案，那就是为每一个页面设置一个独立的 set 集合来存储所有当天访问过此页面的用户 ID。当一个请求过来时，我们使用 sadd 将用户 ID 塞进去就可以了。通过 scard可以取出这个集合的大小，这个数字就是这个页面的 UV 数据。没错，这是一个非常简单的可行方案。但是，如果你的页面访问量非常大，比如一个爆款页面可能有几千万个 UV，你就需要一个很大的set 集合来统计，这就非常浪费空间。如果这样的页面很多，那所需要的存储空间是惊人的。为这样一个去重功能就耗费这样多的存储空间，值得吗？其实老板所需要的数据并不需要太精确，105 万和106 万这两个数字对于老板来说并没有多大区别。
   

127.0.0.1:6379> pfadd uv a b c d a b c d
(integer) 1
127.0.0.1:6379> PFCOUNT uv
(integer) 4
#PFMERGE
redis> PFADD hll1 foo bar zap a
(integer) 1
redis> PFADD hll2 a b c foo
(integer) 1
redis> PFMERGE hll3 hll1 hll2
"OK"
redis> PFCOUNT hll3
(integer) 6

判重

可以把布隆过滤器理解为一个不怎么精确的 set 结构，当你使用它的 contains 方法判断某个对象是否存在时，它可能会误判。但是布隆过滤器也不是特别不精确，只要参数设置得合理，它的精确度也可以控制得相对足够精确，只会有小小的误判概率。当布隆过滤器说某个值存在时，这个值可能不存在；当它说某个值不存在时，那就肯定不存在。打个比方，当它说不认识你时，肯定就是真的不认识；而当它说认识你时，却有可能根本没见过你，只是因为你的脸跟它认识的某人的脸比较相似（某些熟脸的系数组合），所以误判以前认识你。套在上面的使用场景中，布隆过滤器能准确过滤掉那些用户已经看过的内容，那些用户没有看过的新内容，它也会过滤掉极小一部分（误判），但是绝大多数新内容它都能准确识别。这样就可以保证推荐给用户的内容都是无重复的。