Caching Strategies: Redis + CDN + Edge Computing · 课时

缓存降级方案与断路器

通过设计降级方案并使用断路器，实施容错缓存，防止缓存故障影响源站

缓存降级方案与断路器 是 CoddyKit 上的免费 Caching Strategies: Redis + CDN + Edge Computing 课时。这是第 1 节课，共 4 节。你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。这是 Caching Strategies: Redis + CDN + Edge Computing 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 Caching Strategies: Redis + CDN + Edge Computing 课程共包含 4 节课。

本课时的部分内容尚未翻译，以英文显示。

Resilient Caching: An Overview

Caching dramatically improves application performance and scalability. But what if your cache itself fails? A truly robust system needs to handle these failures gracefully.

Resilient caching is about designing your systems to remain stable and responsive even when cache systems encounter issues or become unavailable.

The Problem: Cache Failure

When a cache fails, it can lead to serious problems for your backend services. Without the cache to absorb requests, all traffic might suddenly hit your origin server or database directly.

Cache Stampede: Many requests bypass the cache simultaneously.
Origin Overload: The database or API struggles to handle the sudden surge in traffic.
Cascading Failures: Overloaded origins can fail, leading to more system instability.

Introducing Cache Fallbacks

A cache fallback is a strategy to provide an alternative response when the primary cache is unavailable, returns an error, or even when the origin service fails.

Instead of failing outright or showing an error, your system can serve slightly older data, a default value, or a pre-computed result. This ensures a smoother, more consistent user experience.

Fallback Strategy: Stale-While-Revalidate

The Stale-While-Revalidate HTTP cache control directive is a great example of a fallback. It tells clients (like browsers or CDNs) that they can immediately serve a stale (slightly old) cached response.

Meanwhile, the client or a proxy asynchronously fetches a fresh version in the background. This prevents users from waiting for the revalidation, improving perceived performance.

Cache-Control: max-age=60, stale-while-revalidate=3600

Implementing Cache-Aside Fallback

With the Cache-Aside pattern, your application first checks the cache. If there's a miss, it fetches data from the origin (e.g., database) and then updates the cache.

You can add a fallback in the catch block: if fetching from the origin also fails, provide a default, static, or last-known-good value instead of throwing an error.

public class Main {
  public static String fetchDataWithFallback(String key) {
    try {
      // Simulate attempting to fetch from cache
      String cachedData = null; // Assume cache miss
      if (key.equals("cachedItem")) {
        cachedData = "Cached content for " + key;
      }

      if (cachedData != null) {
        return "Using cache: " + cachedData;
      }

      // Simulate fetching from origin (can fail)
      if (key.equals("failingItem")) {
        throw new RuntimeException("Origin service error!");
      }
      return "From origin: Live content for " + key;

    } catch (Exception e) {
      // Fallback in case of cache miss AND origin failure
      return "Fallback for " + key + " (Error: " + e.getMessage() + ")";
    }
  }

  public static void main(String[] args) {
    System.out.println(fetchDataWithFallback("normalItem"));
    System.out.println(fetchDataWithFallback("cachedItem"));
    System.out.println(fetchDataWithFallback("failingItem"));
  }
}

What are Circuit Breakers?

A circuit breaker pattern prevents an application from repeatedly trying to execute an operation that is likely to fail. It's like an electrical circuit breaker: when a fault is detected, it 'trips' to prevent further damage.

In caching systems, circuit breakers protect the origin server from an onslaught of requests when the cache or the origin itself is struggling, preventing cascading failures.

Circuit Breaker: States & Transitions

A circuit breaker typically operates in three states:

Closed: Operations are allowed. If failures exceed a threshold, it transitions to Open.
Open: Operations are blocked immediately. After a configured timeout, it transitions to Half-Open.
Half-Open: A limited number of test operations are allowed. If successful, it goes back to Closed; otherwise, it returns to Open.

Conceptual Circuit Breaker Logic

Here's a simplified illustration of how a circuit breaker might protect a call to an origin service. Notice how it stops calling the failing service once the circuit is 'tripped'.

public class Main {
  static boolean isOriginHealthy = true; // Simulates origin health
  static boolean circuitBreakerTripped = false;
  static int consecutiveFailures = 0;
  static final int THRESHOLD = 2; // Trip after 2 failures

  public static String fetchDataFromOrigin() {
    if (circuitBreakerTripped) {
      return "Circuit OPEN: Origin call blocked.";
    }
    try {
      if (!isOriginHealthy) { // Simulate origin failing
        throw new RuntimeException("Origin failed!");
      }
      consecutiveFailures = 0; // Reset failures on success
      return "Data from Origin.";
    } catch (RuntimeException e) {
      consecutiveFailures++;
      if (consecutiveFailures >= THRESHOLD) {
        circuitBreakerTripped = true;
        return "Circuit OPEN: Origin failed. Blocking further calls.";
      }
      return "Origin failed, but circuit still closed. " + (THRESHOLD - consecutiveFailures) + " tries left.";
    }
  }

  public static void main(String[] args) {
    System.out.println(fetchDataFromOrigin()); // Success
    isOriginHealthy = false; // Origin becomes unhealthy
    System.out.println(fetchDataFromOrigin()); // Failure 1
    System.out.println(fetchDataFromOrigin()); // Failure 2, trip circuit
    System.out.println(fetchDataFromOrigin()); // Blocked by circuit
  }
}

Combining Fallbacks and Circuit Breakers

For ultimate resilience, you often combine fallbacks and circuit breakers. They serve different but complementary roles:

Circuit breakers prevent hammering a failing service, protecting your backend.
Fallbacks provide a graceful degradation, ensuring users still get some response even when primary data sources are unavailable.

Together, they create a robust defense against system outages and performance degradation.

Check Your Understanding

Consider a scenario where your primary cache server goes down. Many requests then bypass the cache and hit your database directly, causing it to slow down significantly.

Which pattern would primarily prevent the database from being overwhelmed by these direct requests?

Lesson Recap: Resilience

We've learned how to build more resilient caching systems.

Fallbacks provide alternative content when caches or origins fail, maintaining user experience.
Circuit breakers protect your backend services from cascading failures by stopping repeated calls to unhealthy services.

By implementing these patterns, you can significantly enhance the stability and availability of your applications, even under adverse conditions.

常见问题解答

「缓存降级方案与断路器」课时是免费的吗？

是的 — 「缓存降级方案与断路器」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 Caching Strategies: Redis + CDN + Edge Computing 课程的其余内容，请升级到 CoddyKit PRO。 Caching Strategies: Redis + CDN + Edge Computing 课程共包含 4 节课。

「缓存降级方案与断路器」这节课中我会学到什么？

通过设计降级方案并使用断路器，实施容错缓存，防止缓存故障影响源站你通过在浏览器中直接运行的动手代码来练习 Caching Strategies: Redis + CDN + Edge Computing，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 Caching Strategies: Redis + CDN + Edge Computing 需要有经验吗？

无需任何先前经验。CoddyKit 上的 Caching Strategies: Redis + CDN + Edge Computing 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。这是第 1 节课，共 4 节。

「缓存降级方案与断路器」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 Caching Strategies: Redis + CDN + Edge Computing 课中编写并运行代码吗？

能。每节 Caching Strategies: Redis + CDN + Edge Computing 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

← 返回 Caching Strategies: Redis + CDN + Edge Computing