DEV 注意事项:不要忘记清除缓存!
这篇文章适合任何想要为 DEV 代码库做出贡献的人,并且需要一些关于缓存如何影响他们正在处理的功能/错误的说明。
我们的文档中目前还没有太多关于缓存的信息,除了 Fastly 被列为我们依赖的边缘缓存的关键服务。理论上,这条小注释足以让经验丰富的 Rails 开发人员了解在 DEV 中使用缓存时需要考虑哪些因素以及如何操作,但对于初级开发人员来说,这很可能让他们完全不知所措。
如果你像我一样是刚从训练营毕业,那么缓存可能根本不会出现在你的课程中——这是因为在你的应用处理大量流量之前,你根本不需要考虑缓存。所以,如果你不熟悉缓存的一般概念,请先阅读 Kevin Kononenko 的这篇精彩文章:
伟大的。
在 DEV 上,我们高度依赖通过内容分发网络 Fastly 进行缓存。这意味着您的 dev.to 请求将到达距离您所在位置最近的代理服务器(由 CDN 提供的服务器,用于存储我们最常用请求的文件),而不是一路传输到源站。如果您的请求确实需要到达源站,我们还会依赖 Rails 提供的开箱即用的缓存功能,该功能也存储静态的、随时可用的信息。这意味着浏览器、CDN 和 Rails 会协同工作以完成请求,然后直接将请求发送到底层代码以获取新的资源。
Browser Cache > CDN > Rails Cache > Underlying Code
这些都是非常常规的,因此Fastly和Rails文档是学习更多内容的绝佳资源。
如果你正在开发 DEV,那么值得问一问:“这个应该缓存吗?如果是,缓存到什么级别?”或者反过来问:“应该清除缓存吗?”在本文中,我们将重点讨论后者。
最近,我正在开发一个合并两个用户的功能——有时人们会分别通过 Twitter 和 GitHub 登录(而不是将它们关联起来),这样就会创建两个账户。这个过程相当简单:
- 将所有活动从帐户 B 移至帐户 A。
- 删除帐户 B。
完成上述操作后,可以合理地假设,当我访问帐户 A 的个人资料时,我会看到该用户的所有合并活动。结果却不是!我当时有点慌了,以为帐户 B 的所有数据都被删除了。结果发现,我在代码中没有发出清除 Fastly 缓存的信号,所以请求没有收到新数据。是的,用户个人资料(/用户名)都已缓存,这意味着每次该页面上的内容发生变化时,我们都需要清除缓存。
我们有一个缓存清除对象,可以轻松清除 Fastly 缓存,此外还有一些便捷的方法,用于处理需要定期清除的项目。这个文件:app/labor/cache_buster.rb
负责处理所有逻辑。以下是清除我用户资料中缓存的方法:CacheBuster.new.bust("/jess")
。
当我在 Fastly 上清除账户 A 的用户个人资料路径时,我以为会看到所有合并的活动。结果几乎就是那样——文章、徽章和评论都出现了,但其中一个社交图标不见了(具体来说是账户 B 的原始登录方式)。原来,我们利用了低级 Rails 缓存来处理用户数据。我没有运行任何“保存”回调,这些回调会在我更新账户 A 的个人资料时清除缓存。为了清除这个 Rails 缓存,我需要正式更新用户——就像user.touch
通常那样。
我认为在开发中不可能运行 Fastly 缓存,但可以通过切换使用简单的 rake 任务运行 Rail 的缓存bin/rails dev:cache
。
最后一点:除此之外,我们还使用了一个名为CounterCulture的 gem 。这个 gem 会跟踪articles_count
用户的关联计数,帮助我们提高查询速度。有时这些计数会不同步(例如,在更新用户活动时没有运行正确的回调……)。如果遇到这种情况,您可以直接更新计数。例如:
user.articles_count = user.articles.size
这有点像我们的缓存策略的“反向”视图,但我希望它能为 DEV 应用程序提供一些见解。
文章来源:https://dev.to/jess/dev-notes-don-t-forget-to-clear-cache-962