ASP.NET Core 内存缓存实战：一篇搞懂该怎么配、怎么避坑

Tue, 16 Jun 2026 17:04:23 +0800

引言

这篇文章我们来聊一聊 asp.net core 的内存缓存。asp.net core 内存缓存（IMemoryCache）是一个轻量级的缓存方案，适用于单实例应用或者分布式环境中的本地缓存。它提供了简单的 API 来存储和检索数据，同时支持过期策略、优先级设置等功能。

什么是缓存

从用户请求到数据库返回数据，这是一个漫长的过程（夸张了点，通常也就是几十毫秒到几百毫秒）。可是又不止一个用户在访问，甚至同一个用户在短时间内发起多个相似请求，这时候每次都走完整个流程就显得很浪费了。缓存的作用就是把之前请求的结果存储起来，下次有相同请求时直接返回缓存结果，省去重复计算和数据库访问的开销。所以，缓存是一个存储机制，使用它的目的是为了提高性能和响应速度。

asp.net core 中的缓存类型

在 asp.net core 中，提供了三种常用的缓存方案：

内存缓存（IMemoryCache）：适用于单实例应用或者分布式环境中的本地缓存。
分布式缓存（IDistributedCache）：适用于分布式环境中的共享缓存，常见实现有 Redis、SQL Server 等。
Hybrid 缓存：结合内存缓存和分布式缓存，先查内存缓存，未命中再查分布式缓存。

每一类的缓存都有自己的使用场景和适用边界，选择合适的缓存方案是非常重要的。

asp.net core 的内存缓存 IMemoryCache

asp.net core 的内存缓存使用本地内存来临时存储数据，所以它的访问速度非常快，通常远快于网络和数据库访问（具体耗时取决于数据大小与序列化开销）。但是内存缓存也有一些限制，不能在多实例中共享数据。此外，内存缓存的数据会随着应用重启而丢失，所以它更适合存储一些临时数据或者不需要持久化的数据。存放在本机内存中，会占用服务器的内存资源，如果缓存的数据量过大或者过期策略设置不当，可能会导致内存压力增大、频繁回收或者性能问题。因此，在使用内存缓存时需要注意以下几点：

不要将外部输入作为缓存键，因为这类输入可能会消耗不可预测的内存资源，导致缓存被恶意攻击或者误用。
设置合理的过期时间限制缓存的增长。
限制缓存的大小，避免占用过多内存资源。

在 asp.net core 中使用 IMemoryCache

在 asp.net core 中使用 IMemoryCache 非常简单，首先需要在 Program.cs 中注册服务：

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddMemoryCache();

然后在需要使用缓存的地方注入 IMemoryCache：

public class MyService
{
    private readonly IMemoryCache _cache;
    public MyService(IMemoryCache cache)
    {
        _cache = cache;
    }
    public async Task<string> GetDataAsync(string key)
    {
        if (_cache.TryGetValue(key, out string value))
        {
            return value; // 从缓存中获取数据
        }
        else
        {
            value = await FetchDataFromDatabaseAsync(key); // 从数据库获取数据
            _cache.Set(key, value, TimeSpan.FromMinutes(5)); // 将数据存入缓存，设置过期时间为5分钟
            return value;
        }
    }
}

在上面的示例中，我们首先尝试从缓存中获取数据，如果缓存命中就直接返回，否则就从数据库获取数据，并将结果存入缓存中，设置过期时间为5分钟。这样下次有相同请求时，就可以直接从缓存中获取数据，提高性能和响应速度。

Redis：延迟双删的适用边界与落地细节

Tue, 16 Jun 2026 17:04:23 +0800

延迟双删不是新概念，但线上一出缓存脏读，我曾经在项目中把它当成标准答案直接套进去。结果通常是代码写了两次删除，问题却没真正收住。

这篇就聚焦一个知识点：延迟双删到底解决什么问题，为什么它只能改善最终一致概率，以及在 .NET 服务里怎么把第二次删除做得更稳一点。

1. 问题背景：数据库已经更新，为什么缓存里还是旧值

聊一个高频场景：商品详情页读 Redis，后台商品编辑写数据库。读流量远大于写流量，最常见的缓存策略是 Cache Aside。

我的更新代码长这样：先更新数据库，再删除缓存。平时看起来没什么问题，但高并发下还是会偶发脏数据。业务侧看到的现象一般是：管理后台已经改价成功，前台用户短时间内还能查到旧价格。

关键不在“删没删缓存”，而在并发时序。

一个典型过程是这样的：

线程 A 更新数据库中的商品价格
线程 A 删除 Redis 中的商品缓存
线程 B 正好在这个空档读缓存未命中，开始查数据库
线程 B 读到的仍然是旧值，或者读到了事务提交前的旧快照
线程 B 把旧值重新写回 Redis

这时候数据库是新值，缓存却又变回旧值了。问题根因不是删除动作本身，而是删除之后，旧数据又被别的请求回填进缓存。

如果只看文字，这个并发窗口不算直观。把它画成时序图会更清楚：

sequenceDiagram
    autonumber
    participant A as 写线程A
    participant R as Redis
    participant D as Database
    participant B as 读线程B

    A->>D: 更新商品价格为新值
    A->>R: 删除商品缓存
    B->>R: 读取商品缓存
    R-->>B: 未命中
    B->>D: 查询商品数据
    D-->>B: 返回旧值或旧快照
    B->>R: 回填旧值到缓存
    B-->>B: 后续请求命中旧缓存

这张图里最关键的不是“删缓存”这一步，而是删完之后到下一次稳定回填新值之前，中间存在一个旧值重新进入 Redis 的窗口。延迟双删补的就是这个窗口。

Caching on Coding with Denglei