我们的PHP应用程序由一个Web服务器组成，它将接收来自客户端的文件并对其进行CPU密集型分析。 目前，单个用户上传的分析可能需要3秒才能结束并占用100％的CPU。 这使得我们的系统容量达到每秒1/3个请求。
我的团队的要求是增加容量，而不需要大量的代码重新devise。 一个可能的解决scheme是在运行相同应用程序的多个服务器前设置一个负载平衡器，并连接到一个公共数据库。 问题是分析输出磁盘上的文件。
负载平衡器会增加容量，但是之后服务器之间的文件将不可用，所以随之而来的客户端请求可能会失败。 我们托pipe在Rackspace上，是否有办法为所有服务器configuration某种“通用”存储，而不必重写我们的文件持久性代码？ 目前的代码依赖于简单的fopens等。我们有什么select？
为什么不使用CloudFuse将Cloud文件安装到每个服务器上？
然后，您可以使用云文件作为您的通用文件系统。 这对于IO繁重的工作并不理想，但是只是偶尔说出来并且偶尔读取就可以正常工作，此外，您还可以从CDN
GlusterFS将提供完整的POSIX文件系统导出，可以像其他大多数本地文件系统一样进行挂载。 它将复制到冗余configuration的程度，否则将只能根据请求提取数据。 只要每个服务器都configuration好了，即使是在一个盲目的情况下，所创build的文件也具有唯一的path，那么你应该是一个很好的select。
哪个后续的请求将需要访问该文件？ 只是在该login会话中的一个用户，永远相同的用户，或任何人？ 如果这是负载平衡器应该能够帮助的前两个选项之一。
我相信Rackspace提供基于F5 BIG-IP的负载均衡服务 。 会话持久性（将用户发回到同一台服务器进行整个会话）应该是负载均衡服务中的一个选项。 我假设你正在谈论HTTP通信量，在这种情况下，负载平衡器可以向会话中注入一个cookie，并使用它来确保客户端回到处理文件所在的服务器（会话cookie或时间有限的）。
我不知道Rackspace是否让客户使用F5 iRules，但是如果他们这样做，您甚至可以通过让负载平衡器确定哪个服务器托pipe文件来处理第三种情况。
如果文件永远不会进入数据库，那么是的，你需要一个单一的文件系统使用的所有网站的头像。 如果仅在用户会话期间（即上传文件的会话）使用文件，则可以在负载平衡器中使用基于源IP或基于会话的粘性来解决问题，而不需要单个文件系统。
所有的负载均衡器都支持各种粘性方法。 F5负载平衡器很棒，但是Rackspace也卖了很less的锦缎。
如果你需要去单一的文件系统，这将涉及一些返工，并有多种方法来解决它（例如，其中一个网页头可能是文件系统，或数据库服务器，或一个新的专用系统，或者来自机架空间，AWS或其他的云存储系统）。
心连心！