使用 sortedset，使用时间戳做 score, 消息内容作为 key,调用 zadd 来生产消息，消费者
使用 zrangbyscore 获取 n 秒之前的数据做轮询处理。
redis取得当前时间戳
127.0.0.1:6379> time
1) "1578537098"
2) "732425"
127.0.0.1:6379> eval "local a=redis.call('time'); return a[1];" 0
"1578537115"
redis概念
缓存穿透、缓存击穿、缓存雪崩解决方案？
缓存穿透：指查询一个一定不存在的数据，如果从存储层查不到数据则不写入缓存，这将
导致这个不存在的数据每次请求都要到 DB 去查询，可能导致 DB 挂掉。
解决方案：
1.查询返回的数据为空，仍把这个空结果进行缓存，但过期时间会比较短；
2.布隆过滤器：将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定不存在的数据
会被这个 bitmap 拦截掉，从而避免了对 DB 的查询。
缓存击穿：对于设置了过期时间的 key，缓存在某个时间点过期的时候，恰好这时间点对
这个 Key 有大量的并发请求过来，这些请求发现缓存过期一般都会从后端 DB 加载数据并
回设到缓存，这个时候大并发的请求可能会瞬间把 DB 压垮。
解决方案：
1.使用互斥锁：当缓存失效时，不立即去 load db，先使用如 Redis 的 setnx 去设
置一个互斥锁，当操作成功返回时再进行 load db 的操作并回设缓存，否则重试 get 缓存的
方法。
2.永远不过期：物理不过期，但逻辑过期（后台异步线程去刷新）。
缓存雪崩：设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部
转发到 DB，DB 瞬时压力过重雪崩。与缓存击穿的区别：雪崩是很多 key，击穿是某一个
key 缓存。
解决方案：将缓存失效时间分散开，比如可以在原有的失效时间基础上增加一个随机值，
比如 1-5 分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效
的事件。
