缓存更新的模式主要有：
Cache Aside Pattern
在Cache Aside模式中，对于读操作来说，首先读cache,若cache命中，则直接返回；若cache未命中，读DB,然后将读取到的数据写入cache,并返回结果。
对于写操作来说，更新DB中的数据，然后失效cache中的数据。
这种模式的特点是，业务端处理所有数据访问细节，同时利用 Lazy 计算的思想，更新 DB 后，直接删除 cache 并通过 DB 更新，确保数据以 DB 结果为准，则可以大幅降低 cache 和 DB 中数据不一致的概率。
Read/Write Through Pattern
对于Cache Aside模式来说，业务方需要同时维护cache和DB，而Read/Write Through 模式则是将cache和DB交由统一的存储服务管理。
业务进行写操作时，存储服务首先判断cache中是否存在数据，若存在，先更新cache，再更新DB;若不存在，则只更新DB.
业务进行读操作时, 存储服务首先判断cache中是否存在数据，若存在，返回数据；若不存在，则从DB中读取数据，并将数据载入cache中并返回。
这种模式的特点是，存储服务封装了所有的数据处理细节，业务应用端代码只用关注业务逻辑本身，系统的隔离性更佳。另外，进行写操作时，如果 cache 中没有数据则不更新，有缓存数据才更新，内存效率更高。
Write Behind Caching Pattern
Write Behind Caching Pattern与Read/Write Through Pattern一样，将cache和DB交由同一的存储服务管理，不同的是再执行业务方的写操作时，更新cache后,不会直接更新DB,而是异步更新DB。
读操作则与Read/Write Through Pattern一致。
这种模式的特点就是数据存储的写性能最高，非常适合一些变更特别频繁的业务，特别是可以合并写请求的业务。但是这个模式的缺点就是，比如系统 Crash、机器宕机时，如果有数据还没保存到 DB，则会存在丢失的风险。所以这种读写模式适合变更频率特别高，但对一致性要求不太高的业务，这样写操作可以异步批量写入 DB，减小 DB 压力。
