性能设计--缓存设计

• 缓存是提高性能最好的方式
• 缓存是为了加速数据访问，在数据库之上添加的一层机制
  一般来说，缓存有以下三种模式
  Cache Aisde 更新模式
  Read/Write Through更新模式
  Write Behind Caching 更新模式

Cache Aisde 更新模式(标准的设计模式)

该模式是最常用的设计模式，具体逻辑如下
失效：应用程序先从Cache取数据，如果没有得到，则从数据库中取数据，成功后，放到缓存中[在它品的代码中随处可见]
命中：应用程序先从Cache中取数据，取到后返回
更新：先把数据存到数据库中，成功后，再让缓存失效

• 为什么不在写数据库后更新缓存
  并发写操作导致脏数据
• Cache Aisde 的问题[可能造成脏数据的场景]

不过该场景发生的概率非常低，需要读缓存失效的同时有并发写操作。但对数据库来说写比读慢很多，而且还要锁表，读操作必须在写操作进入数据库之前，还要晚于写操作更新缓存。
流程如下图

Read/Write Through更新模式

在Cache Aside模式中，应用代码需要维护两个数据存储，一个是缓存，一个是数据库。
在Read/Write Through模式中，由缓存处理更新数据库的操作。这种模式对应用层来说更简单(认为后端就是一个单一的存储，而存储维护自己的Cache)

• Read Through
  在查询操作中更新缓存，当缓存失效时，数据由缓存服务加到入缓存[Cache Aside中由调用方负责]
• Write Through
  当有数据更新的时候，如果没有命中缓存，直接更新数据库，然后返回。如果命中，则更新缓存，然后由Cahce更新数据库。
  流程如下图
  

Write Behind Caching 更新模式

Write Behind 又叫 Write Back。改模式在更新数据的时候，只更新缓存，不更新数据库，然后异步的批量更新数据库。该设计的好处是让I/O操作很快(直接操作内存)。因为异步，Write Back还可以合并对同一个数据的多次操作。
该模式带来的问题是，数据不是强一致性的，而且可能会丢失。
同时该处理逻辑比较复杂，需要追踪有哪些数据被更新，需要刷到持久层。
流程如下图

参考:
time.geekbang
FaceBook论文
Quora上关于为什么不是写数据库的时候更新缓存的问答

性能设计-缓存

原文：https://www.cnblogs.com/biby/p/14829609.html