架构问题：客户端REST API的缓存解决方案

Question

架构问题：客户端REST API的缓存解决方案

asp.netrestclientdata-access-layerdistributed-caching

3

我正在实现一个高流量的客户端Web应用程序，它使用许多REST API从云数据库中获取数据。我说客户端，因为它是实现REST而不是提供REST。

REST API既可以在服务器端实现，也可以在客户端实现，我需要找到一个好的缓存解决方案。该应用程序正在运行在Web farm上，因此我倾向于使用分布式缓存，如memcached。这个缓存解决方案将需要像代理层一样存在于我的应用程序和REST API之间，并支持客户端和服务器端。

例如，如果我调用更新记录，我会通过REST进行更新，并希望将更新后的记录保留在缓存中，以便下次对该记录的调用不需要额外调用外部REST服务。

我想尽可能地减少REST调用，并尽可能地保持数据准确，但不需要100%准确。

什么是这种缓存代理的最佳解决方案？它是作为独立应用程序在其中一个具有本地缓存的服务器上运行，还是内置于当前解决方案中使用分布式缓存？你有什么想法、建议或关注点？

谢谢，

- Sergey

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Andrew Siemer · Accepted Answer

你说得很对。你需要一个缓存层，作为代理访问你的数据。

我建议你创建一个抽象云概念的层。你的客户端不应该关心数据来自哪里。我会创建一个与云和所有其他数据通信的仓库层。然后在其上放置一个服务层，你的客户端实际上会调用这个服务层。在这个服务层内，你将实现像缓存层这样的东西。

我过去总是建议使用MemCached或 MemCached Win32（取决于你的环境）。如果你在Windows世界中，MemCached Win32效果非常好！看看 Enyim客户端的MemCached win32...它是所有其他端口中最少有问题的。

如果你愿意并且你处于 .net 的世界中，那么你可以尝试 Velocity。微软终于意识到他们的缓存框架中存在一个漏洞，即他们需要支持农场概念。据我上次检查，Velocity还没有退出beta版...但仍然值得一看。

我通常建议从第一天开始使用存储库和服务层的概念...即使你不需要它。它为您的应用程序提供的灵活性是值得拥有的，因为您永远不知道您的应用程序将需要被拉入哪个方向。需要扩展通常是需要这种灵活性的最好理由。但通常当你需要扩展时，你需要立即扩展，而在未来重新设计存储库层和服务层虽然不是不可能，但通常是半复杂的。