一. 前言
ASP.NET Core Web API 接口限流、限制接口并發數量，我也不知道自己寫的有沒有問題，抛磚引玉、歡迎來噴！
二. 需求
- 寫了一個接口，參數可以傳多個人員，也可以傳單個人員，時間範圍限制最長一個月。簡單來說，當傳單個人員時，接口耗時很短，當傳多個人員時，一般人員會較多，接口耗時較長，一般耗時幾秒。
- 當傳多個人員時，并發量高時，接口的耗時就很長了，比如100個使用者并發請求，耗時可長達幾十秒，甚至1分鐘。
- 是以需求是，當傳單個人員時，不限制。當傳多個人員時，限制并發數量。如果并發使用者數少于限制數，那麼所有使用者都能成功。如果并發使用者數，超出限制數，那麼超出的使用者請求失敗，并提示"目前進行XXX查詢的使用者太多，請稍後再試"。
- 這樣也可以減輕被請求的ES叢集的壓力。
三. 說明
- 使用的是.NET6
- 我知道有人寫好了RateLimit中間件，但我暫時還沒有學會怎麼使用，能否滿足我的需求，是以先自己實作一下。
四. 效果截圖
下面是使用jMeter并發測試時，打的接口日志：
五. 代碼
1. RateLimitInterface
接口參數的實體類要繼承該接口
using JsonA = Newtonsoft.Json;
using JsonB = System.Text.Json.Serialization;
namespace Utils
{
/// <summary>
/// 限速接口
/// </summary>
public interface RateLimitInterface
{
/// <summary>
/// 是否限速
/// </summary>
[JsonA.JsonIgnore]
[JsonB.JsonIgnore]
bool IsLimit { get; }
}
}
2. 接口參數實體類
繼承RateLimitInterface接口，并實作IsLimit屬性
public class XxxPostData : RateLimitInterface
{
...省略
/// <summary>
/// 是否限速
/// </summary>
[JsonA.JsonIgnore]
[JsonB.JsonIgnore]
public bool IsLimit
{
get
{
if (peoples.Count > 2) //限速條件，自己定義
{
return true;
}
return false;
}
}
}
3. RateLimitAttribute
作用：标簽打在接口方法上，并設定并發數量
namespace Utils
{
/// <summary>
/// 接口限速
/// </summary>
public class RateLimitAttribute : Attribute
{
private Semaphore _sem;
public Semaphore Sem
{
get
{
return _sem;
}
}
public RateLimitAttribute(int limitCount = 1)
{
_sem = new Semaphore(limitCount, limitCount);
}
}
}
4. 使用RateLimitAttribute
标簽打在接口方法上，并設定并發數量。
伺服器好像是24核的，并發限制為8應該沒問題。
[HttpPost]
[Route("[action]")]
[RateLimit(8)]
public async Task<List<XxxInfo>> Query([FromBody] XxxPostData data)
{
...省略
}
5. 限制接口并發量的攔截器RateLimitFilter
/// <summary>
/// 接口限速
/// </summary>
public class RateLimitFilter : ActionFilterAttribute
{
public override async Task OnActionExecutionAsync(ActionExecutingContext context, ActionExecutionDelegate next)
{
Type controllerType = context.Controller.GetType();
object arg = context.ActionArguments.Values.ToList()[0];
var rateLimit = context.ActionDescriptor.EndpointMetadata.OfType<RateLimitAttribute>().FirstOrDefault();
bool isLimit = false; //是否限速
if (rateLimit != null && arg is RateLimitInterface) //接口方法打了RateLimitAttribute标簽并且參數實體類實作了RateLimitInterface接口時才限速，否則不限速
{
RateLimitInterface model = arg as RateLimitInterface;
if (model.IsLimit) //滿足限速條件
{
isLimit = true;
Semaphore sem = rateLimit.Sem;
if (sem.WaitOne(0)) //注意：逾時時間為0，表示不等待
{
try
{
await next.Invoke();
}
catch
{
throw;
}
finally
{
sem.Release();
}
}
else
{
var routeList = context.RouteData.Values.Values.ToList();
routeList.Reverse();
var route = string.Join('/', routeList.ConvertAll(a => a.ToString()));
var msg = #34;目前通路{route}接口的使用者數太多，請稍後再試";
LogUtil.Info(msg);
context.Result = new ObjectResult(new ApiResult
{
code = (int)HttpStatusCode.ServiceUnavailable,
message = "目前查詢的使用者太多，請稍後再試。"
});
}
}
}
if (!isLimit)
{
await next.Invoke();
}
}
}
上述代碼說明：sem.WaitOne(0)這個逾時時間，最好是0，即不等待，否則高并發下會有問題。SemaphoreSlim的異步wait沒試過。如果逾時時間大于0，意味着，高并發下，會有大量的等待，異步等待也是等待。
SemaphoreSlim短時間是自旋，想象一下一瞬間産生大量自旋會怎麼樣？是以最好不等待，如果要等待，那代碼還得再研究研究，經過測試才能用。
6. 注冊攔截器
//攔截器
builder.Services.AddMvc(options =>
{
...省略
options.Filters.Add<RateLimitFilter>();
});
六. 使用jMeter進行壓力測試
測試結果：
- 被限速的接口，滿足限速條件的調用并發量大時，部分使用者成功，部分使用者提示目前查詢的人多請稍後再試。但不影響未滿足限速條件的傳參調用，也不影響其它未限速接口的調用。
- 測試的所有接口、所有查詢參數條件的調用，耗時穩定，大量并發時，不會出現接口耗時幾十秒甚至1分鐘的情況。
七. 同時測試三個接口
測試三個接口，一個是觸發限流的A接口，一個是未觸發限流的A接口，一個是未被限流的B接口。
jMeter測試設定
觸發限流的A接口，并發量設定為200：
未觸發限流的A接口以及未被限流的B接口，并發量設定為1：
測試日志截圖
截圖說明：可以看到被限流接口共1000次調用，隻有大約40次調用是成功的，剩下的傳回請稍後再試。
截圖說明：實際上觸發限流的接口，并發量為8，壓力依然很大，會拖慢自身以及其它接口，當觸發限流的接口請求結束時，其它接口通路速度才正常。
八. 實際情況
- 這種接口計算量大，是難以支援高并發的，需要限流。争取客戶的了解，僅支援少量使用者在同一時間查詢。
- 實際上隻要使用者錯開幾秒通路，接口的耗時就很正常。問題是，如何錯開幾秒呢？當使用者看到"請稍後再試"的提示，關閉提示，重新點選查詢，就可以錯開了。如果一次兩次不行，就多點幾次查詢。