这是我参与「第五届青训营 」笔记创作活动的第11天 上次记到redis在程序上面的应用，今天就是记录一下使用redis的注意事项，以及会出现的问题。
Redis使用注意事项
大key、热key
大key的问题：读取成本高、容易导致慢查询(过期、删除)、主从复制异常，服务阻塞、无法正常响应请求 尽量不用大key，如果无法避免：
1. 拆分： 存在的问题： 需要维护多个 key，才实现一个数据的读写。结构复杂，耗时。
2. 压缩：（优先考虑的问题） 将value压缩后写入redis，读取时解压后再使用。压缩算法可以是gzip、snappy、lz4等。通常情况下一个压缩算法压缩率高、!则解压耗时就长。需要对实际数据进行测试后，选择一个合适的算法如果存储的是JSON字符串，可以考虑使用MessagePack进行序列化。
集合类结构hash、list、 set、set
(1)拆分:可以用hash取余、位掩码的方式决定放在哪个key中
(2) 区分冷热: 如榜单列表场景使用zset，只缓存前10页数据，后续数据走db
热Key的定义
用户访问一个Key的QPS特别高，导致Server实例出现CPU负载突增或者不均的情况。热key没有明确的标准，QPS 超过500就有可能被识别为热Key
解决方案
- 设置Localcache（本机缓存）：不仅仅使用redis内存，在服务器也设置缓存，减轻redis的压力。LocalCache中缓存过期或未命中，从Redis中将数据更新到LocalCache
- Java的Guava、Golang的Bigcache就是这类LocalCache
- 将key:value这一个热Key复制写入多份，例如key1:value,key2:value，访问的时候访问多个key，但value是同一个，以此将qps分散到不同实例上降低负载。代价是：更新时需要更新多个key，存在数据短暂不一致的风险
缓存穿透、缓存雪崩
穿透：
热点数据查询绕过redis，直接访问数据库，数据量大就可能造成db崩溃
雪崩：
大量缓存同时过期，直接访问数据库
避免穿透：
(1)缓存空值 如一个不存在的userlD。这个id在缓存和数据库中都不存在。则可以缓存一个空值，下次再查缓存直接反空值
(2)布隆过滤器 通过bloom filter算法来存储合法Key，得益于该算法超高的压缩率，只需占用极小的空间就能存储大量key值
避免雪崩：
(1) 缓存空值 将缓存失效时间分散开，比如在原有的失效时间基础上增加一个随机值，例如不同Kev过期时间可以设置为 10分1秒过期，10分23秒过期，10分8秒过期。单位秒部分就是随机时间，这样过期时间就分散了对于热点数据，过期时间尽量设置得长一些，冷门的数据可以相对设置过期时间短一些。
(2) 使用缓存集群，避免单机宕机造成的缓存雪崩
