具有负载平衡的REST服务

我一直在考虑REST服务的优势、整个无状态性和会话亲和性“东西”。让我印象深刻的是，如果您在基础架构中的多台机器上部署了多个服务版本，并且它们都作用于给定的资源，那么该资源的状态存储在哪里

---

在基础设施中有一台使用分布式缓存的主机，并且服务中的任何状态发生变化时，它都会简单地获取/放入缓存，这有意义吗？这将允许出于负载平衡原因而部署的任何数量的服务都可以看到相同的资源状态视图。

如果要设计高负载（通常意味着高可靠性）的系统，那么单点故障永远都不是一个好主意。如果提供一致性视图的服务出现故障，那么在最好的情况下，当查询数据库中的所有内容时，性能会急剧下降，而在最坏的情况下，整个应用程序将停止工作

在你的问题中，你似乎担心一致性。如果有什么需要学习的话，那就是有一个。你可能会发现100%的一致性是不必要的，你可以摆脱一点“混乱”

分布式缓存（like）可以用作已广泛用于创建可扩展基础架构的备份。如果实现正确，缓存可能是冗余的，缓存可以动态地加入和离开环

REST本身也是可缓存的，因为HTTP层可以通过适当使用头（）和软件（例如Squid代理）进行缓存。通过头指定缓存的一个缺点是它依赖于客户机解释和尊重它们

然而，用菲尔·卡尔顿的话来说。对于缓存的数据、缓存的时间以及如何使缓存失效，您确实必须有选择性。可以通过以下方式进行失效：

通过基于计时器的方式（缓存2分钟，然后重新加载）

当更新到来时，将使包含相关数据的所有缓存失效 我倾向于基于计时器的方法，因为它更容易实现，并且您可以相对确定地说陈旧数据在系统中会存在多长时间（例如，公司详细信息将在2小时内更新，股票价格将在10秒内更新）

最后，高负载还取决于您的用例和事务量，这些都不适用。方法（如果您愿意）可以是：

确保系统在没有缓存的情况下正常工作（是否正常工作）

它是否符合性能标准（例如请求/秒、正常运行时间目标）

优化瓶颈

在需要时实现缓存

---

毕竟,，首先，您可能没有性能问题，而且您可以使用单个数据库和良好的备份策略来解决问题。

我认为负载平衡web应用程序更传统的观点是，您可以在多个应用程序服务器上使用REST服务，它们可以从单个数据库检索资源数据服务器

但是，通过使用超媒体，REST服务可以轻松地对应用程序进行垂直分区，以便一些资源来自不同服务器上的一个服务，另一些资源来自另一个服务。这将允许您根据您的域进行一定程度的扩展，而无需单一的数据存储。显然，使用REST，您将无法跨这些服务进行事务性更新，但在某些情况下，分区是有价值的

---

如果您正在研究需要真正扩展的体系结构，那么我建议您在尝试解决分布式缓存问题之前，先看看Greg Young关于CQS体系结构（）的内容。

这似乎是高度理论化的，您能否更详细地描述一下您试图实现的目标？无状态不是REST特有的。“会话关联”是什么意思？