在 ASP.NET 2.0 站点中IIS6我想将键/值对存储在应用程序缓存中。每个键始终是一个长度为 5 个字符的字符串，每个值都是一个长度为 15 - 250 个字符的字符串。
使用场景是，每个网页请求都会查询一次缓存，如果键存在，则使用值，否则查询数据库，并向缓存添加新的键/值，或者根据某些应用程序逻辑替换现有条目。
在这种情况下，我设想/要求缓存大小达到大约 1000 个条目，在该大小下它将变得稳定并且很少（如果有的话）如上所述进行更改。
在我“自己进行性能测试”之前，是否有人有过大量缓存数据的经验，以确定它是否更适合表现 to:
(1) 使用1个包含a的Cache对象SortedDictionary<string, string> or
(2) 允许创建 1,000 个 Cache 对象并将 Cache 本身用作字典或
(3) 这与所讨论的数据量无关。如果条目数量增加到 10,000 或 100,000，在哪种情况下您的答案会改变？
非常感谢。
1000 并不是一个很大的数据量；这可以正常工作，但是如果这些数据在请求之间共享，您将需要考虑同步。现实中一个lock访问Dictionary<string,string>可能没问题，但如果需要，您可以更细粒度。
但是，内置的网络缓存（HttpContext.Cache）也将解决同样的问题，并且内置了所有线程安全性。
不要使用SortedDictionary<,>除非您关心数据是否已排序。我不认为你这样做。
随着数字变大，我更倾向于考虑 redis / memcached 等存储，将本地内存作为本地快捷方式。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
