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

Question

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

什么是保持缓存的最佳地点？ InProc还是分布式的？

Answer 1

使用in-proc或out-proc缓存完全取决于应用程序。

Inproc缓存将数据存储在当前应用程序的进程内存中，这使得缓存数据访问速度非常快，但缓存数据只能由本地应用程序访问。如果您只有一个应用程序服务器或者每个应用程序服务器使用不同的数据集，这可以正常工作。即便如此，如果应用程序服务器关闭，缓存的数据将会丢失。

但是，如果您的多个应用程序服务器使用相同的一组数据，则Inproc缓存不是最佳解决方案。因为在这种情况下，每个应用程序都会加载相同的数据集，从而限制了使用缓存的实用性。 此外，对于会话状态缓存，它将为您提供使用粘滞会话的唯一选项，这反过来会限制负载均衡。另一方面，分布式缓存将增加从另一台服务器获取数据的额外网络成本，但它会给您与所有其他应用程序共享相同数据集的优势。不仅如此，即使应用程序服务器出现故障，数据也将保持缓存。

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

既然您正在重新编写您的应用程序，我会建议您尝试NCache。它提供了进程内和进程外解决方案。您只能编写一次应用程序，使用两种解决方案进行测试，并使用最适合您的应用程序。

Answer 2

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

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

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