搜索引擎的 “查询词” 就是要关注的 “访问的数据”，通过日志，把每天（也可以按一周、一月）都使用到了哪些词，给记录下来，就可以针对这些日志进行统计（这里的统计数据量非常大，需要写个程序来统计，数量大到可能需要使用分布式系统来存储日志 HDFS），统计这一天中，每个词出现的频率，再根据频率降序排序，提取出前 20% 的词，就可以认为这些词是 “热点词” .

接下来就可以把这些热点词，以及涉及到的搜索结构都提前拎出来，放到类似 “ redis” 这样的缓存中了。

如何定期统计呢？

可以写一套离线流程（往往使用 shell，python 写脚本代码），然后通过定时任务来触发（一天更新一次、一个月更新一次......），具体的：

a）完成统计热词的过程.

b）根据热词，找到搜索结果的数据.

c）把得到缓存数据同步到缓存服务器上.

d）控制这些缓存服务器自动重启.

定期生成的优缺点

优点：实现起来比较简单，过程可控（缓存中有什么东西，是比较固定的），方便排查问题.

缺点：实时性不够，如果出现一些突发性的事件，出现了一些新的热点词，新的热词就可能对数据库带来较大的压力（缓存中查询没有，直接打到数据库），例如，过年的前几天，“春节晚会” 这个词就会变的特别高频、或者是某个突发的新闻......

1.3.2、实时生成

先给缓存设定容量上限（可以通过 Redis 配置⽂件的 maxmemory 参数设定）.

接着，之后用户每次查询：

如果在 Redis 中查到了，就直接返回.
如果 Redis 中没有，就从数据库查询，在把查到的结果写入 Redis.

经过一段时间的 “动态平衡” ，redis 中的 key 就逐渐变成了热点数据.

问题1：maxmemory 设置成多少合适？（以下来自于文心一言的建议）

小型项目：
- 对于内存需求较小的小型项目，通常可以将maxmemory设置为较低的值，例如100MB到500MB。这样的设置可以满足基本的缓存和存储需求，同时不会消耗过多的系统资源。
中型项目：
- 对于中型项目，可能需要处理更多的数据和请求，因此建议将maxmemory设置在500MB到2GB之间。这个范围可以提供足够的内存来支持更复杂的操作和数据存储。
大型项目：
- 对于大型项目，可能需要处理大量的数据和高并发的请求。在这种情况下，建议将maxmemory设置在2GB以上，甚至可以达到数十GB或更多。这样可以确保Redis能够有足够的内存来处理大量的数据和请求。

需要注意的是，maxmemory的设置应该根据项目的实际需求和可用系统资源来确定。在设置maxmemory时，还需要考虑Redis的持久化策略、数据淘汰策略以及内存交换等因素。同时，还需要监控Redis的内存使用情况，以便根据实际需求进行调整和优化。

另外，如果开启了Redis的快照功能（RDB或AOF），maxmemory的设置还需要考虑快照文件的大小和频率。为了确保系统的稳定性和性能，建议将maxmemory设置为物理内存的45%（如果开启了快照功能）或系统可用内存的95%（如果没有开启快照功能）。

问题2：但是这样不停的写，redis 中的数据就会越来越多，达到 redis 配置的容量上限之后怎么办？

内存淘汰策略（经典面试）

为了解决上述问题，就可以使用以下四种 “内存淘汰策略” （以下淘汰策略不局限于 redis）：

1. FIFO (First In First Out) ：先进先出

把缓存中存在时间最久的 (也就是先来的数据) 淘汰掉.

2. LRU (Least Recently Used) ：淘汰最久未使⽤的

记录每个 key 的最近访问时间. 把最近访问时间最⽼的 key 淘汰掉.

3. LFU (Least Frequently Used) ：淘汰访问次数最少的

记录每个 key 最近⼀段时间的访问次数. 把访问次数最少的淘汰掉

4. Random 随机淘汰

从所有的 key 中抽取幸运儿被随机淘汰掉

深入理解淘汰策略：

假如在甄嬛传中，你是那个皇上，后宫佳丽三千，但实际上，你能宠幸的妃子也就那么几个（精力有限），相当于热点数据.

今天选秀一批新的小主，而你看上了其中的一个，那么就意味着后宫必有人失宠，那么到底要冷落谁呢？

FIFO：皇后最老，先冷落了.

LRU：找个太监统计最近的宠幸时间，比如，皇后(10天前)、华妃（一个月前）、熹妃（一天前），那么华妃失宠.

LFU：找个太监统计最近的宠幸次数，比如，皇后（6次）、华妃（1次）、熹妃（10次），那么华妃失宠.

Random：随机冷落一个妃子.

redis 中采用的淘汰策略

