c# - 带文件依赖项的 ASP.NET 缓存 : static var vs. AspNet 缓存与 memcached

Question

TL;DR:访问静态局部变量、访问存储在 HttpRuntime.Cache 中的变量或访问存储在 memcached 中的变量哪个可能更快？

在工作中，我们每天大约有 200,000 次页面浏览。在我们的主页上，我们显示促销信息。根据用户的原籍国和语言，此促销事件针对不同的用户有所不同。

所有不同的促销事件都在每个网络服务器上的 XML 文件中定义。我们有 12 台 Web 服务器，它们都使用相同的 XML 文件服务于相同的站点。根据国家/语言，大约有 50 种不同的促销组合。我们想象我们永远不会有超过 200 个左右(如果有的话)促销(组合)总数。

XML 文件可能会在发布周期之外随时更改。更改后，促销的新定义应立即在实时站点上更改。实现此要求的功能是我和其他开发人员的责任。

最初，我编写代码是为了解析 XML 文件的内容，然后将其存储在类的静态成员中。 FileSystemWatcher 监视文件的更改，每当文件更改时，XML 将被重新加载/重新解析，静态成员将更新为新内容。看起来像是一个可靠、简单的解决方案，可以使内存中的促销字典与 XML 文件保持同步。 (每个服务器独立地使用它的 XML 文件的本地副本执行此操作；所有 XML 文件都是相同的并且同时更改。)

与我一起工作的另一位开发人员担任高级职位，并认为这不好。相反，我们应该将所有促销存储在每个服务器的 HttpContext.Current.Cache 中，并使用 CacheDependency 文件依赖项自动监控文件更改，并在文件更改时清除缓存的促销。虽然我喜欢我们不再需要使用 FileSystemWatcher，但我有点担心从 volatile 缓存而不是静态类成员中获取提升会降低性能。

(想对这个问题发表评论吗？我已经放弃了提倡不要切换到 HttpRuntime.Cache 的尝试。)

后来，在我们开始使用 HttpRuntime.Cache 之后，我们采用带有 Enyim 的 memcached 作为我们的 .NET 接口(interface)来解决其他业务问题(例如搜索结果)。当我们这样做时，这位高级开发人员决定我们应该使用 memcached 而不是 HttpRuntime (HttpContext) Cache 来存储促销信息。上级说“是的，听起来不错”，并为他提供了一个带有 memcached 的专用服务器以用于这些促销事件。现在他正在实现更改以改用 memcached。

我怀疑这是一个好的决定。我们现在不是停留在进程中并从 HttpRuntime.Cache 中获取促销数据，而是打开一个到网络 memcached 服务器的套接字并将其值传输到我们的 Web 服务器。

这一定是性能较差，对吧？即使缓存是memcached。 (我还没有机会编制任何性能指标。)

最重要的是，他将不得不在 memcached 上设计自己的文件依赖解决方案，因为它不提供这样的工具。

难道我的原始设计不是最好的吗？这会让您觉得过度设计了吗？ HttpRuntime.Cache 缓存或 memcached 缓存是否必要？

Answer 1

我不知道你在谈论多少数据(假设不是很多)，我倾向于在某种程度上同意你的观点；就原始速度而言，静态成员应该是“最快的”，然后是 Cache。当然，这并不一定意味着它是最佳选择。可扩展性并不总是与速度有关。事实上，我们为可扩展性所做的事情通常会对应用程序的速度产生负面(轻微)影响。

更具体地说；我确实倾向于自己从 Cache 对象开始，除非一些“静态”数据非常小并且几乎可以保证不断需要(在这种情况下我会选择静态成员。不要忘记线程同步，当然!)

对于根本不会经常更改的少量数据，并且可以在需要时轻松修改，通过根据您的记录更改文件，Cache 对象可能是一个很好的选择解决方案。 memcached 可能有点矫枉过正，而且过于复杂……但它也应该有效。

我认为 memcached 解决方案的主要“负面”可能是单点故障问题；使用本地服务器的 Cache 使每个服务器保持隔离。

从政治上讲，听起来您的情况可能真的没有任何选择。但我认为，考虑到您在此处分享的内容，您的推理不一定那么糟糕。