Balance

所以，在实际工作中，一般会做实时的热点数据的检测。这里，参考下面链接。默认情况下，使用频率最低，则后期命中的概率也最低，所以，将其淘汰。因为，Redis本身不建议保存持久化数据，所以，只作为备选方案。所以，建议创建好实例后修改淘汰策略，减少 OOM 问题的出现。而且，我们更关心长期内经常访问的数据，那么LFU更适合。而且，在短期内访问频率较高，那么LRU更适合；该策略会将最近最少使用的Key淘汰。如果，业务场景中热点数据的。访问频率较高的热点数据。访问频率较高的热点数据。使用的时候，推荐使用。

表示存储了大量数据的 Key，表示 Key 的值很大，表示这个 Key 对应的 value 占用空间很多的情况。

将一个热 key 拆分成多个不那么热的 key，在每一个Key后面加一个后缀名，然后把这些key分散到多个实例中。并且，实时的将热点数据同步分发到多个缓存服务器集群中，一旦有的集群打不住了，立刻做切换。热点数据，如果，都被缓存在同一个缓存服务器上，那这个服务器也可能被打挂。这样，用户在查询<淄博烧烤>的时候，先根据用户ID算出一个下标，就是根据一些根据经验，提前的识别出可能成为热key的key，**确实是，**但是，有时候我们并不一定就需要全部的数据。总之，通过缓存的方式，尽量减少用户的访问链路的长度。

这种模式的主要方案就是，先写数据库，后删缓存。，可以选择**“先更新数据库，后删除缓存”**的方式，因为，这种方案更加简单。当应用要写入数据时，缓存会先存储数据，并调用写模块将数据写入数据库。这两种模式下，不需要应用自己去操作数据库，缓存自己就把活干完了。假如一个读线程，在读缓存的时候没查到值，他就会去数据库中查询。是由缓存配置一个读模块，它知道如何将数据库中的数据写入缓存。在数据被请求的时候，如果未命中，则将数据从数据库载入缓存。如果，在查询到结果之后，更新缓存之前，数据库被更新了。

这些请求可能随机生成很多Key来请求查询，这些肯定在缓存和数据库中都没有，那就很容易导致缓存穿透针对类似的情况，可以使用一个过滤器。之所以会发生穿透，就是因为缓存没有把那些不存在的值得Key缓存下来，从而导致每次查询都要请求到数据库。然后，从数据库加载，加载完毕，释放锁。，所有请求的都直接访问数据库，造成数据库高负载，影响性能，甚至数据库岩机。为了避免大量的缓存在同一时间过期，可以把不同的key过期时间设置成不同的。这样再出现查询这个key的请求的时候，直接返回null即可。，让数据库处于负载的情况。