ASP.NET Core 2.1 API缓存优化：Redis之上新增缓存层方案咨询

Hey there! Let's walk through the practical caching layers you can add on top of your existing Redis setup for your ASP.NET Core 2.1 API hosted on Azure App Service. Since you can't manage server resources directly, all these options play nicely with App Service's managed environment:

1. In-Memory Caching (ASP.NET Core's Built-In) #

This is the most straightforward option—leverage ASP.NET Core's native IMemoryCache to store frequently accessed static user data (like avatars, basic profile info) directly in your app instance's memory.

• How to implement: Inject IMemoryCache into your services/repositories, and adjust your data retrieval flow to check memory first, then Redis, then the database. Set a shorter expiration for the in-memory cache (e.g., 5-10 minutes) to balance performance and consistency across App Service's multiple instances.
• Code snippet example:

  public async Task<UserAvatar> GetUserAvatarAsync(Guid userId)
  {
      var cacheKey = $"Avatar_{userId}";
      
      // Check in-memory cache first
      if (_memoryCache.TryGetValue(cacheKey, out UserAvatar cachedAvatar))
      {
          return cachedAvatar;
      }
  
      // Fall back to Redis
      cachedAvatar = await _redisCache.GetAsync<UserAvatar>(cacheKey);
      if (cachedAvatar != null)
      {
          // Populate in-memory cache with a short TTL
          _memoryCache.Set(cacheKey, cachedAvatar, TimeSpan.FromMinutes(5));
          return cachedAvatar;
      }
  
      // Final fallback: database
      cachedAvatar = await _dbContext.UserAvatars.FindAsync(userId);
      if (cachedAvatar != null)
      {
          // Update both layers of cache
          await _redisCache.SetAsync(cacheKey, cachedAvatar, TimeSpan.FromHours(24));
          _memoryCache.Set(cacheKey, cachedAvatar, TimeSpan.FromMinutes(5));
      }
      return cachedAvatar;
  }
  

• Pros: Zero extra cost, fastest access speed, fully compatible with App Service.
• Cons: Cache isn't shared across multiple App Service instances, so set a short TTL to minimize data inconsistency if user data updates.

2. Azure CDN (Content Delivery Network) #

If your user avatars and static data are stored in Azure Blob Storage (or you can migrate them there), Azure CDN is a game-changer. Instead of your API returning the avatar binary data, have it return a CDN URL pointing to the asset. Clients will pull directly from the CDN, completely bypassing your API, Redis, and database.

• How to implement:
  1. Configure a CDN profile and endpoint with your Blob Storage container as the origin.
  2. Set cache rules (e.g., cache avatars for 30 days). When a user updates their avatar, rename the blob or append a version query string (like avatar.jpg?v=2) to trigger a CDN refresh for that asset.
• Pros: Offloads 99% of static resource requests from your stack, global edge nodes improve user experience, drastically reduces Redis and database load.
• Cons: Requires storing assets in a CDN-accessible source (like Blob Storage) instead of the database.

3. Response Caching (For API Endpoints) #

Cache the full HTTP response of your static data endpoints to avoid reprocessing requests entirely. ASP.NET Core 2.1 doesn't have built-in output caching middleware, but you can use the official Microsoft.AspNetCore.ResponseCaching package.

• How to implement:
  1. Add the response caching service in Startup.cs:

     public void ConfigureServices(IServiceCollection services)
     {
         services.AddResponseCaching();
         // ... other services
     }
     

  2. Enable middleware in the pipeline:

     public void Configure(IApplicationBuilder app)
     {
         app.UseResponseCaching();
         // ... other middleware
     }
     

  3. Apply the [ResponseCache] attribute to your controller methods:

     [HttpGet("avatar/{userId}")]
     [ResponseCache(Duration = 300, Location = ResponseCacheLocation.Any)] // Cache for 5 minutes
     public async Task<IActionResult> GetUserAvatar(Guid userId)
     {
         var avatar = await _avatarService.GetUserAvatarAsync(userId);
         return avatar == null ? NotFound() : File(avatar.Data, avatar.ContentType);
     }
     

• Pros: Caches entire responses, reduces API processing overhead, clients will also cache responses if configured.
• Cons: Need to invalidate cached responses manually when user data updates (e.g., using cache tags or triggering a refresh).

4. Azure App Service Local Cache #

App Service offers a persistent local cache that stores data on the instance's local disk (instead of shared storage). You can serialize static user data to files in this cache directory for faster access than Redis.

• How to implement: Enable local cache in your App Service configuration (under "Configuration" > "General settings"), then use IFileProvider or custom file-based caching logic to read/write cached data.
• Pros: More persistent than in-memory cache (survives app restarts, not just instance recycles), faster access than Redis.
• Cons: Cache is lost when the App Service instance is recycled, and data isn't shared across instances—best for extremely static, rarely updated data.

Recommended Approach #

For most scenarios, combine Azure CDN (for static assets like avatars) with In-Memory Caching as a front layer for Redis. This gives you the best of both worlds: offloading most requests to the CDN, while reducing Redis hits for any remaining API-driven data access. For API endpoints returning static data, add Response Caching to further cut down on processing.

内容的提问来源于stack exchange，提问作者Sam