是的，NGINX当然可以！
您可以执行以下DFA：
基于实施速率限制，$http_referer可能通过使用一些正则表达式map将值标准化。当超出限制时，将引发一个内部错误页面，您可以根据相关问题通过error_page处理程序进行处理，并转到一个新的内部位置作为内部重定向（客户端不可见）。
在以上超出限制的位置，您将执行警报请求，让外部逻辑执行通知；随后将缓存此请求，以确保您在给定的时间范围内仅收到1个唯一请求。
捕获先前请求的HTTP状态代码（返回状态代码≥300并使用proxy_intercept_errors on，或者使用not-default-by-default auth_request或add_after_body进行“免费”子请求），然后像完成原始请求一样之前的步骤没有涉及。请注意，我们需要启用递归error_page处理才能起作用。
这是我的PoC和MVP，也位于https://github.com/cnst/StackOverflow.cnst.nginx.conf/blob/master/sf.432636.detecting-slashdot-effect-in-nginx.conf：
limit_req_zone $http_referer zone=slash:10m rate=1r/m; # XXX: how many req/minute?
server {
listen 2636;
location / {
limit_req zone=slash nodelay;
#limit_req_status 429; #nginx 1.3.15
#error_page 429 = @dot;
error_page 503 = @dot;
proxy_pass http://localhost:2635;
# an outright `return 200` has a higher precedence over the limit
}
recursive_error_pages on;
location @dot {
proxy_pass http://127.0.0.1:2637/?ref=$http_referer;
# if you don't have `resolver`, no URI modification is allowed:
#proxy_pass http://localhost:2637;
proxy_intercept_errors on;
error_page 429 = @slash;
}
location @slash {
# XXX: placeholder for your content:
return 200 "$uri: we're too fast!\n";
}
}
server {
listen 2635;
# XXX: placeholder for your content:
return 200 "$uri: going steady\n";
}
proxy_cache_path /tmp/nginx/slashdotted inactive=1h
max_size=64m keys_zone=slashdotted:10m;
server {
# we need to flip the 200 status into the one >=300, so that
# we can then catch it through proxy_intercept_errors above
listen 2637;
error_page 429 @/.;
return 429;
location @/. {
proxy_cache slashdotted;
proxy_cache_valid 200 60s; # XXX: how often to get notifications?
proxy_pass http://localhost:2638;
}
}
server {
# IRL this would be an actual script, or
# a proxy_pass redirect to an HTTP to SMS or SMTP gateway
listen 2638;
return 200 authorities_alerted\n;
}
请注意，这按预期工作：
% sh -c 'rm /tmp/slashdotted.nginx/*; mkdir /tmp/slashdotted.nginx; nginx -s reload; for i in 1 2 3; do curl -H "Referer: test" localhost:2636; sleep 2; done; tail /var/log/nginx/access.log'
/: going steady
/: we're too fast!
/: we're too fast!
127.0.0.1 - - [26/Aug/2017:02:05:49 +0200] "GET / HTTP/1.1" 200 16 "test" "curl/7.26.0"
127.0.0.1 - - [26/Aug/2017:02:05:49 +0200] "GET / HTTP/1.0" 200 16 "test" "curl/7.26.0"
127.0.0.1 - - [26/Aug/2017:02:05:51 +0200] "GET / HTTP/1.1" 200 19 "test" "curl/7.26.0"
127.0.0.1 - - [26/Aug/2017:02:05:51 +0200] "GET /?ref=test HTTP/1.0" 200 20 "test" "curl/7.26.0"
127.0.0.1 - - [26/Aug/2017:02:05:51 +0200] "GET /?ref=test HTTP/1.0" 429 20 "test" "curl/7.26.0"
127.0.0.1 - - [26/Aug/2017:02:05:53 +0200] "GET / HTTP/1.1" 200 19 "test" "curl/7.26.0"
127.0.0.1 - - [26/Aug/2017:02:05:53 +0200] "GET /?ref=test HTTP/1.0" 429 20 "test" "curl/7.26.0"
%
您可以看到，第一个请求导致一个前端和一个后端命中，这与预期的一样（我必须向具有的位置添加一个虚拟后端limit_req，因为a return 200优先于限制，所以不需要真实的后端对于其余的处理）。
第二个请求超出了限制，因此，我们发送警报（获取200），并将其缓存，然后返回429（由于上述限制，无法捕获低于300的请求，因此这是必要的），随后被前端捕获，现在可以免费进行任何所需的操作了。
第三个请求仍超出限制，但是我们已经发送了警报，因此，不会发送新的警报。
做完了！ 不要忘记在GitHub上进行分叉！