在分布式系统环境中，我们有一个RESTful服务，需要在低延迟时提供高读取吞吐量。由于数据库技术的限制，并且考虑到它的重读系统，我们决定使用MemCached。现在，在SOA中，缓存的位置至少有2个选择，基本上客户端在调用服务器与客户端之前在缓存中查找始终调用在缓存中查找的服务器。在这两种情况下，缓存本身都是在分布式MemCached服务器中完成的。
选项1：客户 - ＆gt; RESTful服务 - ＆gt; MemCached - ＆gt;数据库
OR
选项2：客户 - ＆gt; MemCached - ＆gt; RESTful服务 - ＆gt;数据库
我有一个意见，但我很乐意听到社区中的SOA专家支持和反对任何选项的论据。请假设任一选项都是可行的，这是一个架构问题。感谢分享您的体验。
答案 0 :(得分：1)
我见过
选项1：客户 - ＆gt; RESTful服务 - ＆gt;缓存服务器 - ＆gt;数据库
工作得很好。 优点恕我直言，您可以通过以下方式操作并使用此图层，以便您免费使用＆＃34; DB上的部分负载。假设您的最终用户可以有很多类似的请求，并且毕竟客户端可以决定为缓存提供多少存储空间。还有多少次清除它。
答案 1 :(得分：1)
我更喜欢选项1而我目前正在使用它。通过这种方式，可以更轻松地控制DB上的负载（正如@ekostatinov所述）。我有很多系统中每个用户都需要的数据，但数据永远不会改变（例如某些系统规则，项目类型等）。它确实减少了DB负载。通过这种方式，您还可以控制缓存的行为（例如何时清除项目）。
答案 2 :(得分：1)
选项1是首选选项，因为它使memcache成为服务的实现细节。另一种选择意味着如果业务发生变化并且事物不能保存在缓存（或其他可以等）中，则客户端必须进行更改。选项1隐藏了服务接口背后的所有内容。 此外，选项1允许您根据需要改进服务。例如也许以后你认为你需要一种新技术，也许你可以通过数据库等来解决性能问题。同样，选项1可以让你做出所有这些改变，而不会将客户端拖入混乱中
答案 3 :(得分：1)
REST ful API是否向外部消费者公开。在这种情况下，由消费者决定是否要使用缓存以及他们可以使用多少陈旧数据。
至于REST ful服务，服务是业务逻辑的容器，它是数据的权限，因此它决定缓存多少，缓存到期，何时刷新等。使用REST服务的客户端始终假定服务为其提供最新数据。因此选项1是首选。
在这种情况下，谁是客户？ 它是REST API的包装器吗？您是否同时提供客户和服务。
答案 4 :(得分：0)
我可以与Enduro/X middleware实施分享我的经验。对于本地XATMI服务调用，任何客户端进程都连接到共享内存（LMDB）并在那里检查结果。如果保存了响应，则直接从shm返回数据。如果不存在数据，则客户端进程将执行最长路径并执行IPC。在REST访问的情况下，网络客户端仍然执行HTTP调用，但HTTP服务器作为XATMI客户端返回共享内存中的数据。从现实生活中，这种技术极大地推动了通过REST调用使用中间件的Web前端Web应用程序。