我一直在考虑 REST 服务的优势、整个无状态和会话亲和性“东西”。令我印象深刻的是，如果您在基础架构中的多台机器上部署了多个服务版本，并且它们都作用于给定资源，那么该资源的状态存储在哪里？
在基础设施中拥有一个使用分布式缓存的主机是否有意义，并且任何在服务内部发生变化的状态，它只是简单地获取/放入缓存吗？这将允许出于负载平衡原因而部署的任意数量的服务都可以看到相同的资源状态视图。
【问题讨论】：
标签： rest web-services load-balancing
如果您要为高负载设计系统（这通常意味着高可靠性），那么单点故障绝不是一个好主意。如果提供一致视图的服务出现故障，最好的情况是您的性能会随着查询数据库的所有内容而急剧下降，最坏的情况是，您的整个应用程序将停止工作。
在您的问题中，您似乎担心一致性。如果对eBay's architecture 有什么要了解的，那就是有一个trade-off to be made between availability/redundancy/performance vs consistency。您可能会发现不需要 100% 的一致性，并且可以摆脱一些“混乱”。
分布式缓存（如memcache）可以用作distributed hashtable 的支持，它已被广泛用于创建可扩展的基础架构。如果实施得当，缓存可以是冗余的，并且缓存可以动态加入和离开环。
REST 本身也是可缓存的，因为 HTTP 层可以通过适当使用标头 (ETags) 和软件（例如 Squid 代理作为 Reverse proxy）进行缓存。通过标头指定缓存的一个缺点是它依赖于客户端解释和尊重它们。
不过，套用 Phil Karlton 的话，caching is hard。您确实必须对缓存的数据、何时缓存以及如何使该缓存无效。失效可以通过以下方式进行：
我偏爱基于计时器的方法，因为它更易于实施，您可以相对肯定地说陈旧数据将在系统中存在多长时间（例如，公司详细信息将在 2 小时内更新，股票价格将在 2 小时内更新10 秒）。
最后，高负载还取决于您的用例和交易量，这可能都不适用。方法（如果您愿意的话）可能如下：
毕竟，您可能一开始就没有性能问题，而且您可能能够摆脱单一数据库和良好的备份策略。
【讨论】：
我认为负载平衡 Web 应用程序的更传统观点是，您将在多个应用程序服务器上拥有 REST 服务，它们将从单个数据库服务器检索资源数据。
但是，通过使用超媒体，REST 服务可以轻松地垂直划分应用程序，以便一些资源来自一个服务，而一些资源来自不同服务器上的另一个服务。这将允许您在一定程度上根据您的域进行扩展，而无需单个数据存储。显然，使用 REST，您将无法跨这些服务进行事务更新，但肯定存在这种分区很有价值的场景。
如果您正在研究需要真正扩展的架构，那么我建议您在尝试解决分布式缓存问题之前先查看 Greg Young 关于 CQS 架构 (video) 的资料。
【讨论】：