redis 缓存问题,转载:https://www.cnblogs.com/liangsonghua/p/www_liangsonghua_me_22.html
缓存穿透:【缓存和数据库中都没有这个数】
缓存穿透是指查询一个一定不存在的数据,由于缓存是不命中时被动写的,并且处于容错考虑,如果从存储层查不到数据则不写入缓存,这将导致这个不存在的数据每次请求都要到存储层去查询,失去了缓存的意义。在流量大时,可能DB就挂掉了,要是有人利用不存在的key频繁攻击我们的应用,这就是漏洞。
解决办法:
有很多种方法可以有效地解决缓存穿透问题,最常见的则是采用布隆1) 过滤器,将所有可能存在的数据哈希到一个足够大的bitmap中,一个一定不存在的数据会被 这个bitmap拦截掉,从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法(我们采用的就是这种),如果一个查询返回的数据为空(不管是数 据不存在,还是系统故障),我们2) 仍然把这个空结果进行缓存,但它的过期时间会很短,最长不超过五分钟。
缓存雪崩 【同一时刻过期或缓存层挂掉】
缓存雪崩是指在我们设置缓存时采用了相同的过期时间,导致缓存在某一时刻同时失效,请求全部转发到DB,DB瞬时压力过大雪崩。
解决方案:
缓存失效时的雪崩效应对底层系统的冲击非常可怕。大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线 程(进程)写,从而避免失效时大量的并发请求落到底层存储系统上。这里分享一个简单方案就时讲缓存失效时间分散开,比如我们可以1) 在原有的失效时间基础上增加一个随机值,比如1-5分钟随机,这样每一个缓存的过期时间的重复率就会降低,就很难引发集体失效的事件。
缓存击穿
某个极度“热点”数据在某个时间点过期时,导致后端DB压力急剧上升。
对于一些设置了过期时间的key,如果这些key可能会在某些时间点被超高并发地访问,是一种非常“热点”的数据。这个时候,需要考虑一个问题:缓存被“击穿”的问题,这个和缓存雪崩的区别在于这里针对某一key缓存,前者则是很多key。
缓存在某个时间点过期的时候,恰好在这个时间点对这个Key有大量的并发请求过来,这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存,这个时候大并发的请求可能会瞬间把后端DB压垮。
解决办法
- 使用互斥锁:感知到缓存失效,去查询DB时,使用分布式锁,使得只有一个线程去数据库加载数据,加锁失败的线程,等待即可。
- 手动过期:redis上从不设置过期时间,功能上将过期时间存在key对应的value里,如果发现要过期,通过一个后台的异步线程进行缓存的构建,也就是“手动”过期【为每个value设置一个逻辑过期时间, 当发现超过逻辑过期时间后, 会使用单独的线程去构建缓存。】
- 是
无底洞问题:(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 高一致性业务可以结合使用超时剔除和主动更新, 这样即使主动更新出了问题, 也能保证数据过期时间后删除脏数据。