对于楼主的疑问，我也仔细思考过。本质上就是在缓存读取的时候加一个条件。IF（缓存失效）THEN（重建）ELSE（返回缓存数据）。这样的机制对开发来说的确很诱人，不用担心更新数据忘记清缓存。但是。。。IF条件当中的判断缓存失效的数据从哪里来呢？我想要么数据库，要么缓存，要么队列。所以个人觉得为了实现这么一个自动的功能代价有点高。
PHP的YII框架中有一个缓存依赖的模块可以看看，大致思路如上所述。其中的“缓存依赖”就相当于上面说的判断“缓存失效”的条件；在YII中，缓存依赖有很多种，例如数据库，缓存，文件更新时间等

把要更新的数据加入队列，开进程去跑队列，在进程里做处理，可否？

删除比更新好，如果你的请求里面包含了多次数据更新，由此会触发多次缓存更新，但实际上只有最后一次更新的缓存才是有效的。如果更新缓存的执行成本较高的话可能在偶发的高频更新下会引发执行效率的问题。

相对来说，删除缓存的代价更低，且没有请求就不会生成新的缓存，中间无论怎么更新数据都不会浪费。

这种删除策略对于高负荷网站很可能是不适用的，对于这种类型的应用，宁愿牺牲一致性也不会让大量请求直接穿透到数据库上，但对于大多数网站，这种做法应该问题都不大。

在Model里面写update的后置方法 _after_update()，在后置方法里面删除缓存

这和我前几天解决的问题类似，卖个萌！
其实这类问题，我个人认为属于框架问题，或再大一点说是架构问题也不为过~所以如果只是盯着业务来思考这个问题，可能会很无力~
之所以我最后采取“爬虫”方案，是因为开发之初就没有意识到缓存已经成为现在网站的标配，属于非功能性但必要需求！

=。= 一直都是做缓存不更新的数据，第一次碰到，想了一下，可以在在数据库比如MYSQL做触发器。

菜鸟轻拍。

如果在Model中统一处理，这并不难吧。

一般方式是在模型层做处理，因为数据的增删改都是在模型层进行的。有很多php框架都支持事件绑定，所以也可以使用事件机制处理。