我正在实现一个高流量客户端 Web 应用程序，该应用程序使用大量 REST API 作为其来自云数据库的数据访问层。我说客户端是因为它实现了 REST 而不是提供它。
REST API 是在服务器端和客户端实现的，我需要找出一个好的缓存解决方案。该应用程序在网络场上运行，因此我倾向于使用像 memcached 这样的分布式缓存。这个缓存解决方案需要像我的应用程序和 REST API 之间的代理层一样，同时支持客户端和服务器端。
例如，如果我调用更新记录，我将通过 REST 进行更新，并且我希望将更新的记录保存在缓存中，以便下次调用该记录时不需要额外调用外部 REST 服务。
我想尽可能减少 REST 调用，并且需要尽可能保持数据准确，但不需要 100% 准确。
这个缓存代理的最佳解决方案是什么？它是在其中一台具有本地缓存的服务器上运行的独立应用程序，还是使用分布式缓存内置到当前解决方案中的应用程序？你有什么想法、建议或顾虑
谢谢，
最佳答案
您一语中的。您需要一个缓存层来充当数据的代理。
我建议您创建一个层，以某种方式抽象云的概念。您的客户不应该关心数据的来源。我会创建一个与云和所有其他数据通信的存储库层。然后，您可以在客户实际调用的服务层之上放置一个服务层。在这个服务层中，您可以实现诸如缓存层之类的东西。
我过去总是建议使用 MemCached 或 MemCached Win32取决于你的环境。如果您在 Windows 世界中，MemCached win32 工作得非常好!查看Enyim MemCached win32 的客户端...它是所有其他端口中问题最少的。
如果您对它持开放态度并且您处于 .net 世界中，那么您可以尝试 Velocity . MS 终于得到线索，他们的缓存框架中存在一个漏洞，因为他们需要支持场概念。我上次检查的 Velocity 还没有结束测试版……但仍然值得一看。
我通常建议从第一天开始就使用存储库和服务层概念……即使您不需要它。它为您的应用程序提供的灵 active 是值得拥有的，因为您永远不知道您的应用程序需要被拉入哪个方向。需要扩展通常是需要这种灵 active 的最佳理由。但通常当您需要扩展时，您现在需要扩展，并且在存储库层和服务层中进行重构虽然并非不可能，但通常是半复杂的。
关于asp.net - 架构问题 : client REST API's caching solution，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1290618/