☰

所有请求都进入 ELB 激增队列

tag-icon • tag-icon nginx amazon-web-services amazon-elb amazon-cloudwatch
所有请求都进入 ELB 激增队列

问题：似乎我们应用程序的每个请求最终都会进入 ELB 激增队列

激增队列图的示例： 在此处输入图片描述

我们在 AWS 上有一个经典的 ELB，其后有多个 EC2 盒。ELB 侦听器以以下方式设置

LB Protocol  LB Port  Instance Protocol  Instance Port  Cipher SSL  Certificate 
TCP          80       TCP                80              N/A        N/A

在 EC2 实例上，我们有一个 nginx 服务器，其中有以下 nginx.conf：

user nginx;
worker_processes 3;
pid /var/run/nginx.pid;
worker_rlimit_nofile 8192;
worker_rlimit_sigpending 32768;

events {
  worker_connections 2048;
  multi_accept on;
  use epoll;
  accept_mutex off;
}

http {
  sendfile on;
  tcp_nopush on;
  tcp_nodelay on;
  keepalive_timeout 65;
  types_hash_max_size 2048;
  map_hash_bucket_size 128;
  server_tokens off;
  client_max_body_size 0;
  server_names_hash_bucket_size 256;

  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" $request_time';

  access_log /app/log/nginx/access.log main;
  error_log /app/log/nginx/error.log;

  gzip on;
  gzip_disable "msie6";

  gzip_vary on;
  gzip_comp_level 4;
  gzip_buffers 16 8k;
  gzip_http_version 1.1;
  gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

  client_body_temp_path /app/tmp/nginx;:q

  include /etc/nginx/sites-enabled/*;

  upstream tomcat {
    server localhost:8080;
  }

  upstream httpd {
    server localhost:9000;
  }

  upstream play {
    server localhost:9000;
  }

和 vhost sites.conf

log_format  proxylog  '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$proxy_protocol_addr" $request_time';

server { 
  server_name     www.my-site.com;
  rewrite ^(.*)   http://my-site.com$1 permanent;
}

server {
  listen 80 proxy_protocol;

  listen 443 ssl proxy_protocol;
  ssl_certificate      /etc/nginx/my-certificate.crt;
  ssl_certificate_key  /etc/nginx/my-key.key;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers "SECRET";
  ssl_prefer_server_ciphers on;

  set_real_ip_from 10.0.0.0/8;
  root /app/websites/my-site.com/httpdocs;
  index index.html index.htm;
  real_ip_header proxy_protocol;

  server_name my-site.com;
  access_log /app/log/nginx/my-site.com.access.log proxylog buffer=16k flush=2s;
  error_log /app/log/nginx/my-site.com.error.log;

  charset utf-8;

  location /foo {
    proxy_pass http://play;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
  }

  location /bar {
    add_header Access-Control-Allow-Origin "*" always;
    add_header Access-Control-Allow-Methods "GET,POST,OPTIONS,DELETE,PUT" always;
    add_header 'Access-Control-Allow-Headers' 'Origin, X-Requested-With, Content-Type, Accept, User-Agent, Authorization, Referer, Timestamp' always;
    add_header Access-Control-Allow-Credentials true always;
    proxy_pass http://play;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
  }

  location / {
    add_header Access-Control-Allow-Origin "*" always;
    add_header Access-Control-Allow-Methods "GET,POST,OPTIONS,DELETE,PUT" always;
    add_header 'Access-Control-Allow-Headers' 'Origin, X-Requested-With, Content-Type, Accept, User-Agent, Authorization, Referer, Timestamp' always;
    add_header Access-Control-Allow-Credentials true always;

    real_ip_header proxy_protocol;
    set_real_ip_from 10.0.0.0/8;

    proxy_read_timeout 90s;
    proxy_set_header X-Real-IP $proxy_protocol_addr;
    proxy_set_header X-Forwarded-For $proxy_protocol_addr;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Server $host;
    proxy_pass  http://play;
    proxy_set_header Host $http_host;

  }

  location ~ ^/(images|css|js|html) {
    root /app/websites/my-site.com/httpdocs;
  }

  error_page  404              /404.html;

  error_page   500 502 503 504  /50x.html;
  location = /50x.html {
    root   html;
  }
}

我将问题的可能原因限制在 ELB 和 nginx 上，而不是最明显的——实际的 Web 服务器处理请求，因为在我的某个测试中，我完全删除了 Java 应用程序，并将其替换为一个虚拟的 node.js 服务器，该服务器对每个请求都回复“hello world”，但我仍然将所有这些请求记录在激增队列中。

我也尝试进行调整worker_processes，keepalive_timeout看看是否会产生什么影响，但结果没有。

让我感到困扰的是，这个 1 的激增队列不会影响服务的性能，因为看起来请求似乎只会在那里停留几分之一秒，但我不明白为什么即使是一个请求最终也会通过激增队列。

答案1

您的 ELB 是否已设置为 TCP？

如果是这样，您的 ELB 会将每个连接注册到 Surge 队列中。恐怕这是无法避免的。您必须使用 http 或 https 才能使 Surge 队列正常工作。

--

来自 OP 的更新

我创建了一个小型 EC2 实例，其中有一个简单的 TCP 服务器，它只会对每个请求回复“土豆”。我将其放在带有 TCP 侦听器的经典 ELB 后面，然后向我的新 ELB 发出单个请求，并检查了激增队列图表。

在此处输入图片描述

查看 AWS 文档传统负载均衡器的侦听器

当您使用 TCP（第 4 层）进行前端和后端连接时，负载均衡器会将请求转发到后端实例而不修改标头。负载均衡器收到请求后，会尝试在侦听器配置中指定的端口上打开与后端实例的 TCP 连接。

和这个：

对于 HTTP/HTTPS 负载均衡器后面的每个已注册且运行正常的实例，Elastic Load Balancing 都会打开并维护一个或多个 TCP 连接。这些连接确保始终有一个已建立的连接可供接收 HTTP/HTTPS 请求。

据我理解，这意味着每次我们调用 TCP 配置的 ELB 时，它都会将我们的请求放在一边，以便能够打开与我们的 EC2 的连接，然后再将请求传递给机器。

相关内容