AppFabric 与 System.Runtime.Caching
TLDR 版本：用于缓存许多在我的 .NET4 WCF 服务中很少更改的小型数据库表。哪种技术最容易实施、最容易维护并且执行效果最好？为什么？
长版本：我开始为新项目制定缓存策略。过去很简单，因为预打包选项较少（适合初学者的企业库），但现在有了 .NET 4 框架和 AppFabric，我很难决定解决方案。基本上，我想缓存大量很少更改的小型（<100 行，2-4 列）数据库表，并让我的 WCF 服务从缓存中提取它，而不是每次都从数据库中提取。我已经开始阅读文档、观看视频并下载培训材料，但经验是更好的老师，我很难找到两者之间的比较。
任何建议将不胜感激！谢谢！
TLDR version: For caching many small database tables that rarely change in my .NET4 WCF service. Which technology will be easiest to implement, easiest to maintain, and best to perform and why?
Long version: I'm starting to work on a caching strategy for a new project. It used to be simple because there were fewer pre-packaged options (Enterprise Library for starters), but now with the .NET 4 framework and AppFabric being available, I'm having a harder time deciding on a solution. Basically, I want to cache a multitude of small (<100 rows with 2-4 columns) database tables that rarely change and have my WCF service pull it from cache rather than pulling everytime from the database. I've begun reading the documentation, watching the videos, and downloading the training material, but experience is a better teacher and I've had a hard time finding comparisons between these two.
Any advice would be quite appreciated! Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
据我了解，AppFabric 是一个分布式、高可用的应用程序间缓存平台。
与经典的 ASP.NET 缓存或其他本地缓存系统相比，它确实意味着 IPC 比进程内缓存和进程内调用要慢，但具有很大的优势，多个应用程序可以在需要时访问同一缓存集群，并且可以重新启动如果您在基础架构中设计了特定的缓存服务器，则 IIS 中的应用程序池或整个 Web 服务器不会意味着丢失缓存。
具有高可用性和集群性，如果缓存服务器发生故障，其他服务器仍将处理请求。
启用本地缓存的客户端仍然可以在本地缓存数据，但是一旦它们失效或本地缓存失效，数据将从缓存集群中检索，而不是直接从数据库中检索，除非确实需要。
我认为有一个权衡，决定是否最好让 IPC 调用慢一点但在公司内具有可靠性和共享缓存集群。
to my understanding AppFabric is a distributed highly available inter-application caching platform.
compared to classic ASP.NET caching or other local caching systems, it does imply IPC which is slower than in-process caching and in-process calls anyway but has the big advantage that multiple applications can access the same cache cluster if needed and that restarting the app pool in IIS or the whole web server(s) won't imply losing the cache in case you have designed specific cache servers in your infrastructure.
being high-available and clustered if a cache server fails the other one(s) will still server the requests.
with local-cache enabled clients can still cache data also locally but once they fall or local cache is invalidated data will be retrieved from cache cluster and not directly from database, unless really needed.
I think there is a tradeoff, to decide if better to have IPC calls a bit slower but reliability and shared cache cluster in the company or not.