redis 热key、bigKey、布隆过滤器、pipeline

之前在用redis的时候只会觉得说有缓存真好，可以节省大量时间，但是从来没有想过redis可能会存在的问题。

在这里记录下最近自己遇到的以及听到的可能有问题的地方。

热Key

热点key是指瞬间有大量请求去访问同一个key，从而压垮缓存服务。会造成流量过于集中，达到物理网卡上限，从而导致所在redis服务器宕机。那么接下来，对于这个key的请求就不可用，可能会直接压到数据库。导致服务整体不可用。

发现热key的方式：

1. 凭借业务经验进行预估。问题在于并非所有的业务都能预估出哪些key是热key。
2. 在客户端进行收集。在操作redis之前，先进行数据统计。缺点在于会对客户端代码造成入侵。
3. 在Proxy层面进行收集，如果有统一proxy入口，可以在proxy上收集上报
4. 直接使用redis自带命令，monitor命令、hotkeys参数
5. 自己抓包评估

解决方案：

1. 利用二级缓存，利用本地缓存
2. 备份热key，把这个key在多台机器上都存一份

目前自己代码中用到的解决方案是对可能的热key进行预估，并且将这些数据存储到本地缓存中。之前一直是担心本地缓存占用内存过多，后来发现其实可以对需要本地缓存的数据进行一个预估，估计占用存储空间的大小。

https://www.jianshu.com/p/9a761a575daa

https://segmentfault.com/a/1190000017142556?utm_source=tag-newest 有赞透明多级缓存方案

https://www.cnblogs.com/williamjie/p/11250789.html

bigkey

bigkey可能造成的影响：

redis是单线程运行的，一次操作的value很大会对整个redis的响应时间造成负面影响。

这种情况下需要对bigkey进行拆分。

https://blog.csdn.net/beyond59241/article/details/78889867

https://blog.csdn.net/lavorange/article/details/83475960

想到之前的一种场景，需要对所有用户的积分进行排名，之前用到了zset，但是当用户数目上涨的时候，这个key也变成了一个bigkey，这个key在一周内有效，这里如何拆分还没有想到合适的方式。

布隆过滤器

布隆过滤器可以快速判断一个元素是否在集合中

https://blog.csdn.net/u011277123/article/details/88757861

http://www.xiaosongit.com/index/detail/id/627.html

https://yq.aliyun.com/articles/167466?spm=a2c4e.11153940.0.0.7d2b49c4bqtmn6

pipeline

一次性执行多条命令提升执行速度。

原生的批命令具有原子性，而pipeline不具备原子性

原生批命令对应的是一条命令，多个key。pipeline是多命令

原生批命令是服务端实现，pipeline需要服务端和客户端共同完成。

但是使用pipeline的时候也需要注意命令个数不应该太多，不然会导致数据量过大，增加客户端的等待时间，还可能造成网络拥堵。

https://blog.csdn.net/u011489043/article/details/78769428

https://blog.csdn.net/w1lgy/article/details/84455579