聊聊高并发系统限流特技-2

接上文的聊聊高并发系统限流特技-1
原文来自开涛的博客,找不到第此原文链接了

接入层限流

接入层通常指请求流量的入口，该层的主要目的有：负载均衡、非法请求过滤、请求聚合、缓存、降级、限流、A/B测试、服务质量监控等等，可以参考笔者写的《使用Nginx+Lua(OpenResty)开发高性能Web应用》。
对于Nginx接入层限流可以使用Nginx自带了两个模块：连接数限流模块ngx_http_limit_conn_module和漏桶算法实现的请求限流模块ngx_http_limit_req_module。
还可以使用OpenResty提供的Lua限流模块lua-resty-limit-traffic进行更复杂的限流场景。
limit_conn用来对某个KEY对应的总的网络连接数进行限流，可以按照如IP、域名维度进行限流。limit_req用来对某个KEY对应的请求的平均速率进行限流，并有两种用法：平滑模式（delay）和允许突发模式(nodelay)。

ngx_http_limit_conn_module

limit_conn是对某个KEY对应的总的网络连接数进行限流。可以按照IP来限制IP维度的总连接数，或者按照服务域名来限制某个域名的总连接数。但是记住不是每一个请求连接都会被计数器统计，只有那些被Nginx处理的且已经读取了整个请求头的请求连接才会被计数器统计。
配置示例：

