我正在实施一个高流量客户端Web应用程序，该应用程序使用大量REST API来从云数据库中获取数据访问层。我说客户端因为它实现了REST而没有提供它。
REST API是在服务器端和客户端实现的，我需要找到一个很好的缓存解决方案。该应用程序在Web场上运行，因此我倾向于像memcached这样的分布式缓存。这个缓存解决方案需要像我的应用程序和REST API之间的代理层，并支持客户端和服务器端。
例如，如果我调用更新记录，我将通过REST更新，并且我希望在缓存中保留更新记录，以便下次调用该记录不需要额外调用外部REST服务。 / p>
我希望尽可能减少REST调用，并且需要尽可能保持数据的准确性，但它不需要100％准确。
此缓存代理的最佳解决方案是什么？它是一个在具有本地缓存的服务器上运行的独立应用程序，还是使用分布式缓存内置到当前解决方案中？你有什么想法，建议或关注
谢谢，
答案 0 :(得分：4)
你击中了头部的钉子。您需要一个缓存层作为数据的代理。
我建议您创建一个稍微抽象云概念的图层。您的客户不应该关心数据的来源。我将创建一个与云和所有其他数据通信的存储库层。然后，您可以将服务层放在客户端实际调用的服务层之上。在此服务层内部，您可以实现缓存层之类的操作。
我以前总是建议使用MemCached或MemCached Win32，具体取决于您的环境。如果你在windows世界中，MemCached win32的效果非常好！查看Enyim客户端的MemCached win32 ...它是所有其他端口中问题最少的。
如果你对它开放并且你在.net世界，那么你可以试试Velocity。 MS终于得到了他们的缓存框架中存在漏洞的线索，因为他们需要支持农场概念。我上次检查时的速度还没有超出测试范围......但还是值得一看。
我通常建议从第一天起使用存储库和服务层概念......即使您不需要它。它为您的应用程序提供的灵活性值得拥有，因为您永远不知道应用程序需要引入哪个方向。需要扩展通常是需要这种灵活性的最佳理由。但通常当您需要扩展时，您需要立即扩展并在存储库层和服务层进行重构，而不是不可能通常是半复杂的。