我正在考虑使用文件路径和可能的原始 sql 作为我的 asp.net HttpContext 缓存中的缓存键的想法。这些项目只会被缓存几分钟。
我的问题是我是否会遇到错误缓存的数据以及频率。在单用户测试环境中，一切似乎都很顺利，但如果多个用户处于负载状态，会发生什么情况？
我的直觉告诉我这是一个坏主意，但当我试图确认这是一个坏主意时，我发现了一些相互矛盾的信息，让我认为它可能没问题。
例如，缓存键没有长度限制，因为缓存键是散列的，并且字典具有内部冲突解决方案。这是否意味着我没事？不正确缓存数据的结果对应用程序来说真的是灾难性的。
【问题讨论】：
标签： c# asp.net .net caching httpcontext
答案是（有点）在您的问题中。缓存键是散列的。缓存键越长，发生冲突的可能性就越大。因此，最好使用较短的缓存键。
我通常采用的方法是使密钥尽可能简洁（但仍然确定且唯一）。这通常意味着以对象类型名称开头，然后是标识对象的键，其间有一个标准化的分隔符。此解决方案可轻松扩展，因为如果您需要以其他方式区分缓存，您只需添加额外信息即可。
// this will be used to cache the instance MyClass with
// ID (key) value of MyClassKey (usually this is a Guid or int)
var key = "MyClass|MyClassKey";
// this will be used to cache the result of the call to
// MyClass.MyFunctionName(Parameter1Value, Parameter2Value);
var key = "MyClass|MyFunctionName|Parameter1Value|Parameter2Value";
附带说明，如果您使用 .NET 框架 4 或更高版本，System.Runtime.Caching 是一个比System.Web.Caching 更健壮且可插拔的框架，它的工作原理非常相似，但不依赖于System.Web。
【讨论】：