Redis缓存：淘汰机制、缓存雪崩、数据不一致，都一步说到位

Redis缓存模式

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

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

• Cache Aside模式

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

• 同步：访问性能偏低，其更加侧重于保证数据可靠性

• Read-Throug模式

• Write-Through模式

• 异步：有数据丢失风险，其侧重于提供低延迟访问

• Write-Behind模式

Cache Aside模式

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

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

Read/Write-Throug模式

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

Write Behind模式

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

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

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

• 高性能：基于内存查询，KV结构，简单逻辑运算
• 高并发： Mysql 每秒只能支持2000左右的请求，Redis轻松每秒1W以上。让80%以上查询走缓存，20%以下查询走数据库，能让系统吞吐量有很大的提高

虽然使用Redi