【微服务】第35节：Redis的缓存一致性

  IT领域往往都是面试造火箭，实际工作拧螺丝。为了更好的应对面试，让大家能拿到更高的offer✉，我们接下来就讲讲“造火箭”的事情🧑‍🚀。

🔥🔥🔥 包括以下几方面🔽 🎈：

🌈 - Redis - 高级：

• 📛 -Redis主从

• 🤿 - Redis哨兵

• 🧩 - Redis分片集群

• 👨‍💻 - Redis数据结构

• ♻️ - Redis内存回收

• ✅ - Redis缓存一致性（◀️）

1.缓存问题

Redis经常被用作缓存，而缓存在使用的过程中存在很多问题需要解决。例如：

• 💠缓存的数据一致性问题

• 💠缓存击穿

• 💠缓存穿透

• 💠缓存雪崩

1.1.缓存一致性

我们先看下目前企业用的最多的缓存模型。缓存的通用模型有三种：

• 🔹Cache Aside：有缓存调用者自己维护数据库与缓存的一致性。即：

  • 查询时：命中则直接返回，未命中则查询数据库并写入缓存

  • 更新时：更新数据库并删除缓存，查询时自然会更新缓存

• 🔹Read/Write Through：数据库自己维护一份缓存，底层实现对调用者透明。底层实现：

  • 查询时：命中则直接返回，未命中则查询数据库并写入缓存

  • 更新时：判断缓存是否存在，不存在直接更新数据库。存在则更新缓存，同步更新数据库

• 🔹 Write Behind Cahing：读写操作都直接操作缓存，由线程异步的将缓存数据同步到数据库

目前企业中使用最多的就是Cache Aside模式，因为实现起来非常简单。但缺点也很明显，就是无法保证数据库与缓存的强一致性。为什么呢？我们一起来分析一下。

Cache Aside的写操作是要在更新数据库的同时删除缓存，那为什么不选择更新数据库的同时更新缓存，而是删除呢？

原因很简单，假如一段时间内无人查询，但是有多次更新，那这些更新都属于无效更新。采用删除方案也就是延迟更新，什么时候有人查询了，什么时候更新。

⁉️ 那到底是先更新数据库再删除缓存，还是先删除缓存再更新数据库呢？