☰

当服务器设置 cookie 时使用 NGINX 处理缓存

tag-icon • tag-icon nginx reverse-proxy cache
当服务器设置 cookie 时使用 NGINX 处理缓存

我使用NGINX 微缓存。

但是，我仍然不确定如何最好地处理带有Set-Cookie标头的服务器响应。

  • Set-CookieNGINX 是否可以缓存带有标头的原始服务器的响应？

如果答案是否定的，并且Set-Cookie响应应该始终绕过缓存层，这将对性能产生非常负面的影响。

例如，当您访问运行 WooCommerce 的普通电子商务网站时，这些 cookie 会在您第一次访问时设置：

设置Cookie：PHPSESSID = xxyy

设置 Cookie：wp_woocommerce_session_xx=yy

如果将Set-Cookie响应排除在缓存之外，这意味着缓存的内容将永远不会在任何电子商务商店首次访问时提供。

此外，在 WooCommerce 商店浏览产品时，插件会设置woocommerce_recently_viewed=xxxxcookie。cookiewoocommerce_recently_viewed会在每个产品视图上更新，因此对其他产品的所有后续请求都会导致服务器包含标Set-Cookie头。

  • 在这种情况下可以启用缓存吗？

我在 NGINX 中使用的一些默认缓存配置包括：

  if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
    set $skip_cache 1;
  }

如果我将woocommerce_recently_viewedcookie 包含在列表中，则大多数情况下缓存都会被绕过。

  • 在这种情况下，处理缓存和 cookie 的最佳做法是什么？

答案1

一般来说，缓存对动态内容的效果很差，尤其包含“最近查看”等内容的内容会在每次加载单个页面时发生变化。如果您确实想使用缓存，那么第一步是禁用该插件，这样就有可能有人两次看到同一个页面。第二步是仅在有人执行需要会话的操作时才启动会话：登录、将商品放入购物车等。从此时起，您必须在创建会话 cookie 后停止缓存（否则，如果客户只访问缓存一小会儿，则会话在客户和服务器端都会过期）。

我认为对于此类内容，最好在应用程序本身中进行缓存。应用程序应该了解网页的哪些部分是动态的，每次加载页面时都需要重新生成，并且可以将新旧部分组合成网页，以便为用户提供正确的响应。

答案2

DerfK 关于动态内容的说法是正确的完整页面级别，您绝对不希望发生 cookie 泄漏。

但是，您可以在上游层进行更多缓存 - 具体来说，对于 WordPress，它有一个不错的可插入对象缓存。这意味着，虽然页面本身不会被缓存，但您可以将大部分数据库负载存储在临时存储中，例如 memcached (batcache) 或 redis。这些 KV 存储比 MySQL 快得多，而且由于它们在对象和应用程序级别工作，因此它们不会直接受到 WooCommerce 发送的 cookie 的影响。

相关内容