缓存实践Cache Aside Pattern

Cache Aside Pattern旁路缓存，是对缓存应用的一个总结，包括读数据方案和写数据方案。

读数据方案

1. 先读cache，如果命中则返回
2. 如果miss则读db
3. 将db的数据存入缓存

写数据方案

写数据的过程包括了两个问题，更新cache的策略和操作db与cache的顺序。更新cache有两种策略：直接更新cache，和删除cahce。操作db和cache的顺序有先db再cache，和先cache再db。那么就会组合出四种方案：

1. 先更新db再更新cache
2. 先更新db再删除cache
3. 先更新cache再更新db
4. 先删除cache再更新db

Cache Aside Pattern采用的是第2种方案先更新db再删除cache：

1. 先更新数据到db
2. 再删除缓存

其他方案为啥不用呢？

第1种方案：先更新db再更新cache

更新cache比删除cache更直接，也不会在查询时候再从db查询一次，但是这个方案有缺陷，更新db和更新cache是两个操作，不在一个事务，假如有两个线程同时写数据：

1. 线程1先更新了db
2. 线程2也更新了db
3. 线程2又更新了cache
4. 线程1更新了cache

此时db的数据是线程2的，而cache的数据是线程1的，db和cache不一致了。。。此方案无法保证多线程并发时db和ache的一致性。而如果采用删除缓存则不会出现问题。

第3种方案：先更新cache再更新db

这个方案和方案方案1存在同样的问题：无法保证多线程并发时db和ache的一致性。

第4种方案：先删除cache再更新db

如果有两个线程，线程1写数据，线程2读数据：

1. 线程1将cache删除
2. 线程2读数据miss
3. 线程2读取db数据
4. 线程2将db数据写入缓存
5. 线程1将数据更新到db

又悲剧了，cache里面是旧数据。。。

写数据最好的方案是先更新db再删除cache

最后说明一点，Cache Aside Pattern并没有解决分布式事务问题。分布式事务比较复杂，一般保证db和cache的强一致比较困难。根据CAP理论，为保证可用性场景，可以用最终一致性方案解决。

—恢复内容结束—