双重上传
自从我们从一个简单的 Apache 实例转变为负载均衡环境后,有时会出现重复 POST 请求的问题。我们将 nginx 作为反向代理运行。静态内容由 nginx 本身提供,动态内容由两个 Apache 后端提供。
我检查过它不是界面/用户错误。一个小例子:一个简单的图像上传将导致图像被上传两次。请求/POST 不会通过双击或用户失败发送两次。我没有发现任何证据表明浏览器发送了两次请求,所以我怀疑是在服务器端。(请注意,这只是怀疑。)这些请求大部分是内部的,这意味着它们来自员工,所以我可以验证它们是如何产生的。
我能找到的唯一“错误”是 nginx499
在这些情况下会记录错误。但是,我不确定这是问题的原因还是(副作用)。(我知道 499 不是默认的 http 状态,它是 nginx 状态,意思是“客户端已关闭连接”)
要求
重复的 POST 请求几乎是所有可能需要一段时间的请求。我在这里展示的一个例子是一个简单的图像上传,但脚本在后台做了一些事情(图像必须转换成不同的格式/大小,并且应该分发到两个服务器等)。
日志
一个例子是上传图片。nginx 将记录一个“499”和一个 200 请求,但 Apache 正在接收(并处理!)两个请求。
阿帕奇
[17:17:37 +0200] "POST ***URL** HTTP/1. 0" 200 9045
[17:17:47 +0200] "POST ***URL** HTTP/1. 0" 200 20687
nginx
[17:17:47 +0200] "POST ***URL** HTTP/1.1" 499 0
[17:17:52 +0200] "POST ***URL** HTTP/1.1" 200 5641
怀疑
在我看来,更大/更慢的上传更受此影响,所以我怀疑超时。我试图阅读 499 错误:结论似乎是“客户端关闭连接”。这可能是后台的情况,但我不确定这意味着应该发出第二个请求,并且肯定不会发生“用户关闭浏览器”之类的事情。
目前,它似乎有助于分解较慢的 POST 请求(如果有很多事情要做,只需让用户选择 1 并为另一个选择第二次 POST),但这可能只是降低了它发生的机会。没有把握。
这显然是一个临时解决方案。如果是超时,我需要找出在哪里并增加相应的数字,但我不确定为什么超时会导致这种行为:我怀疑是“嗯,出错了”消息,而不是重复。
问题
我正在寻找哪些过程/情况会导致重复发布 POST。当然,任何“不确定为什么,但可以通过增加此超时时间来解决”也很好。
nginx 配置
NGINX.conf
user nginx;
worker_processes 2;
worker_rlimit_nofile 10240;
error_log /var/log/nginx/error.log error;
pid /var/run/nginx.pid;
events {
multi_accept on;
worker_connections 4096;
use epoll;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
tcp_nodelay off;
client_max_body_size 30m;
keepalive_timeout 65;
include /etc/nginx/conf.d/*.conf;
}
conf.d
我已经删除了geo
部件中的一些特定于 IP 的行以及SSL
变体,以保持简单。如果需要,我可以替换它们,但归结geo
为 ssl 后端以及相应的上游和 conf 文件的额外部分。
geo $backend {
default apache-backend;
}
upstream apache-backend {
ip_hash;
server SERVER1 max_fails=3 fail_timeout=30s weight=2;
server SERVER2 max_fails=3 fail_timeout=30s weight=3;
}
conf.d/somestring.conf
limit_conn_zone $binary_remote_addr zone=somestring:10m;
server {
listen ip1:80;
listen ip2:80;
server_name name.tld www.name.tld;
root PATH
access_log PATH/name.log main;
location / {
proxy_pass http://$backend;
}
//*some more locations**//
gzip on;
gzip_http_version 1.0;
gzip_comp_level 2;
gzip_proxied any;
gzip_min_length 1100;
gzip_buffers 16 8k;
gzip_types text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;
}
conf.d/proxy.conf
proxy_set_header Accept-Encoding "";
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_buffering on;
proxy_read_timeout 90;
proxy_buffer_size 32k;
proxy_buffers 8 32k;
proxy_busy_buffers_size 32k;
proxy_temp_file_write_size 32k;
简短的回答:试试这个你的位置块:
更长的解释:
我想我刚刚遇到了你描述的问题:
499
这些请求的状态,并且相同的请求出现在不同的上游节点事实证明,这实际上是 nginx 作为反向代理的默认行为,因此将其升级到更高版本将无法解决此问题,尽管此处给出了可能的解决方案,但这解决了另一个问题。
发生这种情况是因为 nginx 作为负载均衡器以循环方式选择上游节点。When the chosen node fails, the request is sent to the next node. 这里要注意的重要一点是节点故障默认归类为
error or timeout
. 由于您没有设置 aproxy_read_timeout
,因此默认值为 60 秒。所以在等待 60 秒后,nginx 会选择下一个节点并发送相同的请求。因此,一种解决方案是增加此超时,以便您可以完成长时间运行的操作,例如通过设置
proxy_read_timeout 120;
(或任何适合您需要的限制)。另一种选择是阻止反向代理尝试使用下一个节点,以防超时,通过设置
proxy_next_upstream error;
. 或者,您可以按照上面的建议设置这两个选项。从这个论坛主题中,我们了解到罪魁祸首可能是 SPDY。对于那个用户来说,禁用它似乎是一个解决方案,而且自从禁用它以来,我们也没有发布过双重帖子。
确切的问题,除了“SPDY 做到了”,目前尚不清楚,建议的解决方案(禁用 SPDY)的副作用显然是“不再有 SPDY”,但我们可以忍受。
在错误再次出现之前,我将其称为“修复”(或至少:问题的解决方案)。
编辑:我们还没有(25-02-2014)看到这个问题出现了,所以这确实是一个持久的解决方案。