使用 NGINX Plus 缓存集群实现共享缓存（第 2 部分）

编辑器– 这是有关高容量和高可用性缓存的系列文章的第二部分：

• 使用 NGINX Plus 缓存集群的共享缓存，第 1 部分
• 使用 NGINX Plus 缓存集群的共享缓存，第 2 部分（本帖）

如何使用 NGINX 或 NGINX Plus 构建大容量、高可用性缓存集群？ 这篇文章介绍了如何使用两个或多个 NGINX 或 NGINX Plus 缓存服务器来创建高可用性缓存集群。 （除非另有说明，此处描述的方法同样适用于 NGINX Open Source 和 NGINX Plus，但为了简洁起见，我们仅提及 NGINX Plus。）

评论——分片缓存解决方案

本系列的第一部分描述了创建非常大的分片缓存集群的模式。

当您需要创建一个可随意扩展的大容量缓存时，此模式非常有效。 由于每个资源仅缓存在一台服务器上，因此它不是完全容错的，但是一致性哈希负载平衡可以确保如果服务器发生故障，则只有其缓存内容的份额会失效。

创建高可用性缓存集群

如果您的首要目标是不惜一切代价地减少对原始服务器的请求数量，那么缓存分片解决方案并不是最佳选择。 相反，通过精心配置主 NGINX Plus 实例和辅助 NGINX Plus 实例的解决方案可以满足您的要求：

主 NGINX Plus 实例接收所有流量并将请求转发到辅助实例。 辅助实例从原始服务器检索内容并缓存它；主实例还缓存来自辅助服务器的响应并将其返回给客户端。

两个设备都具有完全填充的缓存，并且缓存会根据您配置的超时时间进行刷新。

配置主缓存服务器

配置主缓存服务器以将所有请求转发到辅助服务器并缓存响应。 正如上游组中服务器指令的备份参数所示，当辅助服务器发生故障时，主服务器会将请求直接转发到原始服务器：

proxy_cache_path /tmp/mycache keys_zone=mycache:10m; server { status_zone mycache; # 用于 NGINX Plus 扩展状态 listen 80; proxy_cache mycache; proxy_cache_valid 200 15s; location / { proxy_pass http://secondary; } } upper secondary { zone secondary 128k; # 用于 NGINX Plus 扩展状态 server 192.168.56.11; # 辅助服务器 192.168.56.12 backup ; # 原点 }

配置二级缓存服务器

配置辅助缓存服务器以将请求转发到源服务器并缓存响应。

proxy_cache_path /tmp/mycache keys_zone=mycache:10m;
server {
status_zone mycache; # 用于 NGINX Plus 扩展状态

listen 80;

proxy_cache mycache;
proxy_cache_valid 200 15s;

location / {
proxy_pass http://origin;
}
}

upstream origin {
zone origin 128k; # 用于 NGINX Plus 扩展状态

server 192.168.56.12; # 来源
}

配置高可用性

最后，您需要配置高可用性 (HA)，以便主服务器发生故障时辅助服务器接收传入流量；主服务器随后恢复时收回流量。

在此示例中，我们使用NGINX Plus 的主动被动 HA 解决方案。 对外通告的虚拟IP地址为192.168.56.20，主缓存服务器作为集群中HA的主节点。 如果您正在使用 NGINX 开源，则可以手动安装和配置keepalived或其他 HA 解决方案。

故障转移方案

回想一下，我们想要创建一个高可用性缓存集群，即使缓存服务器出现故障，它也能继续运行。 我们不希望原始服务器上的负载增加，无论是当缓存服务器发生故障还是当其恢复并需要刷新陈旧内容时。

假设主服务器出现故障， NGINX Plus HA 解决方案会将外部 IP 地址转移到辅助服务器。

辅助数据库具有完整的缓存并继续正常运行。 原始服务器上没有额外的负载。

当主缓存服务器恢复并开始接收客户端流量时，其缓存将过时并且许多条目将过期。 主服务器将从辅助缓存服务器刷新其本地缓存；由于辅助服务器上的缓存已经是最新的，因此原始服务器的流量不会增加。

现在假设次级设备发生故障。 主服务器检测到这种情况（使用作为 HA 解决方案的一部分配置的健康检查）并将流量直接转发到备份服务器（即原始服务器）。

主服务器具有完整的缓存并继续正常运行。 再次强调，原始服务器上没有额外的负载。

当辅助服务器恢复时，其缓存将会过时。 但是，只有当主服务器的缓存过期时，它才会接收来自主服务器的请求，此时辅助服务器的副本也将过期。 尽管辅助服务器需要从原始服务器请求内容，但这不会增加对原始服务器的请求频率。 对源服务器没有不利影响。

测试故障转移行为

为了测试我们的 HA 解决方案，我们配置原始服务器来记录请求并返回每个请求的当前时间。 这意味着原始服务器的响应每秒都会发生变化：

access_log /var/log/nginx/access.log;
location / {
return 200 "现在是 $time_localn";
}

主缓存服务器和辅助缓存服务器已配置为缓存带有状态代码的响应200持续 15 秒。 这通常会导致缓存每 15 或 16 秒更新一次。

代理缓存有效 200 15秒；

验证缓存行为

每秒一次，我们向缓存集群的高可用性虚拟 IP 地址发送 HTTP 请求。 直到主服务器和辅助服务器上的缓存过期并且从原始服务器刷新响应时，响应才会改变。 这种情况每 15 或 16 秒发生一次。

$ while sleep 1 ; do curl http://192.168.56.20/ ; done现在是 9/Feb/2017:06:35:03 -0800 现在是 9/Feb/2017:06:35:03 -0800 现在是 9/Feb/2017:06:35:03 -0800 现在是 9/Feb/2017:06:35:03 -0800 现在是 9/Feb/2017:06:35:19 -0800 现在是 9/Feb/2017:06:35:19 -0800 ^C

我们还可以检查源服务器上的日志，以确认它每 15 或 16 秒仅接收一次请求。

验证故障转移

我们可以通过停止主服务器或辅助服务器（例如，停止nginx进程）来验证故障转移是否正常工作。 恒定负载测试继续运行，并且响应被一致缓存。

检查源服务器上的访问日志可确认无论哪个缓存服务器发生故障或恢复，它每 15 到 16 秒仅接收一次请求。

缓存更新的时间

在稳定的情况下，缓存内容通常每 15 到 16 秒更新一次。 内容在 15 秒后过期，并且在收到下一个请求之前最多会有 1 秒的延迟，从而导致缓存更新。

有时，缓存更新速度会显得比较慢（内容更改间隔最多为 30 秒）。 如果主缓存服务器的内容过期，并且主缓存服务器从辅助缓存服务器检索即将过期的缓存内容，就会发生这种情况。 如果这出现问题，您可以在辅助服务器上配置更短的缓存超时。

概括

按照我们在此处描述的方式在两个或多个 NGINX 缓存服务器之间分层缓存是创建高可用性缓存集群的有效方法，该集群可最大限度地减少原始服务器上的负载，并在其中一个缓存服务器发生故障或恢复时保护它们免受流量高峰的影响。

缓存的总容量受限于单个缓存服务器的容量。 本系列的第一部分介绍了一种替代的分片缓存模式，该模式在缓存服务器集群中对缓存进行分区。 在这种情况下，总容量是所有缓存服务器的总和，但不会复制内容，以防止在缓存服务器发生故障时原始服务器的流量激增。

在您自己的服务器上试用高可用性缓存 - 立即开始30 天免费试用或联系我们讨论您的用例。