缓存用于缓解后端db的压力，策略指的是更新缓存以及db的方式。
主要可以分为两个大类：
调用方主动更新缓存以及db：
这种是最最常见也是最最容易想到的方式。即调用端需要同时维护db和缓存的调用，调用端逻辑比较复杂。
读取：先读缓存，缓存未命中读取db然后回写缓存；
写入：同时写入，有很多种。分类标准：db和缓存的先后；缓存失效还是更新。
其实，对写入而言，不论使用什么方式，都会有一些问题存在，因为无法保证db和缓存的更新是原子性的。
但是通常，使用先更新db再让缓存失效可以最大程度得降低问题出现的概率。
为什么？
首先看第二个维度，是失效还是更新？
如果用更新会有什么问题？
两个并发的更新操作会出现写入覆盖的问题，其实与mysql的事务比较相似。
如果不用锁加同步，这个问题无法避免。
如下：
update1： db cache
update2： db cache
类似上面这种并发更新，不论是先缓存还是先db，总会有db与缓存数据不一致的情况。
所以应该使用失效而非更新，只不过失效会增加一次miss而已，并无大碍。
那么是先让缓存失效还是先更新db？
应该先更新db，因为假如先失效缓存，如下序列：
这样，读操作就会把一个之前的脏值放入缓存中，导致缓存db不一致。
如果先更新db：
这种情况也会导致缓存不一致，但是这种情况的条件要苛刻一些，因为update db和delete cache必须发生在select db 和 set cache之间才行。而update db执行一般比select db久，那么select db先发生，但是update db和delete cache已经结束时select db还没有结束导致无法set cache的概率就比较低。
当然，无论如何还是有脏数据的可能。
所以，为缓存设置一个超时时间是必须的，这样可以防止脏数据一直存在而无法被更新。
调用方只更新其中一个：
这种方式将会大大降低调用方的复杂度，读取和上面的没有区别，只是写入有区别，调用方仅仅需要更新一处，即可。
更新缓存：写入操作只更新缓存，然后由缓存更新到db。
更新db：写入操作只更新db，然后监听db的变更，比如说mysql的binlog，监听以后再更新缓存。
下面记录下监听mysql的binlog来更新或者删除缓存的考虑：
缺点：相比较于直接更新缓存，监听binlog从设计上来说更加复杂，另外可能会有延迟；
优点：解放业务代码，我业务代码涉及到更新的地方只需要改db即可，缓存更新不需要考虑。当然有人会说，你这样只是不在业务代码里写了而已，但是更新缓存的逻辑你还是需要在监听binlog的代码里写啊，该写的代码还是没少啊。对，是没少，但是，区别在于，你思考或者写一个更新逻辑时，完完全全可以把更新缓存与db分开，这是很重要的。否则，你需要一直考虑，我的db写入成功没？我写缓存是异步还是同步？等等这样的问题。而监听binlog的方式就不需要这样想，我只管写db就行，能监听到binlog就说明一定写入成功。这其实是一种解耦。
另外还有一个优点就是，如果要做数据迁移，不用binlog的方式可能需要同时迁移缓存数据，但是有了binlog，只迁移db数据就行。
再比如删除脏数据等。
总之，监听binlog方式最大的优点就是解耦，只关注db即可，缓存自动跟着db更新。
