我们的 PHP 应用程序由一个 Web 服务器组成，该服务器将从客户端接收文件并对其进行 CPU 密集型分析。目前，对单个用户上传的分析可能需要 3 秒才能完成，并且占用 100% 的 CPU。这使我们的系统容量达到每秒 1/3 的请求。
我的团队的需求是增加容量，而无需进行大量代码重新设计。一个可能的解决方案是在运行同一应用程序的多台服务器前面设置一个负载平衡器，连接到一个公共数据库。问题是分析输出文件在磁盘上。
负载平衡器会增加容量，但服务器之间将无法使用文件，因此后续的客户端请求可能会失败。我们的服务器托管在 Rackspace 上，有没有办法为所有服务器配置某种“通用”存储，而无需重写文件持久性代码？当前代码依赖于简单的 fopen 等。我们有哪些选择？
答案1
集群文件系统将提供完整的 POSIX 文件系统导出，可以像大多数其他本地文件系统一样挂载。它将复制到配置的冗余程度，否则将只在请求时提取数据。只要每台服务器都配置为即使在盲目情况下创建的文件也有唯一的路径，您就应该处于非常有利的位置。
答案2
为什么不使用 CloudFuse 将云文件安装到每台服务器上？
然后，您可以使用云文件作为通用文件系统。它不适合 IO 繁重的工作，但偶尔阅读和阅读时效果很好，而且您可以从 CDN 提供文件
答案3
哪些后续请求需要访问该文件？仅该登录会话中的一位用户、永远相同的用户，还是任何人？如果是前两个选项之一，则负载平衡器应该能够提供帮助。
我相信Rackspace 提供基于 F5 BIG-IP 的负载平衡服务会话持久性（将用户送回同一台服务器进行整个会话）应该是负载平衡服务中的一个选项。我假设您谈论的是 HTTP 流量，在这种情况下，负载平衡器可以向会话中注入 cookie，并使用它来确保客户端返回到其处理的文件所在的同一服务器（会话 cookie 或时间受限 cookie）。
我不知道 Rackspace 是否允许客户使用 F5 iRules，但如果他们允许的话，您甚至可以通过让负载平衡器确定哪个服务器托管文件来处理第三种情况。
答案4
如果文件从未进入数据库，那么是的，您需要一个由所有 Web 主管使用的单一文件系统。如果文件仅在用户会话（上传文件的会话）期间使用，您可以在负载平衡器中使用源 IP 或基于会话的粘性来解决问题，而无需单一文件系统。
所有负载均衡器都支持各种粘性方法。F5 负载均衡器很棒，但 Rackspace 还出售价格便宜得多的 Brocade。
如果您需要使用单个文件系统，那么这将涉及一些返工，并且有很多方法可以解决它（例如，其中一个 Web 头可以是文件系统、数据库服务器、新的专用系统、或来自 rackspace、AWS 或其他的云存储系统）。
呼！