我刚刚在我的网络应用程序中启用了Django的每站点缓存（使用Redis作为我的缓存后端）并立即遇到问题。我的网站包含一个用户个人资料页面，其中显示了用户的照片及其内容。我还有一个表格，允许他们改变他们的照片和/或生物。如果用户上传了新照片，我会为该照片创建一个新的唯一名称。正如您所期望的那样，当用户访问该表单并上传新照片并重新显示他们的个人资料页面以便他们可以在使用新照片或生物提交之前对其进行审核，该页面会显示他们的旧照片，因为我有站点缓存已启用。我可以禁用特定视图的缓存（例如，对于这种情况），还是必须禁用每站点缓存并在逐个视图的基础上实现它？这是我第一次使用缓存的体验，我不知道应该采取什么方法。我有另一个视图/模板，显示当前登录的所有用户，我预计会有相同的问题，即他们的旧照片将在他们更改后继续显示。
感谢您的建议。
答案 0 :(得分：1)
首先，你不应该只是将缓存作为表现的灵丹妙药，特别是如果你不知道自己在做什么。缓存会增加堆栈的复杂性，它会造成另一个故障点，显然它有时会导致难以排除故障的奇怪问题。在你弄清楚如何衡量网站的性能，做了一些分析，并且事实证明你有性能问题之前，你可能最好不要进行任何缓存。从我读过的内容来看，在尝试通过Django进行缓存之前，最好将重点放在优化数据库查询和最小化页面权重上。如果你想在该棒上完成任何缓存，请查看通过Web服务器（Apache，Nginx等）缓存图像，样式表和JavaScript。
关于我的问题，我认为我对缓存如何运作有错误的概念。当我在Django中启用“per-site”缓存时，我认为我对Django说的是“在Redis缓存中存储每个页面请求的每个响应，直到缓存填满并开始驱逐事物。”如果请求页面并且该页面仍在缓存中，则缓存不会神奇地知道该页面是否已更改，然后获取更新的版本（如果有）。它将继续返回该缓存页面，无论我更改它多少次（除非它被驱逐）。
我做的测试就是将@never_cache装饰器应用于相关视图。这解决了我遇到的问题。但是，正如Lorenzo所暗示的那样，根据具体情况应用缓存可能是一种更好的方法。如果要缓存特定视图，请使用@cache_page装饰器。如果要缓存模板的一部分，请使用{％cache％}。通过Django的低级API“django.core.cache.caches”缓存计算成本高昂的实际数据。如果你想根据缓存过期和/或验证进行缓存，可以通过@condition装饰器使用Django的“条件视图处理”功能。
如果您对缓存完全陌生，我强烈建议您阅读Mark Nottingham的Caching Tutorial和Ryan Tomayko的Things Caches Do。
我希望这有帮助！