http {
limit_conn_zone$binary_remote_addr zone=addr:10m;
limit_conn_log_level error;
limit_conn_status 503;
...
server {
...
location /limit {
limit_conn addr 1;
}

limit_conn：要配置存放KEY和计数器的共享内存区域和指定KEY的最大连接数；此处指定的最大连接数是1，表示Nginx最多同时并发处理1个连接；
limit_conn_zone：用来配置限流KEY、及存放KEY对应信息的共享内存区域大小；此处的KEY是“$binary_remote_addr”其表示IP地址，也可以使用如$server_name作为KEY来限制域名级别的最大连接数；
limit_conn_status：配置被限流后返回的状态码，默认返回503；
limit_conn_log_level：配置记录被限流后的日志级别，默认error级别。
limit_conn的主要执行过程如下所示：
1、请求进入后首先判断当前limit_conn_zone中相应KEY的连接数是否超出了配置的最大连接数；
2.1、如果超过了配置的最大大小，则被限流，返回limit_conn_status定义的错误状态码；
2.2、否则相应KEY的连接数加1，并注册请求处理完成的回调函数；
3、进行请求处理；
4、在结束请求阶段会调用注册的回调函数对相应KEY的连接数减1。
limt_conn可以限流某个KEY的总并发/请求数，KEY可以根据需要变化。

按照IP限制并发连接数配置示例：

首先定义IP维度的限流区域：
limit_conn_zone $binary_remote_addrzone=perip:10m;
接着在要限流的location中添加限流逻辑：

location /limit {
limit_conn perip 2;
echo "123";
}

- 即允许每个IP最大并发连接数为2。
- 使用AB测试工具进行测试，并发数为5个，总的请求数为5个：
  - ab -n 5 -c 5 http://localhost/limit
将得到如下access.log输出：

[08/Jun/2016:20:10:51+0800] [1465373451.802] 200
[08/Jun/2016:20:10:51+0800] [1465373451.803] 200
[08/Jun/2016:20:10:51 +0800][1465373451.803] 503
[08/Jun/2016:20:10:51 +0800][1465373451.803] 503
[08/Jun/2016:20:10:51 +0800][1465373451.803] 503

- 此处我们把access log格式设置为log_format main  '[$time_local] [$msec] $status'；分别是“日期日期秒/毫秒值响应状态码”。
如果被限流了，则在error.log中会看到类似如下的内容：

2016/06/08 20:10:51 [error] 5662#0: *5limiting connections by zone "perip", client: 127.0.0.1, server: _,request: "GET /limit HTTP/1.0", host: "localhost"

**按照域名限制并发连接数配置示例：**
- 首先定义域名维度的限流区域：
    - limit_conn_zone $ server_name zone=perserver:10m;
- 接着在要限流的location中添加限流逻辑：

location /limit {
limit_conn perserver 2;
echo "123";
}

- 即允许每个域名最大并发请求连接数为2；这样配置可以实现服务器最大连接数限制。

**ngx_http_limit_req_module**
- limit_req是令牌桶算法实现，用于对指定KEY对应的请求进行限流，比如按照IP维度限制请求速率。
**配置示例：**

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
limit_conn_log_level error;
limit_conn_status 503;
...
server {
...
location /limit {
limit_req zone=one burst=5 nodelay;
}

- limit_req：配置限流区域、桶容量（突发容量，默认0）、是否延迟模式（默认延迟）；
- limit_req_zone：配置限流KEY、及存放KEY对应信息的共享内存区域大小、固定请求速率；此处指定的KEY是“$binary_remote_addr”表示IP地址；固定请求速率使用rate参数配置，支持10r/s和60r/m，即每秒10个请求和每分钟60个请求，不过最终都会转换为每秒的固定请求速率（10r/s为每100毫秒处理一个请求；60r/m，即每1000毫秒处理一个请求）。
- limit_conn_status：配置被限流后返回的状态码，默认返回503；
- limit_conn_log_level：配置记录被限流后的日志级别，默认error级别。
- limit_req的主要执行过程如下所示：
1、请求进入后首先判断最后一次请求时间相对于当前时间（第一次是0）是否需要限流，如果需要限流则执行步骤2，否则执行步骤3；
2.1、如果没有配置桶容量（burst），则桶容量为0；按照固定速率处理请求；如果请求被限流，则直接返回相应的错误码（默认503）；
2.2、如果配置了桶容量（burst>0）且延迟模式(没有配置nodelay)；如果桶满了，则新进入的请求被限流；如果没有满则请求会以固定平均速率被处理（按照固定速率并根据需要延迟处理请求，延迟使用休眠实现）；
2.3、如果配置了桶容量（burst>0）且非延迟模式（配置了nodelay）；不会按照固定速率处理请求，而是允许突发处理请求；如果桶满了，则请求被限流，直接返回相应的错误码；
3、如果没有被限流，则正常处理请求；
4、Nginx会在相应时机进行选择一些（3个节点）限流KEY进行过期处理，进行内存回收。

###场景2.1测试
- **首先定义IP维度的限流区域：**
  - limit_req_zone $binary_remote_addrzone=test:10m rate=500r/s;
  - 限制为每秒500个请求，固定平均速率为2毫秒一个请求。

- 接着在要限流的location中添加**限流逻辑**：

location /limit {
limit_req zone=test;
echo "123";
}

  - 即桶容量为0（burst默认为0），且延迟模式。

** 使用AB测试工具进行测试，并发数为2个，总的请求数为10个**
 - ab -n 10 -c 2 http://localhost/limit

  将得到如下access.log输出：

[08/Jun/2016:20:25:56+0800] [1465381556.410] 200
[08/Jun/2016:20:25:56 +0800][1465381556.410] 503
[08/Jun/2016:20:25:56 +0800][1465381556.411] 503
[08/Jun/2016:20:25:56+0800] [1465381556.411] 200
[08/Jun/2016:20:25:56 +0800][1465381556.412] 503
[08/Jun/2016:20:25:56 +0800][1465381556.412] 503

- 虽然每秒允许500个请求，但是因为桶容量为0，所以流入的请求要么被处理要么被限流，无法延迟处理；另外平均速率在2毫秒左右，比如1465381556.410和1465381556.411被处理了；有朋友会说这固定平均速率不是1毫秒嘛，其实这是因为实现算法没那么精准造成的。
如果被限流在error.log中会看到如下内容：

2016/06/08 20:25:56 [error] 6130#0: *1962limiting requests, excess: 1.000 by zone "test", client: 127.0.0.1,server: _, request: "GET /limit HTTP/1.0", host:"localhost"

- 如果被延迟了在error.log（日志级别要INFO级别）中会看到如下内容：

2016/06/10 09:05:23 [warn] 9766#0: *97021delaying request, excess: 0.368, by zone "test", client: 127.0.0.1,server: _, request: "GET /limit HTTP/1.0", host:"localhost"


####场景2.2测试
- 首先定义IP维度的限流区域：
limit_req_zone $binary_remote_addr    zone=test:10m rate=2r/s;
- 为了方便测试设置速率为每秒2个请求，即固定平均速率是500毫秒一个请求。
**接着在要限流的location中添加限流逻辑**

location /limit {
limit_req zone=test burst=3;
echo "123";
}

- 固定平均速率为500毫秒一个请求，通容量为3，如果桶满了新的请求被限流，否则可以进入桶中排队并等待（实现延迟模式）。

    **为了看出限流效果我们写了一个req.sh脚本：**

ab -c 6 -n 6 http://localhost/limit
sleep 0.3
ab -c 6 -n 6 http://localhost/limit

- 首先进行6个并发请求6次URL，然后休眠300毫秒，然后再进行6个并发请求6次URL；中间休眠目的是为了能跨越2秒看到效果，如果看不到如下的效果可以调节休眠时间。
将得到如下access.log输出：

[09/Jun/2016:08:46:43+0800] [1465433203.959] 200
[09/Jun/2016:08:46:43 +0800][1465433203.959] 503
[09/Jun/2016:08:46:43 +0800][1465433203.960] 503
[09/Jun/2016:08:46:44+0800] [1465433204.450] 200
[09/Jun/2016:08:46:44+0800] [1465433204.950] 200
[09/Jun/2016:08:46:45 +0800][1465433205.453] 200
[09/Jun/2016:08:46:45 +0800][1465433205.766] 503
[09/Jun/2016:08:46:45 +0800][1465433205.766] 503
[09/Jun/2016:08:46:45 +0800][1465433205.767] 503
[09/Jun/2016:08:46:45+0800] [1465433205.950] 200
[09/Jun/2016:08:46:46+0800] [1465433206.451] 200
[09/Jun/2016:08:46:46+0800] [1465433206.952] 200

![](http://upload-images.jianshu.io/upload_images/2231755-f2653fb9d886372e?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

- 桶容量为3，即桶中在时间窗口内最多流入3个请求，且按照2r/s的固定速率处理请求（即每隔500毫秒处理一个请求）；桶计算时间窗口（1.5秒）=速率（2r/s）/桶容量(3)，也就是说在这个时间窗口内桶最多暂存3个请求。因此我们要以当前时间往前推1.5秒和1秒来计算时间窗口内的总请求数；另外因为默认是延迟模式，所以时间窗内的请求要被暂存到桶中，并以固定平均速率处理请求：
  - 第一轮：有4个请求处理成功了，按照漏桶桶容量应该最多3个才对；这是因为计算算法的问题，第一次计算因没有参考值，所以第一次计算后，后续的计算才能有参考值，因此第一次成功可以忽略；这个问题影响很小可以忽略；而且按照固定500毫秒的速率处理请求。
  - 第二轮：因为第一轮请求是突发来的，差不多都在1465433203.959时间点，只是因为漏桶将速率进行了平滑变成了固定平均速率（每500毫秒一个请求）；而第二轮计算时间应基于1465433203.959；而第二轮突发请求差不多都在1465433205.766时间点，因此计算桶容量的时间窗口应基于1465433203.959和1465433205.766来计算，计算结果为1465433205.766这个时间点漏桶为空了，可以流入桶中3个请求，其他请求被拒绝；又因为第一轮最后一次处理时间是1465433205.453，所以第二轮第一个请求被延迟到了1465433205.950。这里也要注意固定平均速率只是在配置的速率左右，存在计算精度问题，会有一些偏差。

  **如果桶容量改为1（burst=1），执行req.sh脚本可以看到如下输出：**

[09/Jun/2016:09:04:30+0800] [1465434270.362] 200
[09/Jun/2016:09:04:30 +0800][1465434270.371] 503
[09/Jun/2016:09:04:30 +0800] [1465434270.372]503
[09/Jun/2016:09:04:30 +0800][1465434270.372] 503
[09/Jun/2016:09:04:30 +0800][1465434270.372] 503
[09/Jun/2016:09:04:30+0800] [1465434270.864] 200
[09/Jun/2016:09:04:31 +0800][1465434271.178] 503
[09/Jun/2016:09:04:31 +0800][1465434271.178] 503
[09/Jun/2016:09:04:31 +0800][1465434271.178] 503
[09/Jun/2016:09:04:31 +0800][1465434271.178] 503
[09/Jun/2016:09:04:31 +0800][1465434271.179] 503
[09/Jun/2016:09:04:31+0800] [1465434271.366] 200

- 桶容量为1，按照每1000毫秒一个请求的固定平均速率处理请求。

###场景2.3测试

- 首先定义IP维度的限流区域：
limit_req_zone $binary_remote_addrzone=test:10m rate=2r/s;
- 为了方便测试配置为每秒2个请求，固定平均速率是500毫秒一个请求。
**接着在要限流的location中添加限流逻辑：**

location /limit {
limit_req zone=test burst=3 nodelay;
echo "123";
}

- 桶容量为3，如果桶满了直接拒绝新请求，且每秒2最多两个请求，桶按照固定500毫秒的速率以nodelay模式处理请求。
**为了看到限流效果我们写了一个req.sh脚本：**

ab -c 6 -n 6 http://localhost/limit
sleep 1
ab -c 6 -n 6 http://localhost/limit
sleep 0.3
ab -c 6 -n 6 http://localhost/limit
sleep 0.3
ab -c 6 -n 6 http://localhost/limit
sleep 0.3
ab -c 6 -n 6 http://localhost/limit
sleep 2
ab -c 6 -n 6 http://localhost/limit

将得到类似如下access.log输出：

[09/Jun/2016:14:30:11+0800] [1465453811.754] 200
[09/Jun/2016:14:30:11+0800] [1465453811.755] 200
[09/Jun/2016:14:30:11+0800] [1465453811.755] 200
[09/Jun/2016:14:30:11+0800] [1465453811.759] 200
[09/Jun/2016:14:30:11 +0800][1465453811.759] 503
[09/Jun/2016:14:30:11 +0800][1465453811.759] 503
[09/Jun/2016:14:30:12+0800] [1465453812.776] 200
[09/Jun/2016:14:30:12+0800] [1465453812.776] 200
[09/Jun/2016:14:30:12 +0800][1465453812.776] 503
[09/Jun/2016:14:30:12 +0800][1465453812.777] 503
[09/Jun/2016:14:30:12 +0800][1465453812.777] 503
[09/Jun/2016:14:30:12 +0800][1465453812.777] 503
[09/Jun/2016:14:30:13 +0800] [1465453813.095]503
[09/Jun/2016:14:30:13 +0800][1465453813.097] 503
[09/Jun/2016:14:30:13 +0800][1465453813.097] 503
[09/Jun/2016:14:30:13 +0800][1465453813.097] 503
[09/Jun/2016:14:30:13 +0800][1465453813.097] 503
[09/Jun/2016:14:30:13 +0800][1465453813.098] 503
[09/Jun/2016:14:30:13+0800] [1465453813.425] 200
[09/Jun/2016:14:30:13 +0800][1465453813.425] 503
[09/Jun/2016:14:30:13 +0800][1465453813.425] 503
[09/Jun/2016:14:30:13 +0800][1465453813.426] 503
[09/Jun/2016:14:30:13 +0800][1465453813.426] 503
[09/Jun/2016:14:30:13 +0800][1465453813.426] 503
[09/Jun/2016:14:30:13+0800] [1465453813.754] 200
[09/Jun/2016:14:30:13 +0800][1465453813.755] 503
[09/Jun/2016:14:30:13 +0800][1465453813.755] 503
[09/Jun/2016:14:30:13 +0800][1465453813.756] 503
[09/Jun/2016:14:30:13 +0800][1465453813.756] 503
[09/Jun/2016:14:30:13 +0800][1465453813.756] 503
[09/Jun/2016:14:30:15+0800] [1465453815.278] 200
[09/Jun/2016:14:30:15+0800] [1465453815.278] 200
[09/Jun/2016:14:30:15+0800] [1465453815.278] 200
[09/Jun/2016:14:30:15 +0800][1465453815.278] 503
[09/Jun/2016:14:30:15 +0800][1465453815.279] 503
[09/Jun/2016:14:30:15 +0800][1465453815.279] 503
[09/Jun/2016:14:30:17+0800] [1465453817.300] 200
[09/Jun/2016:14:30:17+0800] [1465453817.300] 200
[09/Jun/2016:14:30:17+0800] [1465453817.300] 200
[09/Jun/2016:14:30:17+0800] [1465453817.301] 200
[09/Jun/2016:14:30:17 +0800][1465453817.301] 503
[09/Jun/2016:14:30:17 +0800][1465453817.301] 503

![](http://upload-images.jianshu.io/upload_images/2231755-4d7ec75f5fc80018?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

- 桶容量为3（，即桶中在时间窗口内最多流入3个请求，且按照2r/s的固定速率处理请求（即每隔500毫秒处理一个请求）；桶计算时间窗口（1.5秒）=速率（2r/s）/桶容量(3)，也就是说在这个时间窗口内桶最多暂存3个请求。因此我们要以当前时间往前推1.5秒和1秒来计算时间窗口内的总请求数；另外因为配置了nodelay，是非延迟模式，所以允许时间窗内突发请求的；另外从本示例会看出两个问题：
  - 第一轮和第七轮：有4个请求处理成功了；这是因为计算算法的问题，本示例是如果2秒内没有请求，然后接着突然来了很多请求，第一次计算的结果将是不正确的；这个问题影响很小可以忽略；
  - 第五轮：1.0秒计算出来是3个请求；此处也是因计算精度的问题，也就是说limit_req实现的算法不是非常精准的，假设此处看成相对于2.75的话，1.0秒内只有1次请求，所以还是允许1次请求的。
**如果限流出错了，可以配置错误页面：**

proxy_intercept_errors****on;****recursive_error_pages****on;****error_page 503****//www.jd.com/error.aspx;

- limit_conn_zone/limit_req_zone定义的内存不足，则后续的请求将一直被限流，所以需要根据需求设置好相应的内存大小。
- 此处的限流都是单Nginx的，假设我们接入层有多个nginx，此处就存在和应用级限流相同的问题；那如何处理呢？
  - 一种解决办法：建立一个负载均衡层将按照限流KEY进行一致性哈希算法将请求哈希到接入层Nginx上，从而相同KEY的将打到同一台接入层Nginx上；
  - 另一种解决方案就是使用Nginx+Lua（OpenResty）调用分布式限流逻辑实现。

**lua-resty-limit-traffic**
- 之前介绍的两个模块使用上比较简单，指定KEY、指定限流速率等就可以了，如果我们想根据实际情况变化KEY、变化速率、变化桶大小等这种动态特性，使用标准模块就很难去实现了，因此我们需要一种可编程来解决我们问题；
- 而OpenResty提供了lua限流模块lua-resty-limit-traffic，通过它可以按照更复杂的业务逻辑进行动态限流处理了。其提供了limit.conn和limit.req实现，算法与nginx limit_conn和limit_req是一样的。
- 此处我们来实现ngx_http_limit_req_module中的【场景2.2测试】，不要忘记下载**lua-resty-limit-traffic模块并添加到OpenResty的lualib中**。

**配置用来存放限流用的共享字典：**
- lua_shared_dict limit_req_store 100m;
**以下是实现【场景2.2测试】的限流代码limit_req.lua：**

local limit_req = require "resty.limit.req"
local rate = 2 --固定平均速率 2r/s
local burst = 3 --桶容量
local error_status = 503
local nodelay = false --是否需要不延迟处理
local lim, err = limit_req.new("limit_req_store", rate, burst)
if not lim then --没定义共享字典
ngx.exit(error_status)
end
local key = ngx.var.binary_remote_addr --IP维度的限流
--流入请求，如果请求需要被延迟则delay > 0
local delay, err = lim:incoming(key, true)
if not delay and err == "rejected" then --超出桶大小了
ngx.exit(error_status)
end
if delay > 0 then --根据需要决定是延迟或者不延迟处理
if nodelay then
--直接突发处理了
else
ngx.sleep(delay) --延迟处理
end
end

- 即限流逻辑再nginx access阶段被访问，如果不被限流继续后续流程；如果需要被限流要么sleep一段时间继续后续流程，要么返回相应的状态码拒绝请求。
- 在分布式限流中我们使用了简单的Nginx+Lua进行分布式限流，有了这个模块也可以使用这个模块来实现分布式限流。
- 另外在使用Nginx+Lua时也可以获取ngx.var.connections_active进行过载保护，即如果当前活跃连接数超过阈值进行限流保护。

if tonumber(ngx.var.connections_active) >= tonumber(limit) then//限流end

- 到此笔者在工作中涉及的限流用法就介绍完，这些算法中有些允许突发，有些会整形为平滑，有些计算算法简单粗暴；其中令牌桶算法和漏桶算法实现上是类似的，只是表述的方向不太一样，对于业务来说不必刻意去区分它们；因此需要根据实际场景来决定如何限流，最好的算法不一定是最适用的。
**参考资料**
- https://en.wikipedia.org/wiki/Token_bucket
- https://en.wikipedia.org/wiki/Leaky_bucket
- http://redis.io/commands/incr
- http://nginx.org/en/docs/http/ngx_http_limit_req_module.html
- http://nginx.org/en/docs/http/ngx_http_limit_conn_module.html
- https://github.com/openresty/lua-resty-limit-traffic

最后编辑于：2017.12.03 06:40:16

人面猴
序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
沈念sama阅读 206,214评论 6赞 481
死咒
序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
沈念sama阅读 88,307评论 2赞 382
救了他两次的神仙让他今天三更去死
文/潘晓璐我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
开封第一讲书人阅读 152,543评论 0赞 341
道士缉凶录：失踪的卖姜人
文/不坏的土叔我叫张陵，是天一观的道长。经常有香客问我，道长，这世上最难降的妖魔是什么？我笑而不...
开封第一讲书人阅读 55,221评论 1赞 279
港岛之恋（遗憾婚礼）
正文为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
茶点故事阅读 64,224评论 5赞 371
恶毒庶女顶嫁案：这布局不是一般人想出来的
文/花漫我一把揭开白布。她就那样静静地躺着，像睡着了一般。火红的嫁衣衬着肌肤如雪。梳的纹丝不乱的头发上，一...
开封第一讲书人阅读 49,007评论 1赞 284
城市分裂传说
那天，我揣着相机与录音，去河边找鬼。笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。我是一名探鬼主播，决...
沈念sama阅读 38,313评论 3赞 399
双鸳鸯连环套：你想象不到人心有多黑
文/苍兰香墨我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
开封第一讲书人阅读 36,956评论 0赞 259
万荣杀人案实录
序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
沈念sama阅读 43,441评论 1赞 300
护林员之死
正文独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋以下内容为张勋视角年9月15日...
茶点故事阅读 35,925评论 2赞 323
白月光启示录
正文我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
茶点故事阅读 38,018评论 1赞 333
活死人
序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
沈念sama阅读 33,685评论 4赞 322
日本核电站爆炸内幕
正文年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
茶点故事阅读 39,234评论 3赞 307
男人毒药：我在死后第九天来索命
文/蒙蒙一、第九天我趴在偏房一处隐蔽的房顶上张望。院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
开封第一讲书人阅读 30,240评论 0赞 19
一桩弑父案，背后竟有这般阴谋
文/苍兰香墨我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。一阵脚步声响...
开封第一讲书人阅读 31,464评论 1赞 261
情欲美人皮
我被黑心中介骗来泰国打工，没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。一个月前我还...
沈念sama阅读 45,467评论 2赞 352
代替公主和亲
正文我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
茶点故事阅读 42,762评论 2赞 345

聊聊高并发系统限流特技-2

接入层限流

推荐阅读更多精彩内容