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

缓存通常被用作一种通用的解决方案，当我们考虑改善依赖服务调用的延迟和可用性特征时。由于我们避免了依赖服务的网络往返，延迟得到了改善；由于缓存提供了我们需要的响应，我们不必担心依赖服务的临时停机，因此可用性得到了改善。需要注意的是，如果我们每次都对依赖服务的请求产生不同的响应，或者客户发送的请求类型完全不同，响应之间没有太多的重叠，缓存是无用的。假如我们的服务不能容忍旧的数据，那么缓存的使用也会受到其他限制。?

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

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

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

对于客户端来说，重要的是不要将缓存视为“可有可无”的优化，而是将缓存视为需要像传统服务一样对待和审查的关键组成部分。这包括监控和报警缓存命中率阈值和发送到依赖服务的整体流量。?

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

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

同样，在服务方面，需要实施负载减少机制，以防止服务过载。在这种情况下，过载意味着服务不能在客户加班时间内响应。请注意，随着服务负荷的增加，通常会出现延迟增加，因为服务器资源被过度使用，导致响应速度减慢。我们希望在客户要求加班前做出响应。如果整体延迟开始超过客户加班，则开始拒绝要求。?

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

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

以上是明智的缓存：如何防止分布式系统故障的详细信息，请更多地关注其他相关文章！