我正在将我的项目的web堆栈重构为：nginx – > haproxy – >许多（apache / passenger rails）实例
其中一些目标包括：
image / stylesheet / javascript资源被高速caching，并具有适当的头文件。 我们的页面caching是基于内部参数的，不应该对典型的caching控件做出响应。 为了达到这些目的，我们的configuration看起来像这样
server { ... location /really_slow_dynamic_content/ { root /var/www/tmp; error_page 404 = @fetch; } location @fetch { internal; proxy_pass haproxy_ip; proxy_store /var/www/tmp${uri}_cache.html; proxy_store_access user:rw group:rw all:r; } location /assets/ { proxy_pass haproxy_ip; proxy_cache assets; } location / { proxy_pass haproxy_ip; } } 我不是一个系统pipe理员，我知道有很多替代品/调整/添加可能会有所帮助。 我也不太了解proxy_cache和proxy_store之间的区别。 所以对我的实际问题
在将资源移动到nginx机器之前，将cachingdynamic内容的资产和proxy_store用于proxy_cache是否合理？
另外，如果还有其他的考虑因素或软件，我应该考虑，我很乐意听取他们的意见。 谢谢！
自发布这个问题以来，我意识到我使用的初始configuration根本不使用存储，并且（semi？） 官方wiki示例中的error_page和internal设置不完全是可选的这似乎是工作，一个工作configuration似乎是这个问题更好的遗产）。 所以，使用商店缓慢创build（和很less更新）完整的页面，以及图像的实际caching，JavaScript等似乎对我们工作得很好。 我会接受一个答案，因为它至less让我有一个领导来追踪我的问题，但我仍然不知道我是否按照他们打算的方式使用这两个指令或者不（至less在商店方面，caching似乎更为明显）。
如果内存正确地为我服务，proxy_store存储一个项目的请求的二进制表示，而proxy_cache存储该项目的caching副本的基本forms。
proxy_cache实际上是一个具有多个级别的适当的caching引擎，并且适合于使用相同的密钥来存储来自多个站点的内容。
我个人使用proxy_cache在每个静态内容服务器上存储了超过20亿个产品图像。
proxy_store用于创build对象的“按需”镜像。 它将项目放在与给定项目在后端相同的path上。
在dynamic内容较慢的情况下，proxy_cache更适合，因为它支持caching到期。
proxy_store更有用的一个例子可能是rpm文件的镜像，其中一个文件名/版本将永远不需要过期 。