Redis常用的结构是string、Hash但是它提供了一些其他的结构，这些结构可以助我们完成各种操作。
1. zset结构
当同时满足以下条件时，使用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次报警
思路：
借助Redis的zSet集合，score存储的是异常时的时间戳，获取一定时间范围内的set集合。判断set个数是否满足条件，若满足条件则触发报警；
注意点：
- 防止重复报警：加分布式锁，实现互斥，线程触发报警后，清空Redis；
- 防止去重：因为使用zSet存储，需要防止数据结构自带去重逻辑；
相关API：
- score：当前时间戳；
- zadd(key,异常信息,score)； 将数据放入到zset中
- zrangebyscore(key,5分钟前时间戳,当前时间戳)； 获取过去5分钟内的范围数据，判断是否触发个数。
- del(key)；设置zset的失效时间；
1.2 实现延迟队列
Redis实现延迟队列方法介绍
基于Redis实现DelayQueue延迟队列设计方案
- hash维护消息的数据结构；
- zset做优先队列，按照score（执行时间戳）维护优先级；
- 定时器定时拉取zset里面查找score比当前时间小元素，将这些消息删除；
- 解析消息的topic是什么，然后将任务push到topic对应的list结构中；
- 线程池去开启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算法）
布隆过滤器：是专门用来检测集合中是否存在特定元素的数据结构。
存在误差率：即将不在集合的元素误判在集合中。
为什么存储误差率
- bitmap需要计算value的偏移量，需要使用hash计算出值，hash存在哈希冲突。
- 为了防止偏移量过大，故采取将一个值计算出一组偏移量，将一组偏移量均置为1，也会导致将不存在集合的元素误判在集合中。
布隆过滤器使用场景
所以布隆过滤器适合查询准确度要求没这么苛刻，但是对时间、空间效率比较高的场景。
布隆过滤器实现方式
实现方式：Redis实现布隆过滤器——借鉴Guava的BF算法：
- 插入：将一个value计算为一组偏移量，将这一组偏移量下标设置为1；
- 取出：将一个value计算为一组偏移量，判断这一组偏移量下标是否均为1；
2.1 计算日活、月活、留存率的具体方法
SpringBoot2.x中使用Redis的bitmap结构（工具类）
- 一亿个用户，有的用户频繁登录，也有不经常登录的。
- 如何记录用户的登录信息？
- 如何查询活跃用户？[如一周内 登录三次的]
注意：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 实现分布式锁
- 完成锁最基本的互斥功能
根据Redis是否存在key，判断锁是否被获取；
- 选择一个合适的数据结构
锁应该是一个对象，记录持有锁的线程信息、当前重入次数。所以应该使用Redis的Hash结构来存储锁对象。
- 需要考虑异常情况
3.1 网络波动造成释放锁失败怎么解决？
需要为锁加上超时时间；
3.2 任务未执行完毕时，锁由于超时时间被释放？
线程一旦加锁成功，可以启动一个后台线程，每隔多少秒检查一次，如果线程还持有锁，可以不断延长锁的生存时间。
- 可能存在的缺陷？
主从切换时，从服务器上没有加锁信息，导致多个客户端同时加锁。
4. list结构
4.1 维护分布式缓存
list结构底层是ziplist/quicklist（可看着一个双端队列）。常用命令：
使用list作为对象的缓存池。通过rpush放入对象，通过lpop取出对象。
若是阻塞取，可以使用blpop命令实现。
4.2 实现令牌桶限流
数据结构选择hash。
hash里面维护：最后放入令牌时间、当前桶内令牌量、桶内最大数量、令牌放置速度（元数据）。
被动式维护：
- hash维护令牌桶元数据；
- 当用户请求到达时，第一步是根据（当前时间-最后最后一次令牌生成时间）/1000* 每秒生成令牌速度—生成令牌；
- 将令牌放入桶中，若满了则溢出来；
- 请求取出令牌；
- 若请求获取到令牌，则放行用户请求；
5. String结构
5.1 固定窗口计数器限流
命令：incr原子累加；
对一段固定时间窗口内的请求进行计数，如果请求数超过了阈值，则舍弃该请求；如果没有达到设定的阈值，则接受该请求，且计数加1。当窗口时间结束，重置计数器为0。
优点：实现简单，容易理解；
缺点：流量曲线可能不够平滑，有“突刺现象”。
1. 一段时间内（不超过时间窗口）系统服务不可用。比如窗口大小1s，限流为100，恰好某个窗口第1ms来了100个请求，然后2ms-999ms请求都会被拒绝。这段时间用户会感觉系统服务不可用（即不够平滑）。
2. 窗口切换时可能会出现两倍于阈值流量的请求。比如窗口大小1s，限流大小100，然后在某个窗口的第999ms有100个请求，窗口前期没有请求。所以这100个请求都会通过。然后下一个窗口的第1ms又来100个请求，然后全部通过。其实也是1ms内通过的200个请求。
5.2 滑动窗口计数器
命令：Redis的incr命令
是对固定窗口计数器的优化，解决的是切换窗口两倍阈值流量的场景。
具体解决方案是：将限流窗口分为多个小的限流窗口，各个限流窗口分别计数。当前时间大于窗口最大时间时，将头部的小窗口数据舍弃，尾部新增小窗口来处理新请求。
优点：本质上是对固定窗口的优化
- 解决固定窗口算法切换窗口时2倍阈值的场景；
- 解决“漏桶算法”不能应对突发流量的场景；
