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