我可以在我的web负载均衡器和我的web farm之间实现什么样的caching策略？

我不确定我是否理解这个问题。 反向代理caching是一种常见的做法，有很多工具可以做到这一点。 清漆和鱿鱼在开源世界中很受欢迎。 通常情况下，您需要在负载均衡器后放置几个RPC框，然后直接从RPC框到您的Web服务器，或者通过负载均衡器返回到Web服务器。

也就是说，如果你正在谈论一个API，通常你所服务的大部分内容都是dynamic的，这使得caching大部分是无用的。

我迟到了这里的派对; 但我有一些贡献…

Cal Henderson在他的“build立可伸缩网站”一书中简要地谈到了你正面临的问题。 您应该阅读关于Web服务API的章节。

正如画架正确指出的那样，反向代理caching通常不会给API带来太多好处。

对你有利的两件事是：

1. 您正在使用的数据的分布式键值caching。 也就是说，您可以将热门数据caching在您的平台原生对象格式中，也可以作为简单的序列化数组或其他任何适合您的平台的快速数据。 这限制了对你的数据库命中的数量，在那里你会有最糟糕的扩展问题。 您的API服务器仍然需要获取任何非高速caching的数据集，并对响应进行序列化，但是至less序列化部分仅受CPU限制，并且可以轻松进行缩放。
2. 某种限速系统，即限制或拒绝提出太多请求的客户的能力。 API调用通常会涉及相当繁重的服务器处理（因为他们读取或操作原始数据），所以保护自己免受写不好的客户端是有道理的。

除此之外，Cal Hendersonbuild议使用stream行语言创build开源客户端库，并将最佳实践融入这些（即客户端caching，速率限制）中。 这样第三方开发人员将有一个简单，兼容的代码平台来重用和build立。 这个想法听起来很棒恕我直言，但也有点昂贵。

caching层将有助于静态内容，但我不明白它将如何帮助dynamicAPI太多。 但是，这仍然有帮助。

例如，您可以使用CDN来帮助caching和分发静态内容，以减less服务器的工作负载，从而将更多时间用在dynamic内容上。

对于你的dynamic的东西，你可能想要采用像这里提到的东西，如果你正在使用CDN的dynamic的东西。

像Akamai这样的CDN甚至可以对dynamic内容（如API和SSL）有所帮助。 他们通过在边缘节点和服务器之间保持开放的TCP会话来实现这一点。 这减less了服务器上打开连接的数量，并节省了大量的时间和数据包build立新的TCP会话。

像HAProxy这样的负载平衡器也可以通过简化和优化TCP会话来提供帮助。 它甚至可以在“World”端运行1500个MTU数据包，在后端运行巨型帧，以减less真实服务器上的处理时间。 它有一些技巧来将连接处理从真实服务器卸载到LB. 你的API服务器上的线程和TCP套接字绑在一起只是一些慢的TCP客户端是浪费资源。