为何不能将Redis缓存设为永久有效，仅在数据库修改时同步？

核心结论 #

对于你提到的每2个月才更新一次的表，可以采用接近永久的缓存策略，但不建议完全取消过期时间——技术文章强调设置过期时间，本质是为了应对缓存与数据库不一致的极端场景，而你的“变更时删除缓存”逻辑如果可靠，超长过期时间既能满足性能需求，又能保留兜底机制。

为什么技术文章都强调设置过期时间？ #

这些建议主要是为了规避以下风险：

• 缓存同步故障兜底：如果你的缓存删除逻辑出现bug（比如异步删除失败、分布式事务导致的不一致），过期时间会自动让缓存失效，拉取最新数据，避免长期使用脏数据。
• Redis内存压力：永久缓存会持续占用内存，若后续业务调整导致数据量增大或更新频率变高，可能引发Redis内存不足问题。
• 业务变更风险：当前更新频率低不代表永远如此，万一后续业务调整忘记修改缓存策略，过期时间能减少脏数据影响范围。
• Redis数据恢复问题：如果Redis重启后持久化数据未恢复，永久缓存的键不会自动重建（除非有访问触发），低频访问的表可能很久才会触发重建，期间会一直直接查询数据库。

针对你的场景的优化建议 #

结合你提供的代码，给出具体调整方案：

1. 给低频表配置超长过期时间（替代完全永久） #

不要完全取消过期时间，而是给低频表设置6个月甚至更长的绝对过期时间，既接近“永久”，又保留兜底能力。可以通过泛型判断或配置文件区分不同实体的缓存策略：

public CachedRepository(IRepository<T> repository, IDistributedCache dcache)
{
    _repository = repository;
    _distributedCache = dcache;

    DistributedCacheEntryOptions expiration;
    // 根据实体类型判断是否为低频表
    if (typeof(T) == typeof(LowFrequencyEntity)) // 替换成你的低频实体类型
    {
        expiration = new DistributedCacheEntryOptions
        {
            AbsoluteExpirationRelativeToNow = TimeSpan.FromDays(180) // 6个月过期
        };
    }
    else
    {
        expiration = new DistributedCacheEntryOptions
        {
            AbsoluteExpirationRelativeToNow = TimeSpan.FromSeconds(30),
            SlidingExpiration = TimeSpan.FromSeconds(25)
        };
    }
    cacheOptions = expiration;
}

2. 提升缓存删除的可靠性 #

你的代码中缓存删除操作未处理异常，建议添加重试和日志记录，避免因缓存删除失败导致数据不一致：

private async Task SafeRemoveCacheAsync(string key)
{
    try
    {
        await _distributedCache.RemoveAsync(key);
    }
    catch (Exception ex)
    {
        // 记录异常日志，便于排查
        // _logger.LogError(ex, "删除缓存键失败: {Key}", key);
        // 可选：重试一次
        try
        {
            await _distributedCache.RemoveAsync(key);
        }
        catch (Exception retryEx)
        {
            // _logger.LogError(retryEx, "重试删除缓存键失败: {Key}", key);
        }
    }
}

然后在Add/Delete/Update方法中调用这个方法替代直接RemoveAsync。

3. 优化缓存键命名规范 #

给缓存键添加统一前缀，避免与其他系统的键冲突，也便于Redis管理：

private string CacheKey = $"Cache:{typeof(T).Name}";
// 单个实体键改为
string key = $"{CacheKey}-{entity.Id}";

4. 处理Redis不可用的降级逻辑 #

当前代码中Redis操作异常会直接抛出，导致业务失败，建议降级到直接查询数据库：

public async Task<T> GetByIdAsync(string id, CancellationToken cancellationToken = default)
{
    try
    {
        string key = $"{CacheKey}-{id}";
        var result = await _distributedCache.GetStringAsync(key);

        var options = new JsonSerializerOptions
        {
            IgnoreReadOnlyFields = true,
            IgnoreReadOnlyProperties = true,
            ReferenceHandler = ReferenceHandler.IgnoreCycles,
            DefaultIgnoreCondition = System.Text.Json.Serialization.JsonIgnoreCondition.WhenWritingNull
        };

        var value = string.IsNullOrEmpty(result) ? default : JsonSerializer.Deserialize<T>(result, options);

        if (value == null)
        {
            var item = await _repository.GetByIdAsync(id);

            if (item is null) 
                return item;

            await _distributedCache.SetStringAsync(key, JsonSerializer.Serialize<T>(item, options), cacheOptions);

            return item;
        }

        return value;
    }
    catch (Exception ex)
    {
        // 记录日志
        // _logger.LogError(ex, "缓存操作失败，降级到数据库查询");
        return await _repository.GetByIdAsync(id);
    }
}

总结 #

对于极低更新频率的表，在确保缓存同步逻辑可靠的前提下，用超长绝对过期时间替代完全永久缓存是更稳妥的选择——既享受了缓存带来的性能提升，又保留了过期时间的兜底能力，能有效规避极端场景下的脏数据问题。

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