我有多个后端服务器不断构build和刷新API的公共部分，以caching它。 后端服务器正在build立，取决于在作业队列中要做什么。
一次，后端服务器1将build立：
/article/1.json /article/5.json 后端服务器2将构build：
/article/3.json /article/9.json /article/6.json
我需要从前端服务器提供这些文件。 caching存储为文件，以便直接由nginx服务，而不需要通过rails栈。
问题是要想方设法在前端服务器上更新caching（添加新的服务器应该是无缝的）。
我考虑过：
任何经验或更好的方法来实现这个想法？
你不会说构建一篇文章需要多长时间，但是假设它不是非常慢，我认为让应用程序服务器动态构建页面并让前端服务器进行缓存会更好。 在这个场景中，你可以把haproxy / varnish / squid / nginx的一些组合放在你的应用服务器前，让它们为你做平衡/缓存。
如果你继续在后端继续构建它们，你可以做同样的事情。
你最终的目标是有这样的：
internet -> load balancer -> caching server 1 --> numerous app servers \-> caching server 2 -/
根据需要添加更多缓存服务器和应用程序服务器。 互联网永远不会知道。 根据您选择的软件，负载均衡器/缓存服务器可能相同，也可能不相同。 真的取决于你的负载和特定的需求。
如果你不想碰到铁轨堆栈，那么在它到达整个应用程序之前，你可以使用类似rack-cache的东西来捕获请求：
http://rtomayko.github.io/rack-cache/
至少这样，你只需要引导机架。
它也支持memcached作为存储机制： http : //rtomayko.github.io/rack-cache/storage
你是对的，S3是非常慢的itlsef，尤其是HTTPS会话设置可能需要长达5-10秒。 但S3是原始数据的理想存储，我们使用它很多，但与S3 Nginx代理的组合，以加快数据传输和注入缓存设施。
Nginx S3代理解决方案在生产环境中经过了很好的测试，并且缓存机制工作完美，每个应用服务器都去代理从S3获取原始文件进行缓存。
为了防止狗桩效应，你可以使用：
新文件的proxy_cache_lock ， doc
更新文件的proxy_cache_use_stale更新 ， doc
一个S3的Nginx代理配置看看这个https://gist.github.com/mikhailov/9639593