一个遗留的问题场景

话说很久很久之前，遇到过这样的一个问题，当时还是在用django自带得admin做项目，新闻的数据量很大，导致每次打开新闻的列表页都非常慢，把Django上能用的优化都用上之后好了些，但是还是没有彻底解决。当时貌似没有考虑用缓存来解决，具体原因忘了，毕竟后台项目体验上过得去就行。

看到cachalot之后，突然就想到了这个场景，当时没有用缓存可能是考虑数据增加很快,缓存的时间设置不好把握，也可能是其他原因。但是cachalot确实是一个值得考虑的方案。

怎么使用cachelot

上面说了些毫无营养的联想，再来说说怎么使用，github上说的很清楚了，使用相当简单:

pip install django-cachalot

#然后Django的installs_app中加入

INSTALLED_APPS = (
    ...
    "cachalot",
    ...
)
即可

原理

这个项目代码很少，做的事基本上就是给Django执行sql的那个方法: compiler.execute_sql = patch_execute_sql(compiler.execute_sql) 打个patch，大体逻辑就是，这个sql如果没执行过就执行，然后缓存结果。 这个是正常得缓存逻辑，那么如果数据进行了更改怎么处理呢，cachalot也对执行写数据库的方法打了patch，在写的时候根据语句对缓存进行删除。

总结

Djang本身提供了三个层级的cache：整站，view，自定义。cachalot相当于提供了query层级的cache。不过这东西对于单独的应用是有些帮助，但是对于相互依赖的多个应用就不太适用了，比如：A系统只是用来读数据的，本身并不写，这样缓存始终无法更新。

写完仔细想想，这东西貌似没有太多的应用场景。对于小站点或许有用，比如我的博客。但博客已经添加了view层的缓存。或许可以参考cachalot来做些缓存策略上的优化。