“更新缓存” 与 淘汰缓存” 对比

缓存是一种提高系统读性能的常见技术，对于读多写少的应用场景，我们经常使用缓存来进行优化。

那么问题来了，当数据发生变化的时候：
（1）是更新缓存中的数据，还是淘汰缓存中的数据呢？
（2）是先操纵数据库中的数据再操纵缓存中的数据，还是先操纵缓存中的数据再操纵数据库中的数据呢？
（3）缓存与数据库的操作，在架构上是否有优化的空间呢？
这是本文关注的三个核心问题。

更新缓存
数据不但写入数据库，还会写入缓存；更新缓存的优点：缓存不会增加一次miss，命中率高
淘汰缓存
数据只会写入数据库，不会写入缓存，只会把数据淘汰掉；淘汰缓存的优点：简单

选择更新缓存还是淘汰缓存
主要取决于更新缓存的复杂度，只是简单的把数据设置成一个值，那么：
（1）淘汰缓存的操作为deleteCache(uid)
（2）更新缓存的操作为setCache(uid, data)
更新缓存的代价很小，此时我们应该更倾向于更新缓存，以保证更高的缓存命中率。
如果数据需要通过复杂的计算得出，那么更新缓存的代价很大，此时我们应该更倾向于淘汰缓存。

淘汰缓存操作简单，并且带来的副作用只是增加了一次cache miss，建议作为通用的处理方式。

先操作数据库还是先操作缓存
假设淘汰缓存作为对缓存通用的处理方式，又面临两种选择：
（1）先写数据库，再淘汰缓存
（2）先淘汰缓存，再写数据库
究竟采用哪种时序呢？

对于一个无法保证事务性的操作，一定涉及“哪个操作先做，哪个操作后做”的问题，解决这个问题的方向是：
如果出现不一致，谁先做对业务的影响较小，就谁先执行。
由于写数据库与淘汰缓存不能保证原子性，谁先谁后同样要遵循上述原则。
假设先写数据库，再淘汰缓存
：第一步写数据库操作成功，第二步淘汰缓存失败，则会出现DB中是新数据，Cache中是旧数据，数据不一致。

假设先淘汰缓存，再写数据库：
第一步淘汰缓存成功，
第二步写数据库失败，则只会引发一次Cache miss。
结论：
数据和缓存的操作时序，结论是清楚的：先淘汰缓存，再写数据库。

缓存架构优化
服务化优化方案
在应用与数据库之间加入一个服务层，向上游提供数据访问接口，向上游屏蔽底层数据存储的细节，这样业务线不需要关注数据是来自于cache还是DB。

异步缓存更新方案
业务所有的写操作都走数据库，所有的读操作都通过缓存，由一个异步的工具来做数据库与缓存之间数据的同步，具体细节是：
（1）要有一个初始化缓存的过程，将需要缓存的数据全量写入缓存
（2）如果数据库有写操作，异步更新程序读取binlog日志，更新缓存
在（1）和（2）的合作下，缓存中有全部的数据，这样：
（a）业务线读cache，一定能够hit（很短的时间内，可能有脏数据），无需关注数据库
（b）业务线写DB，cache中能得到异步更新，无需关注缓存
这样将大大简化业务线的调用逻辑，存在的缺点是：
如果缓存的数据业务逻辑比较复杂，async-update异步更新的逻辑可能也会比较复杂。