在Django查询缓存处理策略与实现中介绍了利用django singal来实现model缓存的方式。相应代码在实际项目中也运行了有一阵，其间也遇到了不少坑..

models.update不会触发cache更新

之前提及的缓存更新机制是通过post-save signal来实现的，在调用models.save、models.create时会触发signal，然而update是不会触发的。因此对单个model对象进行更新时还是需要通过调用save，而不是update。

在对多个对象进行更新时则无法避免使用update操作，比如，

Post.objects.all().update(title='xxx')

一旦进行了上述update操作，缓存中的数据更新也必须进行手动处理了。

transaction可能导致缓存与数据库不一致

假设在transaction块中调用了save，signal就会触发缓存数据修改，然而若是transaction失败rollback了，那数据库数据就不会发生改动，然而这时缓存中数据却已经被修改掉了。这种情况导致的不一致相对来说处理起来就麻烦多了，也找不到一个通用的方法。

因为种种可能的莫名其妙的异常问题，缓存中存放的数据若是出现了问题，则需要有一定的修正机制。在手动控制缓存的时候，这种修正容易添加。类似这种自动化的缓存处理，则暂时只能寄希望与缓存数据的自动过期，以及编码上的一些约定。

category = Category.cache.get(id=1)

经过这么一系列的改进，算是有一个能用版本了。这个版本依然有不足，比如接收的参数也可以改为django orm的那些参数，然后可以考虑进一步实现cache.filter(...)等操作。一句话，经可能简化缓存的访问调用。不过这些进一步的优化就有待需要使用的时候再行添加了。