缓存可以以低成本提供可用性和延迟方面的直接好处。但是，如果忽略我们上面讨论的方面，则在缓存发生故障时可能会暴露隐藏的扩展瓶颈，从而可能导致系统故障。定期检查以确保系统在缓存发生故障时也能正常运行，这对于防止可能影响系统可靠性的灾难性中断至关重要。

当我们考虑改善依赖服务调用的延迟和可用性特性时，缓存通常被用作一种通用解决方案。由于我们避免了对依赖服务进行网络往返，因此延迟有所改善；由于缓存提供了我们所需的响应，我们无需担心依赖服务的临时停机，因此可用性有所改善。需要注意的是，如果我们对依赖服务的请求每次都导致不同的响应，或者客户端发出的请求类型截然不同且响应之间没有太多重叠，则缓存无济于事。如果我们的服务无法容忍陈旧数据，那么使用缓存还会受到其他限制。 

我们不会深入探讨缓存类型、技术和适用性，因为这些内容在互联网上已经广泛介绍过了。相反，我们将重点讨论缓存中较少被提及的风险，这些风险在系统发展过程中被忽视，而这会使系统面临大面积中断的风险。 

何时使用缓存

在许多情况下，部署缓存是为了掩盖依赖服务的已知扩展瓶颈，或者缓存接管这一角色，以隐藏依赖服务随着时间的推移可能出现的扩展缺陷。例如，当我们的服务开始减少对依赖服务的调用时，他们开始相信这是稳定状态流量的常态。如果我们的缓存命中率为 90%，这意味着对依赖服务的 9/10 次调用都由缓存提供，那么依赖服务只能看到 10% 的实际流量。如果客户端缓存由于中断或错误而停止工作，依赖服务的流量将激增 9 倍！在几乎所有情况下，这种流量激增都会使依赖服务过载，从而导致中断。如果依赖服务是数据存储，这将导致依赖该数据存储的多个其他服务瘫痪。

为了防止此类中断，客户端和服务都应考虑遵循建议来保护他们的系统。 

建议

对于客户端来说，重要的是不要再将缓存视为“可有可无”的优化，而是将其视为需要与常规服务一样对待和审查的关键组件。这包括对缓存命中率阈值以及发送到依赖服务的整体流量进行监控和报警。 

对缓存业务逻辑的任何更新或更改也需要在开发环境和预生产阶段经过同样严格的测试。部署到参与缓存的服务器时，应确保存储的状态已转移到部署后即将启动的新服务器，或者部署期间缓存命中率的下降对于依赖服务来说是可以容忍的。如果在部署期间关闭大量缓存服务服务器，则可能导致缓存命中率成比例下降，从而给依赖服务带来压力。 

客户端还需要实施防护措施来控制流向依赖项服务的整体流量（以每服务事务数 (TPS) 来衡量）。当缓存队列出现故障时，令牌桶等算法可以帮助限制来自队列的 TPS。这需要通过关闭缓存实例并查看客户端如何向依赖项服务发送流量来定期进行测试。客户端还应考虑实施具有较小生存时间 (TTL) 的负缓存策略。负缓存意味着客户端将存储来自依赖项服务的错误响应，以确保依赖项服务在长时间中断时不会受到重试请求的轰炸。 

同样，在服务端，需要实施负载削减机制来防止服务过载。在这种情况下，过载意味着服务无法在客户端超时内做出响应。请注意，随着服务负载的增加，通常表现为延迟增加，因为服务器资源被过度使用，导致响应速度变慢。我们希望在客户端请求超时之前做出响应，如果总体延迟开始超过客户端超时，则开始拒绝请求。 

有多种技术可以防止过载；最简单的技术之一是限制从应用程序负载均衡器 ( ALB ) 到服务主机的连接数。但是，这可能意味着不加区分地丢弃请求，如果不希望这样，则可以在服务的应用程序层实施优先级技术以丢弃不太重要的请求。负载削减的目标是确保服务在服务的整体负载增加时保护有效吞吐量，即在客户端超时内提供的请求。服务还需要定期运行负载测试以验证服务主机处理的最大 TPS，这允许对 ALB 连接限制进行微调。我们介绍了几种保护服务有效吞吐量的技术，这些技术应该可以广泛应用，但读者可以根据自己的服务需求探索更多方法。

结论

缓存可以以低成本提供可用性和延迟方面的直接好处。但是，如果忽略我们上面讨论的方面，则在缓存发生故障时可能会暴露隐藏的扩展瓶颈，从而可能导致系统故障。定期检查以确保系统在缓存发生故障时也能正常运行，这对于防止可能影响系统可靠性的灾难性中断至关重要。