volatile-ttl（相当于 FIFO, 只不过是局限于过期的 key）在设置了过期时间的key中，根据过期时间进行淘汰，越早过期的优先被淘汰.
volatile-lru（就是 LRU，只不过局限于过期的 key）当内存不足以容纳新写⼊数据时，从设置了过期时间的key中使⽤LRU（最近最少使用）算法进行淘汰.
allkeys-lru（就是 LRU，针对所有 key）当内存不⾜以容纳新写⼊数据时，从所有key中使⽤LRU（最近最少使用）算法进行淘汰
volatile-lfu（就是 LFU，只不过局限于过期的 key） 4.0版本新增，当内存不⾜以容纳新写⼊数据时，在过期的key中，使⽤LFU算法进行删除key.
allkeys-lfu（就是 LFU，针对所有 key） 4.0版本新增，当内存不⾜以容纳新写⼊数据时，从所有key中使⽤LFU算法进行淘汰.
volatile-random 当内存不⾜以容纳新写⼊数据时，从设置了过期时间的key中，随机淘汰数据.
allkeys-random 当内存不⾜以容纳新写⼊数据时，从所有key中随机淘汰数据.
noeviction 默认策略，当内存不⾜以容纳新写⼊数据时，新写⼊操作会报错.

1.3.3、redis 内存淘汰策略的特性

问题：假设有一天触发了内存淘汰机制，现在系统判定需要删除一个 set，那么到底是删除这整个 set 呢？还是删除这个 set 中的某些成员？

这里我们需要清除一点：Redis 不会单独去删除一个 set 数据结构中的部分成员来释放内存，而是直接删除整个 key-value 对。

如果你的 Redis 中存储了一个 set 数据结构，并且这个 key 被淘汰策略选中，那么整个 set（包括它的所有成员）都会被删除，而不是只删除 set 中的某些成员。

1.4、缓存使用的注意事项（重点）

1.4.1、缓存预热（Cache preheating）

这里主要针对缓存更新策略是实时生成的（定期生成不涉及 “预热” ）.

为什么要预热？

redis 服务器首次接入之后，服务器是没有数据的，此时所有请求都会直接打给 mysql，在 redis 上没查到，而在 mysql 上查到的数据会继续写入 redis，随着时间推移，redis 上的数据越积累越多 mysql 承担的压力才逐渐变小 .

那么没预热前，mysql 的压力是相当大的.

如何解决上述问题？

通过缓存预热，就可以解决. 主要就是，把缓存定期生成和实时生成结合一下.

具体的，先通过离线的方式，通过一些统计途径，统计一些热点数据，导入到 redis 中，此时导入的这批热点数据，就能帮 mysql 承担很大压力了.

随着时间的推移，逐渐就使用新的热点数据淘汰旧数据了.

1.4.2、缓存穿透（Cache penetration）

查询某个 key ，在 redis 中没有，mysql 中也没有，这个 key 也就不会更新到 redis 中。

这就导致，这次查询没有，下次查，还是没有....... 如果这样的数据很多，并且反复查询，一样会给 mysql 带来很大压力.

如何处理？

首先是一种亡羊补牢的方式：通过改进业务/加强监控警报，但这都是出现事故，才采取的行为.

更靠谱的方案（降低问题的严重性）：

1. 如果这个 key 在 redis 和 mysql 上都不存在，仍然把这个 key 写入 redis，value 设置成一个非法值，比如 "".

2. 引入布隆过滤器. 每次查询 redis / mysql 之前都先判定一下 key 是否在布隆过滤器上存在（布隆过滤器本质上是结合 hash + bitmap 实现的，以比较小的空间开销和比较快的速度，针对 key 是否存在进行判定），不存在就没必要查了.

1.4.3、缓存雪崩（Cache avalanche）

在短时间内，redis 中大规模的 key 失效，导致缓存命中率陡然下降，并且 mysql 的压力迅速上升，甚至直接宕机.

redis 上为什么会出现大规模的 key 失效？

1. redis 直接挂了，比如 redis 宕机，或者 redis 集群模式下大量节点宕机.

2. redis 好着呢，但是可能之前短时间内设置了很多相同过期时间的 key.

如何处理？

1) 加强监控警报，例如采取集群的监控，或者哨兵监控的方式，加强 redis 集群可用性.

2）不给 key 设置过期时间，或者设置过期时间的时候，添加一些随机因子，来避免同时过期.

1.4.4、缓存击穿（Cache breakdown）

这里翻译成 “击穿” 实际上不太合适，以至于一些面试官也分不清击穿和穿透（这种情况，最好两种都说明一下）.

这里更适合的翻译成 “瘫痪”.

缓存击穿相当于雪崩的特殊情况. 针对热点 key，如果过期了，导致大量请求直接访问到数据库上，甚至引起数据库宕机.

如何处理？

1. 基于统计的方式发现热点 key，设置为永不过期. 这种方式往往需要服务器结构做出比较大的调整.

2. 进行必要的服务降级（例如服务器的功能本来有 10 个，特定情况下，会关闭一些不重要的功能，只保留核心功能. 类似于手机的省电模式），例如访问数据库的时候使用分布式锁，限制数据库的访问频率.

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/知新_RL/article/detail/581286