结合业务场景，缓存的读写方式可以分为以下三种模式：
-
Cache Aside（旁路缓存）
-
Read/Write Through（读写穿透）
-
Write Behind Caching（异步缓存写入）
Cache Aside
- 查询：应用程序先去cache中读取数据，如果可以命中，则直接返回；如果没有命中，则去数据库中查询，成功后存入缓存。
- 更新：应用程序先去更新数据库，成功后再删除缓存。
最常见的一种方式。在这种模式下可以尽可能的保证缓存的一致性，适合对一致性要求较高的场景。
注意：在更新数据时，以下方式可能会造成数据不一致。
1、先删除缓存，再更新DB。删除缓存后，更新DB之前如果有新的查询请求到来，会将缓存更新为原来的结果，造成不一致。
线程1：----> 删除缓存 ------------------------> 更新DB（新数据）
线程2：------------------> 查询DB（脏数据）----> 将脏数据存入缓存
2、先更新DB，再更新缓存。在并发更新的场景下，两个线程的更新DB与更新缓存的顺序无法控制，导致数据不一致。
线程1：----> 更新DB（新数据1）------------------------------------------------------------> 更新缓存（新数据1）
线程1：-------------------------------> 更新DB（新数据2）----> 更新缓存（新数据2）
3、先更新DB，再删除缓存。这种方式是我们推荐的方式，但是还是有数据不一致的可能，比如：
线程1：-----------------------------------------------------> 更新DB（新数据） --> 删除缓存
线程2：----> 没有命中缓存，查询DB（脏数据） ----------------------------------------------> 将脏数据存入缓存
虽然发生这种不一致的情况几率很小，但还是要引入缓存失效时间来避免长时间数据的不一致。
Read/Write Through
对于 Cache Aside 模式，业务应用需要同时维护 cache 和 DB 两个数据存储方，过于繁琐。而在Read/Write Through模式下，存储服务封装了所有的数据处理细节（cache + DB），业务应用端代码只用关注业务逻辑本身，系统的隔离性更佳。
存储服务收到业务应用的写请求时，会首先查 cache，如果数据在 cache 中不存在，则只更新 DB，如果数据在 cache 中存在，则先更新 cache，然后更新 DB。而存储服务收到读请求时，如果命中 cache 直接返回，否则先从 DB 加载，回种到 cache 后返回响应。
Write Behind Caching
在该模式下，更新数据时只更新缓存，不直接更新DB，通过异步的方式将缓存结果批量的或合并后再更新到DB。这种方式的特点是效率非常高，但不是强一致，甚至会丢失数据，适用于访问量、点赞数等对于性能要求高，但一致性要求不高的场景。
