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