缓存设计的几种方式
这里指缓存的更新方式，一般来说缓存的更新方式有三种：
Cache Aside更新模式
这是最常见的更新模式，其设计如下：
- 读取：先从缓存中查询，如果存在直接返回；否则从数据库中读取结果放入缓存，然后返回；
- 写入：先写入数据库，然后将缓存中的数据设置为失效；
那么对于写操作，在写入数据库之后为什么不直接讲数据写入缓存，而是将其设置为过期状态呢？ 其实这么做的原因主要是怕引起脏读，因为如果两个并发的写操作，无法确定那个操作先完成，所以最后写入缓存的值也就无法确定。
而使其失效的方式就一定不会有并发问题了吗？ 并不是的。想象一下来了一个读操作，缓存中不存在，所以要去数据库中读，而这时又来了一个写操作，写完数据库后会将数据放到缓存中。而前面的写操作马上又会将其从数据库中的旧数据覆盖到缓存中，导致错误产生。
但实际上，这种情况很少发生，因为它的概率确实很低，至于为什么大家可以google一下，网上有很多相关的信息。但也不是不可能，所以稳妥一点的方式是为缓存设置一个有效时间。
Write/Read Through更新模式
上面说的cache-aside模式，应用程序需要维护两份数据交互，一个是缓存，另一个是数据库，这样对应用程序来说比较繁琐。而Write/Read模式则将缓存和数据库看成是一个整体，我们把它叫做缓存系统，对于数据库的交互全由缓存系统自己控制。对应用程序来说只需跟缓存交互即可，至于对数据库的操作则不关心。
read through
这是对于读操作而言，当缓存失效时，缓存系统从数据库中读入新的数据放在缓存中，然后返回。
write through
对于写操作而言，如果没有命中缓存，则直接更新数据库；否则直接更新缓存，然后再由缓存系统写到数据库。
其过程可以参考wiki的示意图：
Write Behind Caching更新模式
与Write through类似，对于写操作，只更新缓存，而不更新数据库。更新数据库的操作通过后台异步方式实现，类似一些消息队列的异步持久化的方式，这样的好处是写操作只针对内存操作，后台异步写操作还可以批量处理，整体来说速度更快。
这种实现方式较为复杂，其过程可以参考wiki的示意图：