缓存和http缓存“反向代理”有什么区别

Question

我有点难以理解普通缓存“内存、文件、数据库等”和 http 缓存“反向代理”之间的区别。

示例。

假设我有一个页面分为 3 个部分。

• 电影
• 游戏
• 应用程序

当我从数据库中检索这些部分时，我将每个部分缓存在其自己的密钥中，并且当向这些部分中的任何一个输入新数据时，我会刷新缓存并重新制作它，包括新数据，所以现在每个部分都会仅在添加了新内容时才更新。

另一方面，http缓存有一些调用ESI，你可以包含与主页具有不同缓存寿命的页面部分，这是完美的，但是

为什么我需要使用它？ 或者比第一种方法有什么优势？

编辑

• 这比我所追求的更模糊，但你为什么要在下面使用/继续使用反向代理？

https://laracasts.com/series/russian-doll-caching-in-laravel https://www.reddit.com/r/laravel/comments/3b16wr/caching_final_html_from_view/ https://github.com/laracasts/matryoshka

Answer 1

反向代理缓存有几个好处：

• 代理服务的请求永远不会到达您的网络服务器。通常是 更便宜/更容易扩展您的代理服务器（例如，通过使用 Akamai 等商业提供商）而不是扩展您的 网络服务器。
• 这意味着您可以在流量高峰和拒绝 服务攻击的压力要小得多。
• 这也意味着你可以服务 不靠近您的源网络服务器的流量要快得多 - 如果 您的网站服务于全球受众，延迟可能会对 您认为的响应时间。
• 您也可以让您的网络服务器离线，例如用于升级，而不影响您的最终用户。

反向代理缓存的缺点：

• 这是一个额外的架构层，带来了复杂性、维护、管理等。
• 这可能还需要额外的费用（大多数站点都有单独的反向代理服务器基础设施，或者使用商业 CDN 提供商）。
• 您的解决方案设计需要管理更多层之间的缓存失效 - 这很容易变得复杂且容易出错。
• 反过来，这意味着调试和测试解决方案可能非常困难。如果 QA 团队报告了错误的页面，您需要能够找出该项目的提供来源 - 反向代理、应用程序缓存、数据库？