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