多步骤图像提交到负载平衡服务器问题
我们有两个 apache/php Web 服务器，通过鱿鱼页面缓存代理进行负载平衡。图像提交页面上的鱿鱼缓存未激活。我们有一个用户可以提交图像的表单。
这是一个两步过程。他们首先上传图像。第二步，他们可以输入有关图像的详细信息，然后在提交图像详细信息后将图像移至正确的文件夹。
问题是，当流量较高时，第二步可能由另一台服务器提供，然后是上传图像的服务器。所以第二步可能会找不到上传的图片，导致上传失败。
我们在这些服务器上有数千个图像文件，因此它们之间的同步很慢。无论如何，我们是否可以强制特定页面始终由特定服务器提供服务？基本上是为了绕过负载平衡功能。
We have two apache/php web servers load balanced with squid page caching proxy. The squid caching is not active on image submission pages. We have a form where users can submit images.
It's a two step process. They first upload the images. The second step they can enter details about the images and images are then moved over to correct folders once they submit the image details.
Problem is when there is high traffic the second step might be served from a different server then the one with the uploaded images. So the second step might not find the uploaded images and upload fails to complete.
We have thousands of image files on these servers so the syncing between them is slow. Is there anyway that we can force a specific page to always to be served from a specific server? Basically to bypass the load balancing feature.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对此有一些解决方案。
就我个人而言，我会选择选项 1，因为您仍然可以获得循环负载平衡，但每个连接都粘在它最初连接到的主机上。
选项 2 的优点是仍然平等地平衡请求，但缺点是 NFS 共享会出现单点故障。
如果使用哈希表，如果数据库服务器上没有足够的 RAM，选项 3 可能会导致问题。
There are a few solutions to this.
Personally I would go with option 1 as you still get round robin load balancing, but each connection is stuck to the host that it was initially connected to.
Option 2 has the benefit of still equally balancing requests, but the downside is the NFS share is a single point of failure.
Option 3 can cause issues if there is not enough ram on the DB server if you use a hash table.
我可以看到两个接近杰弗里答案的选项。
1. 将图片上传到通过rsync同步的上传目录。
那么图像数量会小得多，并且同步速度会快得多。
完成整个过程后，您可以将图像移动到正确的文件夹。
2. DB：不存储图像本身，而是存储图像的 url，因此您始终会知道哪个服务器正在保存它并可以访问它。
只有两个选项来阅读 Geogre 的答案并寻找与该主题相关的信息。
I can see two options close to Geoffrey answer.
1. Upload images to an upload directory syncronized through rsync.
Then the # of images would be much smaller and they would sync much faster.
After you go through the whole process you can move the image to the right folder.
2. DB: Storing not the image itself but the url of the image, so you always will know which server is holding it, having access to it.
Just two options that came reading Geogrey's answer and looking for info related to this topic.