Redis使用bitmap、zset、hash、list等结构完成骚操作？

Redis常用的结构是string、Hash但是它提供了一些其他的结构，这些结构可以助我们完成各种操作。

1. zset结构

zSet底层结构.png

当同时满足以下条件时，使用ziplist编码：

• 元素数量小于128；
• 所有member长度都小于64字节；

常用命令	作用
zadd(key,score,member)	向名称key的zset中添加元素member，score用于排序。如果元素存在，根据score更新元素顺序
zrange(key,start,end)	返回名称为key的zset（元素已按score从大到小排序）中index从start到end所有元素
zrangebyscore(key, min, max)	返回名称为key的zset中score>=min且score<=max的所有元素

1.1 n秒内完成m次报警

SpringBoot—实现n秒内出现x个异常报警

思路：
借助Redis的zSet集合，score存储的是异常时的时间戳，获取一定时间范围内的set集合。判断set个数是否满足条件，若满足条件则触发报警；

注意点：

1. 防止重复报警：加分布式锁，实现互斥，线程触发报警后，清空Redis；
2. 防止去重：因为使用zSet存储，需要防止数据结构自带去重逻辑；

相关API：

• score：当前时间戳；
• zadd(key,异常信息,score)； 将数据放入到zset中
• zrangebyscore(key,5分钟前时间戳,当前时间戳)； 获取过去5分钟内的范围数据，判断是否触发个数。
• del(key)；设置zset的失效时间；

1.2 实现延迟队列

Redis实现延迟队列方法介绍
基于Redis实现DelayQueue延迟队列设计方案

延迟队列.png

1. hash维护消息的数据结构；
2. zset做优先队列，按照score（执行时间戳）维护优先级；
3. 定时器定时拉取zset里面查找score比当前时间小元素，将这些消息删除；
4. 解析消息的topic是什么，然后将任务push到topic对应的list结构中；
5. 线程池去开启worker线程去list中拉取数据，拉取到消息后，去hash中找到数据结构，于是调用监听方法。

相关API：

• score：执行时间戳；
• zset查找zrangebyscore(key,10s前时间戳,当前时间戳)；得到待消费的消息；
• list的blpop、brpop是天然阻塞的，worker线程可以调用该方法去list拉取消息。

2. bitmap结构

常用命令	作用
setbit key offset value	指定偏移量（offset）原来存储的值，value是0/1
getbit key offset	返回指定key上的偏移量，若key不存在，则返回0

2.1 实现布隆过滤器

SpringBoot2.x—使用Redis的bitmap实现布隆过滤器（Guava中BF算法）

布隆过滤器：是专门用来检测集合中是否存在特定元素的数据结构。
存在误差率：即将不在集合的元素误判在集合中。

为什么存储误差率

1. bitmap需要计算value的偏移量，需要使用hash计算出值，hash存在哈希冲突。
2. 为了防止偏移量过大，故采取将一个值计算出一组偏移量，将一组偏移量均置为1，也会导致将不存在集合的元素误判在集合中。

布隆过滤器使用场景

所以布隆过滤器适合查询准确度要求没这么苛刻，但是对时间、空间效率比较高的场景。

布隆过滤器实现方式

实现方式：Redis实现布隆过滤器——借鉴Guava的BF算法：

• 插入：将一个value计算为一组偏移量，将这一组偏移量下标设置为1；
• 取出：将一个value计算为一组偏移量，判断这一组偏移量下标是否均为1；

2.1 计算日活、月活、留存率的具体方法

SpringBoot2.x中使用Redis的bitmap结构（工具类）

1. 一亿个用户，有的用户频繁登录，也有不经常登录的。
2. 如何记录用户的登录信息？
3. 如何查询活跃用户？[如一周内 登录三次的]

注意：bitmap使用存在风险，若仅仅计算hash值，会导致bitmap占用空间过大。一般需要对hash值进行取余处理。

本地单点redis:0>setbit my:xxx 2000000001 1
"0"
本地单点redis:0>memory usage my:xxx
"251052088"
本地单点redis:0>del my:xxx
"1"
本地单点redis:0>setbit my:xxx 1000001 1
"0"
本地单点redis:0>memory usage my:xxx
"127032"

3. hash结构

3.1 实现分布式锁

1. 完成锁最基本的互斥功能

根据Redis是否存在key，判断锁是否被获取；

2. 选择一个合适的数据结构

锁应该是一个对象，记录持有锁的线程信息、当前重入次数。所以应该使用Redis的Hash结构来存储锁对象。

3. 需要考虑异常情况

3.1 网络波动造成释放锁失败怎么解决？

需要为锁加上超时时间；

3.2 任务未执行完毕时，锁由于超时时间被释放？

线程一旦加锁成功，可以启动一个后台线程，每隔多少秒检查一次，如果线程还持有锁，可以不断延长锁的生存时间。

4. 可能存在的缺陷？

主从切换时，从服务器上没有加锁信息，导致多个客户端同时加锁。

4. list结构

4.1 维护分布式缓存

list结构底层是ziplist/quicklist（可看着一个双端队列）。常用命令：

常用命令.png

使用list作为对象的缓存池。通过rpush放入对象，通过lpop取出对象。

若是阻塞取，可以使用blpop命令实现。

4.2 实现令牌桶限流

Redis和Lua脚本(实现令牌桶限流)

数据结构选择hash。
hash里面维护：最后放入令牌时间、当前桶内令牌量、桶内最大数量、令牌放置速度（元数据）。

获取令牌算法.png

被动式维护：

1. hash维护令牌桶元数据；
2. 当用户请求到达时，第一步是根据（当前时间-最后最后一次令牌生成时间）/1000* 每秒生成令牌速度—生成令牌；
3. 将令牌放入桶中，若满了则溢出来；
4. 请求取出令牌；
5. 若请求获取到令牌，则放行用户请求；

5. String结构

5.1 固定窗口计数器限流

命令：incr原子累加；

对一段固定时间窗口内的请求进行计数，如果请求数超过了阈值，则舍弃该请求；如果没有达到设定的阈值，则接受该请求，且计数加1。当窗口时间结束，重置计数器为0。

优点：实现简单，容易理解；
缺点：流量曲线可能不够平滑，有“突刺现象”。

1. 一段时间内（不超过时间窗口）系统服务不可用。比如窗口大小1s，限流为100，恰好某个窗口第1ms来了100个请求，然后2ms-999ms请求都会被拒绝。这段时间用户会感觉系统服务不可用（即不够平滑）。

2. 窗口切换时可能会出现两倍于阈值流量的请求。比如窗口大小1s，限流大小100，然后在某个窗口的第999ms有100个请求，窗口前期没有请求。所以这100个请求都会通过。然后下一个窗口的第1ms又来100个请求，然后全部通过。其实也是1ms内通过的200个请求。

固定窗口计数器.png

5.2 滑动窗口计数器

命令：Redis的incr命令

是对固定窗口计数器的优化，解决的是切换窗口两倍阈值流量的场景。

具体解决方案是：将限流窗口分为多个小的限流窗口，各个限流窗口分别计数。当前时间大于窗口最大时间时，将头部的小窗口数据舍弃，尾部新增小窗口来处理新请求。

滑动窗口算法.png

优点：本质上是对固定窗口的优化

1. 解决固定窗口算法切换窗口时2倍阈值的场景；
2. 解决“漏桶算法”不能应对突发流量的场景；