redis的应用
1、分布式锁
2、redis队列
ack/bak队列的作用，从即时队列取出消息处理之前先将消息备份一份到ack/bak队列，如果消息的消费者能够正常处理，不管是正常业务处理亦或出了异常被捕获，均认为消息被正常消费，此时移除ack/bak的消息；如果因为一些不可预知的问题例如服务器突然断电或者宕机，不知道消息是否被正常消费，此时ack/bak队列依旧有备份，下次应用重启之后会将ack/bak队列中的消息全部回放，交给消费者重新处理，确保此种异常场景下，消息不会丢失.
3、位图
4、HyperLogLog
4.1、原理
优秀的基数统计算法——HyperLogLog 这个帖子比较浅显，可能也不一定全对
4.2、适用场景
- UV统计
5、布隆过滤器
5.1、原理
布隆过滤器可以理解为将一个字符串，通过计算多个hash值，存在二进制位图中，来标记此字符串是否存在。众所周知，hash值存在hash冲突，同一个hash值，可能来自于不同的字符串；布隆过滤器的思想也比较朴素，一个误差大，那就多搞几个hash值，来降低碰撞的误差，但是并不能完全避免误差。所以布隆过滤器中的存在是可能存在，不存在那是一定不存在。
布隆过滤器的优势：兼顾了存储空间效率（因为使用了位图，比较省空间）和查询效率
5.2、适用场景
- 风控中黑名单过滤
- 避免给用户推荐已读的文章
……等等需要判重的场景均可以使用
HyperLogLog 与 布隆过滤器的差别
hyperloglog 只提供了三个命令pfadd、pfcount、pfmerge三个命令，如果想知道某个key是否存在，则没有办法，布隆过滤器变通下可以做到；
总结下：
- HyperLogLog适用于基数统计，例如UV统计
- 布隆过滤器适用于快速判断是否存在于某个集合中，例如防止重复提交，非法用户判断等
6、简单滑动窗口限流
6.1、实现
基于redis sorted set实现
// 记录请求时间
redis > ZADD key 请求时间戳 1
// 移除滑动窗口(例如1秒)之外的记录数
redis > ZREMRANGEBYSCORE key (now - 1000) now
// 统计集合剩余记录数
redis > ZCARD KEY
6.2、适用场景
redis的简单滑动窗口比较简单，通过sorted set记录实现，也因为此，不适合并发量很大的场景，会导致集合中记录过多，拖慢redis性能。如果是对于小并发的系统还是可以用的，或者需要和其他限流手段组合适用
7、令牌桶限流
7.1、原理
令牌桶的原理比较简单：
- 令牌桶以恒定速率生产令牌放入桶中。
- 当请求到达时，如果桶中有足够的令牌，请求放行，同时消耗一个令牌；如果桶中没有足够的令牌，拒绝请求或者排队等待；
- 令牌桶拥有容量上限，如果生产的令牌超过上限，则丢弃超出令牌
7.2、适用场景
限流（防护自己的系统），允许一定量的流量激增
7.3、实现
8、漏桶限流
8.1、原理
漏桶的原理：
- 设置一个固定容量的桶，以固定速率消费请求，如果桶满则拒绝请求，以达到平滑消费请求的目的
8.2、适用场景
限流(主要用在防护别人的系统)，均匀地请求外部系统。超出能力上限就拒绝访问
