性能设计-缓存
性能设计--缓存设计
- 缓存是提高性能最好的方式
- 缓存是为了加速数据访问，在数据库之上添加的一层机制
一般来说，缓存有以下三种模式
Cache Aisde 更新模式
Read/Write Through更新模式
Write Behind Caching 更新模式
Cache Aisde 更新模式(标准的设计模式)
该模式是最常用的设计模式，具体逻辑如下
失效：应用程序先从Cache取数据，如果没有得到，则从数据库中取数据，成功后，放到缓存中[在它品的代码中随处可见]
命中：应用程序先从Cache中取数据，取到后返回
更新：先把数据存到数据库中，成功后，再让缓存失效
- 为什么不在写数据库后更新缓存
并发写操作导致脏数据 - Cache Aisde 的问题[可能造成脏数据的场景]
| 进程1(读) | 进程2(写) |
|---|---|
| 读操作 | |
| 没有命中缓存 | |
| 数据库中取数据 | 同时一个写操作 |
| 写完成 | |
| 失效缓存 | |
| 将老数据放入缓存(造成脏数据) |
不过该场景发生的概率非常低，需要读缓存失效的同时有并发写操作。但对数据库来说写比读慢很多，而且还要锁表，读操作必须在写操作进入数据库之前，还要晚于写操作更新缓存。
流程如下图
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还可以合并对同一个数据的多次操作。
该模式带来的问题是，数据不是强一致性的，而且可能会丢失。
同时该处理逻辑比较复杂，需要追踪有哪些数据被更新，需要刷到持久层。
流程如下图
