总--下面的都是方法论，理论。至于具体实现，各个缓存产品自己定
更新缓存的的Design Pattern有四种：Cache aside, Read through, Write through, Write behind caching
Cache Aside Pattern
这是最常用最常用的pattern了。其具体逻辑如下：
失效：应用程序先从cache取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。
命中：应用程序从cache中取数据，取到后返回。
更新：先把数据存到数据库中，成功后，再让缓存失效。
失效和命中的示意图：
更新的示意图：
如果更新时先让缓存失效，再更新数据，下次读取时再将数据更新到缓存中可否？
一个事实是，写操作（更新操作）要比读操作慢。
假设现在有两个并发操作读操作Read和更新操作Write，如果更新操作前就让缓存失效。那么Write还没进行完，就有Read操作进来，这时Read先从缓存获取数据并且没有获取到，那么Read会直接把老数据OldData读取出来后放到缓存中。而后Write更新了数据，数据变成了新的数据NewData。这时，就出现了缓存中的数据OldData和数据源中的数据NewData不一致的情形。并且Read操作一直可以从缓存中获取OldData，也没法对OldData进行更新了。
Read/Write Through Pattern
更新数据库（Repository）的操作由缓存自己代理。应用认为后端就是一个单一的存储，而存储自己维护自己的Cache。
Read Through
Read Through 套路就是在查询操作中更新缓存，也就是说，当缓存失效的时候（过期或LRU换出），Cache Aside是由调用方负责把数据加载入缓存，而Read Through则用缓存服务自己来加载，从而对应用方是透明的。
Write Through
Write Through 套路和Read Through相仿，不过是在更新数据时发生。当有数据更新的时候，如果没有命中缓存，直接更新数据库，然后返回。如果命中了缓存，则更新缓存，然后再由Cache自己更新数据库（这是一个同步操作）
下图自来Wikipedia的Cache词条。其中的Memory可以理解为就是例子里的数据库。
Write Behind Caching Pattern
Write Behind 又叫 Write Back，更新数据的时候，只更新缓存，不更新数据库，而缓存会异步地批量更新数据库。
设计的好处就是让数据的I/O操作飞 快无比（因为直接操作内存 ），因为异步，write backg还可以合并对同一个数据的多次操作，所以性能的提高是相当可观的。
带来的问题是，数据不是强一致性的，而且可能会丢失。
另外，Write Back实现逻辑比较复杂，因为他需要track有哪数据是被更新了的，需要刷到持久层上。操作系统的write back会在仅当这个cache需要失效的时候，才会被真正持久起来，比如，内存不够了，或是进程退出了等情况，这又叫lazy write。
441
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
