首先講解兩個算發：
算法思想是：
- 令牌以固定速率產生，並緩存到令牌桶中；
- 令牌桶放滿時，多余的令牌被丟棄；
- 請求要消耗等比例的令牌才能被處理；
- 令牌不夠時，請求被緩存。
--------------------------------------------------------------------------------------------------------------------------------------
漏桶算法：
算法思想是：
- 水（請求）從上方倒入水桶，從水桶下方流出（被處理）；
- 來不及流出的水存在水桶中（緩沖），以固定速率流出；
- 水桶滿后水溢出（丟棄）。
- 這個算法的核心是：緩存請求、勻速處理、多余的請求直接丟棄。
相比漏桶算法，令牌桶算法不同之處在於它不但有一只“桶”，還有個隊列，這個桶是用來存放令牌的，隊列才是用來存放請求的。
從作用上來說，漏桶和令牌桶算法最明顯的區別就是是否允許突發流量(burst)的處理，漏桶算法能夠強行限制數據的實時傳輸（處理）速率，對突發流量不做額外處理；而令牌桶算法能夠在限制數據的平均傳輸速率的同時允許某種程度的突發傳輸。
Nginx按請求速率限速模塊使用的是漏桶算法，即能夠強行保證請求的實時處理速度不會超過設置的閾值。
------------------------------------------------------------------------------------------------------------------------------------
官方限制ip並發連接和請求有兩個模塊，不需要重新編譯安裝，nginx默認已經集成。
limit_req_zone : 限制請求數
limit_conn_zone ：限制並發連接數
limit_req_zone 參數配置 limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;
參數講解：
$binary_remote_addr:遠程的訪問地址，此處以二進制的形式記錄
zone:=one:10m :設置一個名字為one,大小為10M的緩存空間
rate=10r/s: 限制訪問速率，此處設置為每秒接受10個請求（nging里是按ms及時的，此處為s）
limit_req zone=one burst=5 nodelay;
參數講解：
zone=one:指定使用名字為one的這個緩存空間，若沒有設置burst參數，結合上文，此處的配置表示為每秒接受請求10個
burst=5:因為我們的流量並不是向漏桶一樣每時每刻都是勻速的，所以為了避免某一時刻出現大規模的流量出現，所以我們添加burst參數，此處配置表示為，設置一個大小為5的緩沖區，當有大量請求（爆發）過來時，訪問超過了上面的限制可以先放到緩沖區內。
nodelay:一般是和burst一起使用的，如果設置了nodelay，當訪問超過了頻次而且緩沖區也滿的情況下會直接返回503，如果設置了，則所有大的請求會等待排隊。
limit_conn_log_level error; #定義當服務器由於limint被限制或緩存時，配置寫入日志。延遲的記錄比拒絕的記錄低一個級別。例子：limit_req_log_level notice延遲的的基本是info。
limit_conn_status 589; #當客戶端配置得並發數超過了nginx限制的數量后會返回的狀態值
limit_conn_zone $binary_remote_addr zone=one:10m;
limit_conn_zone $server_name zone=perserver:10m;
limit_req_zone $binary_remote_addr zone=allips:100m rate=20r/s;
server {
listen 8888;
access_log /var/log/nginx/example_http.log;
location /status {
stub_status on;
access_log off;
allow 127.0.0.1;
allow 10.0.17.27;
allow 10.0.1.142;
deny all;
}
location / {
limit_conn one 5; #限制每個用戶連接到服務器的數量
limit_conn perserver 2000;#限制連接到服務器的總數
limit_req zone=allips burst=200 nodelay;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_pass http://test;
#Proxy Settings
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
#proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-For $http_x_forwarded_for;
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
proxy_ignore_client_abort on;
proxy_max_temp_file_size 0;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
}
}
總結與心得：
1.在設置完上面的參數后，使用jmeter進行壓測時會發現，neginx的日志顯示沒秒的請求數永遠是20（前段設置的rate是每秒處理20個），發現burst的參數並沒有起作用，后來我把burst參數設置為2000，發現前幾秒tps可以達到四五百，但是后面依舊恢復到20.並不向我想的一樣，會一直超過20個tps運行先去，所以這個burst的時間也是有限制的， 並不是大流量下一直有用，所以在生產配置的時候一定要想好rate的參數值，因為burst只適用突發的以小段時間。
2.第二次我啟用了兩個客戶端去壓測，發現nginx的tps的值達到了40，因此得出結論，此處限制只是針對單個ip,並不是全局配置。兩個客戶端的壓測時間我故意間隔了幾分鍾，發現出現了兩次四五百的tps,后面一樣回歸到40tps不變。因此burst也是針對ip有限制的。
3，使用了ab進行壓測，ab -n 40 -c 20 http://IP/index.html 發現我rate設置的值不管是多少永遠只有一個是失敗的，貌似rate沒有起作用，是一個大坑。
root@in-yeerqianghe:/# ab -n 50 -c 20 http://10.0.18.128/index.html This is ApacheBench, Version 2.3 <$Revision: 1706008 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking 10.0.18.128 (be patient).....done Server Software: nginx/1.12.2 Server Hostname: 10.0.18.128 Server Port: 80 Document Path: /index.html Document Length: 14 bytes Concurrency Level: 20 Time taken for tests: 0.006 seconds Complete requests: 50 Failed requests: 49 (Connect: 0, Receive: 0, Length: 49, Exceptions: 0) Non-2xx responses: 49 Total transferred: 36063 bytes HTML transferred: 26327 bytes Requests per second: 8579.27 [#/sec] (mean) Time per request: 2.331 [ms] (mean) Time per request: 0.117 [ms] (mean, across all concurrent requests) Transfer rate: 6042.86 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 1 0.2 1 1 Processing: 1 1 0.5 1 2 Waiting: 1 1 0.5 1 2 Total: 1 2 0.3 2 3 Percentage of the requests served within a certain time (ms) 50% 2 66% 2 75% 2 80% 2 90% 3 95% 3 98% 3 99% 3 100% 3 (longest request)