具有负载平衡的 REST 服务

Question

我一直在考虑 REST 服务的优势、整个无状态和 session 关联“东西”。令我震惊的是，如果您在基础架构中的多台机器上部署了多个服务版本，并且它们都作用于给定资源，那么该资源的状态存储在哪里？

在使用分布式缓存的基础设施中拥有一个单一的主机，以及服务内部发生变化的任何状态，它只是简单地获取/放入缓存是否有意义？这将允许出于负载平衡原因的任意数量的已部署服务都看到相同的资源状态 View 。

Answer 1

如果您正在为高负载(通常意味着高可靠性)设计系统，那么单点故障绝不是一个好主意。如果提供一致 View 的服务出现故障，最好的情况是您的性能会随着查询数据库的所有内容而急剧下降，最坏的情况是您的整个应用程序停止工作。

在您的问题中，您似乎担心一致性。如果有什么要了解的eBay's architecture ，就是有trade-off to be made between availability/redundancy/performance vs consistency .您可能会发现不需要 100% 的一致性，您可以摆脱一些“困惑”。

分布式缓存(如 memcache )可以用作 distributed hashtable 的支持已被广泛用于创建可扩展的基础设施。如果正确实现，缓存可以是冗余的，并且缓存可以动态地加入和离开环。

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

然而，用 Phil Karlton 的话说，caching is hard .您确实必须对缓存的数据、何时缓存以及如何使该缓存失效进行选择性。可以通过以下方式进行无效:

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

当更新到来时，使包含相关数据的所有缓存失效。

我偏爱基于计时器的方法，因为它更易于实现，您可以相对肯定地说陈旧数据将在系统中存在多长时间(例如，公司详细信息将在 2 小时内更新，股票价格将在 10 秒内更新) .

最后，高负载还取决于您的用例，并且取决于交易量，这些都不适用。方法论(如果你愿意的话)可能如下:

确保系统在没有缓存的情况下正常运行(是否有效)

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

优化瓶颈

在需要时实现缓存

毕竟，您可能一开始就没有性能问题，而且您可以使用单个数据库和良好的备份策略。