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