redis 缓存问题，转载：https://www.cnblogs.com/liangsonghua/p/www_liangsonghua_me_22.html

缓存穿透：【缓存和数据库中都没有这个数】

缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且处于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。

 

解决办法：

有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆1) 过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法（我们采用的就是这种），如果一个查询返回的数据为空（不管是数 据不存在，还是系统故障），我们2) 仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

 3)做好参数校验，不合法的key直接return 

 

缓存雪崩 【同一时刻过期或缓存层挂掉】

缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过大雪崩。

 

解决方案：

缓存失效时的雪崩效应对底层系统的冲击非常可怕。大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线 程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上。这里分享一个简单方案就时讲缓存失效时间分散开，比如我们可以1） 在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

2）或者 不给热点数据加过期时间，有更新操作就更新缓存 3）redis搞成集群，从而缓存层高可用  4）限流并降级，如个性推荐数据不可用就改用热点数据

缓存击穿

某个极度“热点”数据在某个时间点过期时，导致后端DB压力急剧上升。

对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题，这个和缓存雪崩的区别在于这里针对某一key缓存，前者则是很多key。

缓存在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

解决办法

1. 使用互斥锁：感知到缓存失效，去查询DB时，使用分布式锁，使得只有一个线程去数据库加载数据，加锁失败的线程，等待即可。
2. 手动过期：redis上从不设置过期时间，功能上将过期时间存在key对应的value里，如果发现要过期，通过一个后台的异步线程进行缓存的构建，也就是“手动”过期【为每个value设置一个逻辑过期时间， 当发现超过逻辑过期时间后， 会使用单独的线程去构建缓存。】
3. 是

无底洞问题：（redis集群场景下才有此问题）客户端一次批量操作会涉及多次网络操作， 也就意味着批量操作会随着节点的增多， 耗时会不断增大
解决方案1：强制将相关的多个key分配到一个节点上
解决方案2：根据key算出散列值，根据散列值得到对应的节点，key按所属的节点分组，每组都可以通过mget或pipline执行

Redis 面试知识点总结：https://mp.weixin.qq.com/s/bHeTlrCeM-MXvcr2xcV0ow   

Redis 是单线程的，为什么还能这么快?

答：1）基于内存  2）单线程，没有多线程的CPU切换  3)多路复用IO，非阻塞IO  4）数据结构简单

当 Redis 重启的时候，它会优先使用 AOF 文件来还原数据集，因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整；RDB 恢复数据集的速度也要比 AOF 恢复的速度快。

当 Redis 需要做持久化时，Redis 会 fork 一个子进程，子进程将数据写到磁盘上一个临时 RDB 文件中

RDB 的缺点是：如果你需要尽量避免在服务器故障时丢失数据，那么RDB不合适你

AOF 的缺点：对于相同的数据集来说，AOF 的文件体积通常要大于 RDB 文件的体积。根据所使用的 Fsync 策略，AOF 的速度可能会慢于 RDB（AOF 将 Redis 执行的每一条命令追加到磁盘中，处理巨大的写入会降低Redis的性能）

https://mp.weixin.qq.com/s/I3tu8-kYaA6ULuOxTtgNug
链接中提到的一些优秀实践：
1 当这个hash结构的内层field-value数量不超过512，并且value的字节数不超过64时，就使用zipList

2 zipList要比hashTable占用少的多的空间。但是会耗费更多的cpu来进行查询。

3 采用高效而且均衡的知名算法crc32，该哈希算法可以将一个字符串变成一个long型的数字

4 如果key的长短不一，譬如有些40位，有些10位，因为对齐问题，那么将产生巨大的内存碎片，占用空间情况更为严重。所以，保持key的长度统一（譬如统一采用int型，定长8个字节），也会对内存占用有帮助。
5 string型的md5，占用了32个字节。而通过hash算法后，将32降到了8个字节的长整形，这显著降低了key的空间占用

6 如果value是字符串、对象等，应尽量采用byte[]来存储，同样可以大幅降低内存占用。譬如可以选用google的Snappy压缩算法，将字符串转为byte[]，非常高效，压缩率也很高。

7 为减少redis对字符串的预分配和扩容（每次翻倍），造成内存碎片，不应该使用append，setrange等。而是直接用set，替换原来的。

1 redis支持并发 10W QPS【QPS:每秒查询率】

2 redis的String 类型是二进制安全的，可以包含任何数据，比如 jpg 图片或者序列化的对象。String 类型的值最大能存储 512M。

3 Redis List 的是实现是一个双向链表，既可以支持反向查找和遍历；集合是通过 hashtable 实现的；
Redis Sorted Set 的内部使用 HashMap 和跳跃表（skipList）来保证数据的存储和有序，HashMap 里放的是成员到 Score 的映射；

4 Bitmaps： 在字符串数据结构上使用位操作

5 GEO： Redis3.2提供了基于地理位置信息的功能

6 如果要Redis将配置持久化到本地配置文件， 需要执行config rewrite命令

7 慢查询只记录命令执行时间， 并不包括命令排队和网络传输时间。 因此客户端执行命令的时间会大于命令实际执行时间。当客户端出现请求超时， 需要检
查该时间点是否有对应的慢查询， 从而分析出是否为慢查询导致的命令级联阻塞

为了防止慢查询日志丢失，可以定期执行slow get命令将慢查询日志持久化到其他存储中

8 每隔1秒输出内存的使用量， 一共输出100次：redis-cli -r 100 -i 1 info | grep used_memory_human

9 --bigkeys选项使用scan命令对Redis的键进行采样， 从中找到内存占用比较大的键值，这些键可能是系统的瓶颈

10 redis-cli的--pipe选项实际上就是使用Pipeline机制原生批量命令是原子的， Pipeline是非原子的
原生批量命令是一个命令对应多个key， Pipeline支持多个命令

Pipeline虽然好用， 但是每次Pipeline组装的命令个数不能没有节制，可以将一次包含大量命令的Pipeline拆分成多次
较小的Pipeline来完成

11 Bitmaps本身不是一种数据结构， 实际上它就是字符串 ， 但是它可以对字符串的位进行操作  setbit key offset value

12 很多应用的用户id以一个指定数字（例如10000） 开头， 直接将用户id和Bitmaps的偏移量对应势必会造成一定的浪费， 通常的做法是每次做setbit操作时将用户id减去这个指定数字

gitbit key offset

13 高一致性业务可以结合使用超时剔除和主动更新， 这样即使主动更新出了问题， 也能保证数据过期时间后删除脏数据。