简单说说缓存中的几种模式。ACache-Aside读操作：应用先查询缓存，命中则返回；如果应用程序未命中，它会从数据库中读取数据，将其写入缓存，然后返回。写操作：应用程序先更新数据库，然后删除缓存，然后返回。可以看出，在这种模式下，缓存只有写和删除操作，没有修改。适用场景：多读少写。存在问题：多线程下容易出现数据不一致。2Read/Write-Through核心思想：当应用程序需要操作数据时，只与缓存组件进行交互；缓存中的数据不会过期。Read-Through，应用查询缓存是否存在，存在则返回；如果不存在，则缓存组件从数据库加载数据。Write-Through，先查询缓存中是否存在要写入的数据，如果存在则先更新缓存再更新数据库最后返回；如果要写入的数据在缓存中不存在，对应的策略有两种：一种是先将数据写入缓存，然后缓存组件将数据同步更新到数据库中；另一种策略是直接将数据写入数据库而不写入缓存。适用场景：多读少写。存在的问题：由于应用在操作数据时只与缓存组件交互，数据不一致的概率比Cache-Aside低。因为这种模式下缓存是没有过期时间的，所以缓存的使用会非常大。3.Write-BackWrite-Back也称为Write-Behind。这种模式是进行Write-Through。异步回写一般用于数据持久化存储的回写，也可以在一定时间后批量回写。场景：少读，多写存在问题：异步或按一定间隔批量回写，会造成数据延迟或数据丢失。这里只是介绍常见缓存模式中的一些基本情况。讨论的缓存模式都有自己的问题。我们需要根据自己的业务场景选择适合自己的模式。当然，在使用缓存时必须考虑数据丢失、热数据、缓存穿透、缓存预热等问题。另外，数据模型也需要注意。Cache-Aside下缓存中的数据模型可能与数据库的数据模型不一致，但Read/Write-Through模式下两者的数据模型一般需要相同。最后附上一篇比较全面的文章，链接：https://mp.weixin.qq.com/s?__...提到了数据一致性一般是多步操作，其中一个步骤失败并发也介绍了各种解决方案和问题，比如延迟双删的场景。文章中还提到我们使用redis来提高性能。有时我们不能保证完全一致性，只能做到最终一致性，即CAP中的AP（可用性和分区容错性，一致性很难）。还有一点就是使用Cache-Aside模式造成不一致的概率是最低的。我们先列举如下过程：X在缓存中不存在，在数据库中X=1。线程A读取数据库，得到旧值X=1。线程B更新数据库X=2，线程B删除缓存线程A将旧值X=1写入缓存为什么说Cache-Aside模式造成不一致的概率很低呢？原因如下：读请求+写请求的并发缓存刚刚过期。更新数据库+删除缓存的时间（步骤3-4）比读数据库+写缓存的时间（步骤2和5）要短。会出现不一致，尤其是第三步的可能性比较小，因为更新数据的时间可能会有锁，一般比读取的时间要长。总结：引入缓存的目的大多是为了提高性能和数据的强一致性。通常很难考虑到没有特殊情况。建议先更新数据库，再删除缓存。延迟双删是针对缓存+主从数据库不及时同步问题，一般通过消息队列进行缓存删除操作，但是延迟时间不好评估（先删除缓存，再修改数据库，最后在一定时间后删除缓存）。参考文章：https://www.pianshen.com/arti...https://hiddenpps.blog.csdn.n...缓存穿透、雪崩等问题处理缓存穿透、雪崩等问题处理中的一些问题redis延迟双删
