StackExchangeRedis NHibernate二级缓存为何需锁机制？能否禁用？

一、为什么StackExchangeRedis的NHibernate二级缓存需要锁机制？ #

分布式缓存场景下，当热点缓存Key失效时，会出现多个请求同时绕过缓存直接查询数据库的情况（即缓存击穿），短时间内大量请求打向数据库，可能导致数据库压力过载甚至宕机。

StackExchangeRedis的NHibernate二级缓存提供者内置锁机制，核心作用是：

• 当缓存失效时，只允许第一个请求去数据库加载数据并更新缓存
• 其他请求会等待锁释放，之后直接读取更新后的缓存
• 避免重复查询数据库，降低数据库并发压力，同时保证缓存数据的一致性

二、为什么其他Redis缓存提供者（如NHibernate.Caches.CoreDistributedCache.Redis）没有锁机制？ #

不同缓存提供者的设计定位和场景覆盖不同：

• CoreDistributedCache.Redis是基于通用分布式缓存抽象实现的，更偏向基础缓存能力，把并发控制的责任交给上层应用或业务逻辑，而非缓存本身
• StackExchangeRedis的NHibernate提供者是专门针对NHibernate二级缓存的生命周期和并发加载场景做的深度适配，默认内置锁来匹配NHibernate的缓存使用逻辑

三、哪些场景必须依赖锁机制？ #

如果你的应用存在以下情况，锁机制是必要的：

• 高并发访问热点数据：比如秒杀活动、热门商品详情页，缓存失效后若无锁，瞬间会有大量请求打向数据库
• 数据更新频率低但访问量极高：缓存失效后的并发查库代价极大，锁能有效减少数据库压力
• 对缓存一致性要求严格：锁可以保证同一时刻只有一个请求更新缓存，避免多个请求同时更新导致的缓存数据不一致问题

四、能否将锁机制覆写为无操作（no-op）？ #

可以，但需要先评估自身场景的风险：

• 如果你的应用是低并发场景，或者热点数据极少，缓存击穿的概率极低，去掉锁几乎不会有影响
• 如果你的数据库能承受缓存失效后的短暂峰值压力，也可以安全移除锁

覆写示例 #

自定义缓存提供者，重写锁相关方法：

public class NoLockStackExchangeRedisCache : StackExchangeRedisCache
{
    public NoLockStackExchangeRedisCache(string regionName, IDictionary<string, string> properties, ISerializer serializer) 
        : base(regionName, properties, serializer)
    {
    }

    // 重写锁方法，直接返回成功
    public override bool Lock(string key, TimeSpan timeout) => true;

    // 重写解锁方法，无实际操作
    public override void Unlock(string key) { }
}

之后在NHibernate配置中注册这个自定义缓存提供者即可。

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