使用Redis，你必须知道的21个注意要点

Tags

Top Highlights

• 使用布隆过滤器快速判断数据是否存在。即一个查询请求过来时，先通过布隆过滤器判断值是否存在，存在才继续往下查。

• 每次更新数据后，需要清除缓存

• 如果是String类型，单个value大小控制10k以内。 如果是hash、list、set、zset类型，元素个数一般不超过5000。

• 如果大量的key在某个时间点集中过期，到过期的那个时间点，Redis可能会存在卡顿，甚至出现缓存雪崩现象，因此一般不同业务的key，过期时间应该分散一些。有时候，同业务的，也可以在时间上加一个随机值，让过期时间分散一些。

• 如果哈希元素n比较多的话，可以优先考虑使用hscan。

• 但是它一般调试用而已，尽量不要在生产上用！因为monitor命令可能导致redis的内存持续飙升。

• Redis服务器在Monitor这个客户端的输出缓冲区又会有大量“存货”，也就占用了大量Redis内存。

• redis的keys是遍历匹配的，复杂度是O（n），数据库数据越多就越慢。我们知道，redis是单线程的，如果数据比较多的话，keys指令就会导致redis线程阻塞，线上服务也会停顿了，直到指令执行完，服务才会恢复

• 但是会有一定的重复概率，需要在客户端做一次去重。

• 因为在对键进行增量式迭代的过程中， 键可能会被修改， 所以增量式迭代命令只能对被返回的元素提供有限的保证 。

• 如果删除一个List/Hash/Set/ZSet类型时，它的复杂度是O(n), n表示元素个数。

• 如果是List类型，你可以执行lpop或者rpop，直到所有元素删除完成。 如果是Hash/Set/ZSet类型，你可以先执行hscan/sscan/scan查询，再执行hdel/srem/zrem依次删除每个元素。

• 执行复杂度较高的命令，会消耗更多的 CPU 资源，会阻塞主线程。所以你要避免执行如SORT、SINTER、SINTERSTORE、ZUNIONSTORE、ZINTERSTORE等聚合命令，一般建议把它放到客户端来执行。

• 正要执行expire设置过期时间时，进程crash或者要重启维护了，那么这个锁就“长生不老”了，别的线程永远获取不到锁啦

• 可能被别的客户端释放/解锁

• 一致性要求高的话，可以使用biglog+MQ保证。

• Redis集群扩容：增加分片副本，均衡读流量； 对热key进行hash散列，比如将一个key备份为key1,key2……keyN，同样的数据N个备份，N个备份分布到不同分片，访问时可随机访问N个备份中的一个，进一步分担读流量； 使用二级缓存，即JVM本地缓存,减少Redis的读请求。

• Redis Cluster 只支持 db0，要迁移的话，成本高

• 设置了过期时间的

• noeviction：默认策略，当内存不足以容纳新写入数据时，新写入操作会报错。