首先讲解两个算发：
算法思想是：
- 令牌以固定速率产生，并缓存到令牌桶中；
- 令牌桶放满时，多余的令牌被丢弃；
- 请求要消耗等比例的令牌才能被处理；
- 令牌不够时，请求被缓存。
--------------------------------------------------------------------------------------------------------------------------------------
漏桶算法：
算法思想是：
- 水（请求）从上方倒入水桶，从水桶下方流出（被处理）；
- 来不及流出的水存在水桶中（缓冲），以固定速率流出；
- 水桶满后水溢出（丢弃）。
- 这个算法的核心是：缓存请求、匀速处理、多余的请求直接丢弃。
相比漏桶算法，令牌桶算法不同之处在于它不但有一只“桶”，还有个队列，这个桶是用来存放令牌的，队列才是用来存放请求的。
从作用上来说，漏桶和令牌桶算法最明显的区别就是是否允许突发流量(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)