ASP.NET内置缓存（HttpContext.Cache） - 是否有人使用这些东西？

Question

希望利用ASP.NET中的侧缓存的开发人员现在似乎对财富/选择感到尴尬：

1. 内置的ASP.NET缓存（HttpContext.Cache）
2. AppFabric on-premise
3. AppFabric Azure
4. Redis Azure
5. 其他第三方

如果你还没有听说过，微软宣布＃2的生命结束。那（加上＃4的存在）让我想知道＃3是否是一个很好的长期赌注。但我真正的问题是关于＃1。我很长一段时间都在ASP社区工作过。我很少听到（或看到）企业对内置缓存的使用。也许其他开发者知道我不知道的事情？它糟透了？

我的公司正在追求＃5。我们正在考虑从供应商的API中抽象出来，可能使用基于＃1语义的接口，但如果＃1从第一天开始就不起作用，那么重点是什么？ - 谢谢，BGU

Answer 1

我最近（去年左右）在Intranet环境中使用内置缓存来存储13Mb缓慢变化（每天一次）的数据。对我来说的好处是......易用性，可靠性，并且因为内置缓存是IIS的一部分，所以没有其他依赖项（例如路由/防火墙），所以不会出错。

现在是否常用内置缓存？我不知道，我以前很少使用它，或者从那以后。然而，在可预见的未来，它可行并且似乎可能存在。

Answer 2

1. ASP.Net缓存 （实际上 HttpRuntime.Cache ）它是最快的，而且更喜欢方法，如果你这样做的话不打算作为Web Farm或Web Garden托管。

2. Windows Server AppFabric - 如果您计划托管为Web场或Web园，则可以使用此选项。 需要大量配置;我个人更喜欢 Redis缓存。

3. AppFabric缓存已在Azure中停用。接下来， Azure角色内缓存也将很快退役。

4. Redis缓存 - 如果您计划在Azure中托管，目前推荐使用此方法。

底线是如果它是单个实例，我绝对会使用 HttpRuntime.Cache 。但是，我个人更喜欢Web场或Web Garden的 Redis缓存。

Answer 3

解决方案：ObjectCache是Microsoft提供的基于MemoryCache和AppFabric的抽象。如果需要松散耦合，也应将其用作第三方产品的抽象。 （这就是我们最终要做的。）