当同时满足以下条件时，使用ziplist编码：
SpringBoot—实现n秒内出现x个异常报警
思路：
借助Redis的zSet集合，score存储的是异常时的时间戳，获取一定时间范围内的set集合。判断set个数是否满足条件，若满足条件则触发报警；
注意点：
相关API：
Redis实现延迟队列方法介绍
基于Redis实现DelayQueue延迟队列设计方案
相关API：
SpringBoot2.x—使用Redis的bitmap实现布隆过滤器（Guava中BF算法）
布隆过滤器： 是专门用来检测集合中是否存在特定元素的数据结构。
存在误差率： 即将不在集合的元素误判在集合中。
所以布隆过滤器适合查询准确度要求没这么苛刻，但是对时间、空间效率比较高的场景。
实现方式：Redis实现布隆过滤器——借鉴Guava的BF算法：
SpringBoot2.x中使用Redis的bitmap结构（工具类）
注意：bitmap使用存在风险，若仅仅计算hash值，会导致bitmap占用空间过大。一般需要对hash值进行取余处理。
根据Redis是否存在key，判断锁是否被获取；
锁应该是一个对象，记录持有锁的线程信息、当前重入次数。所以应该使用Redis的Hash结构来存储锁对象。
3.1 网络波动造成释放锁失败怎么解决？
需要为锁加上超时时间；
3.2 任务未执行完毕时，锁由于超时时间被释放？
线程一旦加锁成功，可以启动一个后台线程，每隔多少秒检查一次，如果线程还持有锁，可以不断延长锁的生存时间。
主从切换时，从服务器上没有加锁信息，导致多个客户端同时加锁。
list结构底层是ziplist/quicklist（可看着一个双端队列）。常用命令：
使用list作为对象的缓存池。通过rpush放入对象，通过lpop取出对象。
若是阻塞取，可以使用blpop命令实现。
Redis和Lua脚本(实现令牌桶限流)
数据结构选择hash。
hash里面维护：最后放入令牌时间、当前桶内令牌量、桶内最大数量、令牌放置速度（元数据）。
被动式维护：
命令：incr原子累加；
对一段固定时间窗口内的请求进行计数，如果请求数超过了阈值，则舍弃该请求；如果没有达到设定的阈值，则接受该请求，且计数加1。当窗口时间结束，重置计数器为0。
优点：实现简单，容易理解；
缺点：流量曲线可能不够平滑，有“突刺现象”。
1. 一段时间内（不超过时间窗口）系统服务不可用。 比如窗口大小1s，限流为100，恰好某个窗口第1ms来了100个请求，然后2ms-999ms请求都会被拒绝。这段时间用户会感觉系统服务不可用（即不够平滑）。
2. 窗口切换时可能会出现两倍于阈值流量的请求。 比如窗口大小1s，限流大小100，然后在某个窗口的第999ms有100个请求，窗口前期没有请求。所以这100个请求都会通过。然后下一个窗口的第1ms又来100个请求，然后全部通过。其实也是1ms内通过的200个请求。
命令：Redis的incr命令
是对固定窗口计数器的优化，解决的是切换窗口两倍阈值流量的场景。
具体解决方案是：将限流窗口分为多个小的限流窗口，各个限流窗口分别计数。当前时间大于窗口最大时间时，将头部的小窗口数据舍弃，尾部新增小窗口来处理新请求。
优点：本质上是对固定窗口的优化