Azure Redis缓存故障转移与陈旧数据：如何程序化清理缓存？

我在项目中使用分布式Azure Redis缓存，启动配置如下：

if (cacheEnvironmentLocal.HasValue && cacheEnvironmentLocal.Value)
{
    services.AddDistributedMemoryCache();
}
else
{              
    services.AddStackExchangeRedisCache(options =>
    {
     options.Configuration = cacheConnectionString;
    });
}

我使用的AddStackExchangeRedisCache已默认实现重试、超时策略及ForceReconnect机制。当前采用Azure Redis标准层，包含主、从两个节点，多数情况下至少一个节点可用，但在硬件或网络故障导致缓存暂时不可用时，可能出现双节点故障。

我担忧的场景：缓存不可用时执行Remove操作抛出异常，后续缓存恢复后，缓存中仍留存陈旧数据，下次获取该值时会导致应用异常。Get和Set操作可通过捕获异常继续执行，但Remove操作失败会遗留陈旧数据问题，我的Remove函数代码如下：

/// <summary>
/// Removes the object from the cache.
/// </summary>
/// <typeparam name="T">Type of the vaule.</typeparam>
/// <param name="id">Id of the object.</param>
public void Remove<T>(string id)
    where T : class
{
    var key = GenerateKey(id, GetTypeName<T>());
    if (string.IsNullOrEmpty(key))
    {
        logger.Warning("Id or type for the cache were not provided properly");
        return;
    }

    try
    {
       distributedCache.Remove(key);
    }
    catch(Exception e)
    {
        logger.Error(new CacheException(Error_02.CacheRemoveFailed, e));
    }
}

目前我对Get、Set、Remove操作均采取捕获异常后继续执行的处理方式。查阅多篇官方文档后仍未找到答案，现咨询：当此类缓存故障发生时，能否通过程序化方式执行FLUSHDB清理缓存，确保缓存恢复后数据干净？

1. 程序化执行FLUSHDB的可行性 #

可以通过代码执行FLUSHDB，但存在明显的风险和限制：

• FLUSHDB会清空当前Redis数据库的所有缓存数据，缓存恢复后大量请求会直接穿透到后端数据库，可能引发缓存雪崩，造成数据库短期压力过载。只有当你的业务能承受这种冲击时，才考虑使用该方式。
• 实现方式：借助StackExchange.Redis的IDatabase对象直接执行命令，示例代码如下：

var redisConn = ConnectionMultiplexer.Connect(cacheConnectionString);
var db = redisConn.GetDatabase();
db.Execute("FLUSHDB");

需注意：必须在确认缓存完全恢复正常后再执行，避免在故障期间加重服务负担。

2. 更稳妥的替代方案 #

相比全量清空，针对问题数据的精准处理更合理：

• 记录失败的删除任务：在Remove操作捕获异常时，将需要删除的key存入持久化存储（如数据库、Azure队列）。待缓存恢复后，通过后台定时任务批量重试这些删除操作，仅清理确实需要移除的陈旧数据。
• 给缓存key设置过期时间：在Set缓存时统一配置合理的过期时间，即使Remove操作失败，陈旧数据也会自动过期，避免长期留存。这是缓存容错的基础手段，能有效降低删除失败的影响。
• 缓存数据版本化：将缓存key设计为{类型标识}:{ID}:{版本号}的格式，数据更新时同步升级版本号。后续Get操作只会读取对应最新版本的缓存，旧版本的key即使存在也不会被访问，无需强制删除。

3. Azure Redis故障恢复的注意事项 #

Azure Redis标准层双节点故障恢复后，服务会自动完成主从数据同步，但故障期间的操作失败可能导致数据不一致：

• 故障期间不要频繁执行清理或补偿操作，避免增加服务恢复的负担。
• 通过Azure Monitor监控缓存的连通状态，当检测到服务恢复正常后，再触发对应的补偿逻辑。

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