最常用、应用最广泛的是第一个：Cache Aside Pattern（旁路缓存模式）。
为了帮你更好地理解，我们可以从场景选择和优缺点来剖析一下：
- Cache Aside Pattern (旁路缓存) ------ 工业界的首选
这是目前绝大多数互联网应用最通用的做法。
适用场景：读多写少的场景（绝大多数 Web 应用）。
逻辑：应用代码直接与数据库和缓存交互。
读数据：先读缓存，没命中再读数据库，并将数据写入缓存。
写数据：先更新数据库，然后直接删除缓存（注意：是删除而不是更新）。
为什么用它：
灵活性：你可以完全控制缓存的失效逻辑。
容错性：如果缓存服务宕机，程序依然可以从数据库读取，系统不会瘫痪（数据库压力虽会瞬间增大，但系统可用）。
一致性：采用"先删缓存，后更新数据库"或者"先更新数据库，再删缓存"的组合策略，可以很好地权衡性能与数据一致性。
- Read/Write Through Pattern
适用场景：对数据一致性要求极高，且希望缓存层对上层应用透明的场景。
特点：应用只负责和缓存交互，缓存层会自动去和数据库同步。
缺点：在 Java 后端开发（如使用 Redis + MySQL）中，这种模式实现起来较复杂，通常需要引入额外的中间件或框架来代理这一层逻辑，且缓存层如果出现故障，整个系统会直接受到影响。
- Write Behind Caching Pattern (又称 Write Back)
适用场景：极致的写入性能要求，如高频计数器、实时排行、日志分析等。
特点：应用只管更新缓存，缓存通过异步队列慢慢同步到数据库。
风险：如果缓存服务在同步给数据库之前宕机，会导致数据丢失。它保证的是最终一致性，不保证强一致性。因此，除非对实时性要求极高且能容忍少量数据丢失，否则一般不用于关键的业务数据。
