FusionCache 新特性：工厂上下文中获取缓存键的设计解析

在分布式缓存系统中，缓存键的管理是一个核心功能。FusionCache 作为一款高性能的.NET缓存库，在最新版本中引入了一项重要改进：允许开发者在工厂方法中直接访问缓存键，这一设计优化了内存使用和性能表现。

背景与问题

在传统缓存操作中，当使用GetOrSet方法时，开发者通常需要在工厂方法中引用外部定义的缓存键变量。这种实现方式虽然可行，但会带来两个显著问题：

1. 闭包分配问题：Lambda表达式捕获外部变量会导致额外的内存分配
2. 静态Lambda限制：由于变量捕获的存在，无法使用静态Lambda表达式，错失了性能优化机会

此外，当配合使用CacheKeyPrefix功能时，实际使用的缓存键可能与开发者传入的原始键不同，这增加了获取准确键值的复杂度。

解决方案设计

FusionCache通过扩展工厂上下文(FusionCacheFactoryExecutionContext)的方式，新增了两个关键属性：

public string Key { get; }       // 处理后的完整缓存键
public string OriginalKey { get; } // 原始传入的缓存键

这种设计带来了多重优势：

1. 消除闭包：开发者不再需要从外部作用域捕获变量
2. 支持静态Lambda：现在可以将工厂方法标记为static以获得性能提升
3. 键值透明性：明确区分原始键和处理后的键，便于调试和日志记录

实现细节

在实际使用中，当CacheKeyPrefix未设置时，Key和OriginalKey属性将返回相同的值。这种设计保持了向后兼容性，同时为需要前缀的场景提供了明确的支持。

示例用法：

var cacheKey = "user_123";
cache.GetOrSet<string>(
    cacheKey,
    static (ctx, ct) => {
        var processedKey = ctx.Key;       // 如"MyApp:user_123"
        var originalKey = ctx.OriginalKey; // "user_123"
        return FetchUserData(originalKey);
    }
);

命名规范考量

在属性命名上，开发团队经过慎重考虑：

1. Key：沿用项目内部一贯的命名约定，代表最终处理后的缓存键
2. OriginalKey：明确表示用户原始传入的键值

这种命名方式与FusionCache现有的日志、追踪和事件系统保持了一致性，同时通过XML注释提供了充分的说明，确保开发者能够清晰理解两者的区别。

性能影响

这一改进对性能有积极影响：

1. 减少内存分配：避免了闭包产生的额外内存开销
2. 优化执行效率：支持静态Lambda带来轻微的性能提升
3. 降低GC压力：减少了短期对象的产生

对于高频调用的缓存操作，这些优化累积起来可以带来可观的性能提升。

总结

FusionCache通过这项改进，不仅解决了开发者在实际使用中遇到的痛点，还提升了整体性能表现。这种设计体现了API设计的一致性和对性能细节的关注，是缓存库设计中值得借鉴的实践。

对于需要极致性能的场景，开发者现在可以结合static修饰符使用这一特性，同时保持代码的清晰和可维护性。这为构建高性能.NET应用提供了又一个有力的工具。