大家好，欢迎来到IT知识分享网。

在实际的工作项目中， 缓存成为高并发、高性能架构的关键组件 ，那么Redis为什么可以作为缓存使用呢？首先可以作为缓存的两个主要特征：

由于Redis 天然就具有这两个特征，Redis基于内存操作的，且其具有完善的数据淘汰机制，十分适合作为缓存组件。

其中，基于内存操作，容量可以为32-96GB，且操作时间平均为100ns，操作效率高。而且数据淘汰机制众多，在Redis 4.0 后就有8种了促使Redis作为缓存可以适用很多场景。

那Redis缓存为什么需要数据淘汰机制呢？有哪8种数据淘汰机制呢？

数据淘汰机制

Redis缓存基于内存实现的，则其缓存其容量是有限的，当出现缓存被写满的情况，那么这时Redis该如何处理呢？

Redis对于缓存被写满的情况，Redis就需要缓存数据淘汰机制，通过一定淘汰规则将一些数据筛选出来删除，让缓存服务可再使用。那么Redis使用哪些淘汰策略进行刷选删除数据？

在Redis 4.0 之后，Redis 缓存淘汰策略6+2种，包括分成三大类：

Note: LRU( 最近最少使用，Least Recently Used)算法， LRU维护一个双向链表 ，链表的头和尾分别表示 MRU 端和 LRU 端，分别代表最近最常使用的数据和最近最不常用的数据。

LRU 算法在实际实现时，需要用链表管理所有的缓存数据，这会带来额外的空间开销。而且，当有数据被访问时，需要在链表上把该数据移动到 MRU 端，如果有大量数据被访问，就会带来很多链表移动操作，会很耗时，进而会降低 Redis 缓存性能。

其中，LRU和LFU 基于Redis的对象结构redisObject的lru和refcount属性实现的:

typedef struct redisObject {
    unsigned type:4;
    unsigned encoding:4;
    // 对象最后一次被访问的时间
    unsigned lru:LRU_BITS; /* LRU time (relative to global lru_clock) or
                            * LFU data (least significant 8 bits frequency
    // 引用计数                        * and most significant 16 bits access time). */
    int refcount;
    void *ptr;
} robj;

IT知识分享网

Redis的LRU会使用redisObject的lru记录最近一次被访问的时间，随机选取参数maxmemory-samples 配置的数量作为候选集合，在其中选择 lru 属性值最小的数据淘汰出去。

在实际项目中，那么该如何选择数据淘汰机制呢？

在理解了Redis缓存淘汰机制后，来看看Redis作为缓存其有多少种模式呢？

Redis缓存模式

Redis缓存模式基于是否接收写请求，可以分成只读缓存和读写缓存：

只读缓存：只处理读操作，所有的更新操作都在数据库中，这样数据不会有丢失的风险。

读写缓存，读写操作都在缓存中执行，出现宕机故障，会导致数据丢失。缓存回写数据到数据库有分成两种同步和异步：

Cache Aside模式

查询数据先从缓存读取数据，如果缓存中不存在，则再到数据库中读取数据，获取到数据之后更新到缓存Cache中，但更新数据操作，会先去更新数据库种的数据，然后将缓存种的数据失效。

而且Cache Aside模式会存在并发风险：执行读操作未命中缓存，然后查询数据库中取数据，数据已经查询到还没放入缓存，同时一个更新写操作让缓存失效，然后读操作再把查询到数据加载缓存，导致缓存的脏数据。

Read/Write-Throug模式

查询数据和更新数据都直接访问缓存服务，缓存服务同步方式地将数据更新到数据库。出现脏数据的概率较低，但是就强依赖缓存，对缓存服务的稳定性有较大要求，但同步更新会导致其性能不好。

Write Behind模式

查询数据和更新数据都直接访问缓存服务，但缓存服务使用异步方式地将数据更新到数据库（通过异步任务） 速度快，效率会非常高，但是数据的一致性比较差，还可能会有数据的丢失情况，实现逻辑也较为复杂。

在实际项目开发中根据实际的业务场景需求来进行选择缓存模式。那了解上述后，我们的应用中为什么需要使用到redis缓存呢？

在应用使用Redis缓存可以提高系统性能和并发，主要体现在

虽然使用Redis缓存可以大大提升系统的性能，但是使用了缓存，会出现一些问题，比如，缓存与数据库双向不一致、缓存雪崩等，对于出现的这些问题该怎么解决呢？

使用缓存常见的问题

使用了缓存，会出现一些问题，主要体现在：

缓存与数据库数据不一致

只读缓存(Cache Aside模式)

对于只读缓存(Cache Aside模式)， 读操作都发生在缓存中，数据不一致只会发生在删改操作上（新增操作不会，因为新增只会在数据库处理），当发生删改操作时，缓存将数据中标志为无效和更新数据库 。因此在更新数据库和删除缓存值的过程中，无论这两个操作的执行顺序谁先谁后，只要有一个操作失败了就会出现数据不一致的情况。

总结出，当不存在并发的情况使用重试机制（消息队列使用），当存在高并发的情况，使用延迟双删除(在第一次删除后，睡眠一定时间后，再进行删除)，具体如下：

NOTE:

延迟双删除伪代码：

redis.delKey(X)
db.update(X)
Thread.sleep(N)
redis.delKey(X)

读写缓存（Read/Write-Throug、Write Behind模式 ）

对于读写缓存，写操作都发生在缓存中，后再更新数据库，只要有一个操作失败了就会出现数据不一致的情况。

总结出，当不存在并发的情况使用重试机制（消息队列使用），当存在高并发的情况，使用分布锁。具体如下：

缓存雪崩

缓存雪崩，由于缓存中有大量数据同时过期失效或者缓存出现宕机，大量的应用请求无法在 Redis 缓存中进行处理，进而发送到数据库层导致数据库层的压力激增，严重的会造成数据库宕机。

对于缓存中有大量数据同时过期，导致大量请求无法得到处理， 解决方式：

对于缓存出现宕机，解决方式：

缓存穿透

缓存穿透，数据在数据库和缓存中都不存在，这样就导致查询数据，在缓存中找不到对应key的value，都要去数据库再查询一遍，然后返回空（相当于进行了两次无用的查询）。

当有大量访问请求，且其绕过缓存直接查数据库，导致数据库层的压力激增，严重的会造成数据库宕机。

对于缓存穿透，解决方式：

缓存击穿

缓存击穿，针对某个访问非常频繁的热点数据过期失效，导致访问无法在缓存中进行处理，进而会有导致大量的直接请求数据库，从而使得数据库层的压力激增，严重的会造成数据库宕机。

对于缓存击穿，解决方式：

总结

在大多数业务场景下，Redis缓存作为只读缓存使用。针对只读缓存来说， 优先使用先更新数据库再删除缓存的方法保证数据一致性 。

其中，缓存雪崩，缓存穿透，缓存击穿三大问题的原因和解决方式

来源：https://segmentfault.com/a/1190000039020626