ASP.NET InProc缓存与分布式缓存

Question

我正在研究Redis和替代品，因为我们将转而编写分布式应用程序。我的想法是我们需要像Redis这样的分布式缓存来确保我们在任何地方都有一致的缓存。我的高级同事不同意并且说我们应该使用选择性的InProc缓存，其中一些数据在请求时被缓存在机器的内存中。他还说Redis比缓存数据InProc慢得多。他同意我们应该将Session状态存储在分布式缓存中，因为这需要保持一致。

保留缓存的最佳位置是什么？ InProc或分布式？

Answer 1

使用进程内或进程外缓存完全取决于应用程序。

Inproc缓存将数据存储在当前应用程序的进程内存中，这使得缓存数据访问速度非常快，但缓存数据只能由本地应用程序访问。如果您只有一个应用程序服务器或每个应用程序服务器使用不同的数据集，则此方法正常。即便如此，如果应用程序服务器出现故障，缓存的数据也将丢失。

但是，如果您的多个应用程序服务器使用相同的数据集，则Inproc缓存不是最佳解决方案。因为在这种情况下，每个应用程序都将加载相同的数据集，因此限制了使用缓存的有用性。 此外，对于会话状态缓存，它将为您提供使用粘性会话的唯一选项，这反过来会限制负载平衡。

另一方面，分布式缓存会增加从另一台服务器获取数据的额外网络成本，但它会为您提供与所有其他应用程序共享相同数据集的优势。不仅如此，即使应用程序服务器出现故障，数据也将保持缓存状态。

您还可以使用Inproc和OutProc缓存的混合解决方案，例如NCache提供的解决方案，您可以在其中拥有分布式群集缓存（包含所有缓存数据）和本地inproc缓存（包含数据，经常被该应用程序服务器使用）。这将为您提供缓存技术的优势。

由于您正在重写您的应用程序，我建议您尝试NCache。它提供了进程内和进程外的解决方案。您只需编写一次应用程序，使用两种解决方案进行测试，然后选择最适合您的应用程序。

Answer 2

InProc和分布式缓存不是互斥的，也可能是您唯一的选择。您也可以拥有distributed invalidation solutions。

您还应该更仔细地检查您对“一致”缓存的真正需求。保证会话状态真正一致的唯一方法是锁定它。这将序列化来自同一用户的同时请求。

你确定你真的想要/需要会话状态吗？如果您要跟踪的内容是基于安全性的，您确定无法处理稍微陈旧的数据吗？如果它是基于用户状态的，它可能会被渲染到客户端页面中，而不是在服务器上独立跟踪。