后端Web框架【免费下载链接】yii2Yii 2: The Fast, Secure and Professional PHP Framework项目地址https://gitcode.com/gh_mirrors/yi/yii2点击查看免费下载Yii 2 内置了一套基于漏桶算法leaky bucket的 API 限流机制用于防止接口被恶意滥用或超频调用。本文以 Yii 2 官方指南俄语版原始文档 与 英文版原文为骨架结合框架源码与单元测试完整讲解RateLimitInterface三个方法的实现、RateLimiter过滤器的自动检查流程、429 响应与X-Rate-Limit-*响应头的配置方法。读完本文你将能在自己的 REST 控制器中开箱即用地配置每用户 10 分钟最多 100 次调用之类的限流策略并理解其底层判定逻辑。为什么需要限流滥用防护与 429 语义公开的 API 一旦上线就可能面临爬虫、暴力破解、批量拉取等滥用行为。限流rate limiting的核心目标是在一个时间窗口内限制每个调用方通常按用户维度的最大请求次数。例如限制每个用户在 10 分钟内最多调用 100 次 API。当用户在窗口期内发出超过限额的请求时服务端应返回 HTTP 状态码429Too Many Requests请求过多。在 Yii 2 中这个 429 异常由专门的异常类 TooManyRequestsHttpException 表示其构造函数将状态码固定为 429见 TooManyRequestsHttpException.php#L22-L33对应 RFC 6585 §4 中关于 429 的规范定义。第一步让 User Identity 实现 RateLimitInterface启用限流的前提是user identity 类必须实现yii\filters\RateLimitInterface。在 Yii 2 中identity 类由yii\web\User::identityClass配置指定通常对应你的User模型ActiveRecord。该接口定义在 framework/filters/RateLimitInterface.php只要求实现三个方法方法签名职责getRateLimit()getRateLimit($request, $action)返回最大允许请求数与时间窗口大小例如[100, 600]表示600 秒内最多 100 次调用loadAllowance()loadAllowance($request, $action)从持久化存储中加载剩余允许请求数与上次检查时的 UNIX 时间戳saveAllowance()saveAllowance($request, $action, $allowance, $timestamp)将剩余允许请求数与当前 UNIX 时间戳保存回持久化存储从接口的 PHPDoc 可以看到RateLimitInterface.php#L21-L46三个方法都会收到当前Request对象和即将执行的Action这意味着你完全可以根据请求路径、Action 名称实现差异化限流策略。存储方案数据库两列 or 缓存/NoSQL官方文档建议在 user 表中增加两个字段分别记录剩余配额allowance和上次检查时间UNIX 时间戳。loadAllowance()与saveAllowance()就是围绕这两个字段的读写逻辑。为进一步提升性能减少数据库写入也可以把这两条信息存入缓存如yii\caching\Cache或 NoSQL 存储中——因为每次请求都会触发一次读取和一次写入高频接口下数据库压力不容忽视。User 模型的标准实现示例以下示例完整引自官方文档见 docs/guide/rest-rate-limiting.md#L23-L40 与 docs/guide-ru/rest-rate-limiting.md#L25-L42public function getRateLimit($request, $action) { return [$this-rateLimit, 1]; // $rateLimit 次请求 / 每秒 } public function loadAllowance($request, $action) { return [$this-allowance, $this-allowance_updated_at]; } public function saveAllowance($request, $action, $allowance, $timestamp) { $this-allowance $allowance; $this-allowance_updated_at $timestamp; $this-save(); }其中rateLimit、allowance、allowance_updated_at对应 user 表新增的三个列前者是限流上限可在每个用户上配置不同值后两者用于持久化配额状态。示例中窗口大小取1秒若希望每分钟 60 次可改为[60, 60]。第二步RateLimiter 如何自动执行检查一旦 identity 类实现了RateLimitInterfaceYii 就会通过yii\filters\RateLimiter自动进行限流检查。该过滤器在 framework/rest/Controller.php#L54-L75 中作为yii\rest\Controller的默认行为behavior挂载public function behaviors() { return [ contentNegotiator [...], verbFilter [...], authenticator [...], rateLimiter [ class RateLimiter::className(), ], ]; }也就是说只要你的 REST 控制器继承自yii\rest\Controller或其子类yii\rest\ActiveController限流检查就已默认启用无需额外注册。REST 请求处理周期中限流位于第 4 步内容协商 → 请求方法校验 → 用户认证 →限流→ 响应格式化见 Controller.php#L20-L29。beforeAction检查的触发时机与三条分支RateLimiter继承自ActionFilter其检查逻辑在beforeAction()中执行framework/filters/RateLimiter.php#L97-L117若未显式设置user属性则取Yii::$app-getUser()-getIdentity(false)false表示不强制登录避免触发登录流程若user是闭包Closure则调用它动态获取 identity自 2.0.38 起支持适用于不使用标准Yii::$app-user组件的场景例如多用户组件Yii::$app-apiUser只有当user是RateLimitInterface实例时才真正执行检查否则仅记录一条 info 日志后跳过不影响请求继续执行。这一点在 tests/framework/filters/RateLimiterTest.php 中有对应的三条测试用例testBeforeActionUserInstanceOfRateLimitInterface实现接口则检查、testBeforeActionUserNotInstanceOfRateLimitInterface未实现则跳过、testBeforeActionEmptyUser未登录则跳过见 RateLimiterTest.php#L68-L105。checkRateLimit漏桶算法的具体计算核心判定逻辑在checkRateLimit()framework/filters/RateLimiter.php#L127-L147list($limit, $window) $user-getRateLimit($request, $action); list($allowance, $timestamp) $user-loadAllowance($request, $action); $current time(); // 按时间流逝“恢复”配额距上次检查经过的时间 / 窗口 * 上限 $allowance (int) (($current - $timestamp) * $limit / $window); if ($allowance $limit) { $allowance $limit; // 上限封顶 } if ($allowance 1) { $user-saveAllowance($request, $action, 0, $current); $this-addRateLimitHeaders($response, $limit, 0, $window); throw new TooManyRequestsHttpException($this-errorMessage); } $user-saveAllowance($request, $action, $allowance - 1, $current); $this-addRateLimitHeaders($response, $limit, $allowance - 1, (int) (($limit - $allowance 1) * $window / $limit));算法要点配额随时间线性恢复上次检查后每经过一个窗口周期的 1/limit时间就恢复 1 次请求配额(当前时间 - 上次时间戳) * limit / window恢复值封顶为limit配额不足则拒绝恢复后若allowance 1则保存配额 0 并抛出TooManyRequestsHttpException消息默认为Rate limit exceeded.可通过$errorMessage属性自定义见 RateLimiter.php#L59正常请求扣减 1 次配额并保存新的时间戳。测试用例testCheckRateLimitTooManyRequests验证了配额不足时抛出yii\web\TooManyRequestsHttpExceptionRateLimiterTest.php#L107-L117。第三步响应头 X-Rate-Limit-* 与关闭方式启用限流后默认情况下每个响应都会携带以下三个 HTTP 头向客户端通报当前配额状态响应头含义X-Rate-Limit-Limit时间窗口内允许的最大请求数X-Rate-Limit-Remaining当前窗口内剩余可用的请求数X-Rate-Limit-Reset距离恢复满额配额还需等待的秒数这三个头的写入逻辑集中在addRateLimitHeaders()framework/filters/RateLimiter.php#L156-L164且受enableRateLimitHeaders属性控制默认true。测试 RateLimiterTest.php#L135-L153 分别验证了开启时响应头数量为 3、关闭时为 0。如果你不想暴露这些信息例如内部服务间调用可以在 REST 控制器中覆写behaviors()关闭它——这是官方文档给出的标准写法见 docs/guide/rest-rate-limiting.md#L49-L56public function behaviors() { $behaviors parent::behaviors(); $behaviors[rateLimiter][enableRateLimitHeaders] false; return $behaviors; }由于rateLimiter行为是parent::behaviors()的一部分通过数组下标修改其配置即可其余行为内容协商、认证、动词过滤保持不变。进阶RateLimiter 的其他可配置属性除了enableRateLimitHeaders与errorMessageRateLimiter 还暴露以下属性供你在behaviors()中覆盖user显式指定实现RateLimitInterface的 identity 对象自 2.0.38 起支持传入闭包function() { return Yii::$app-apiUser-identity; }便于在未使用标准Yii::$app-user组件时动态获取身份对应 issue #18236测试见 RateLimiterTest.php#L158-L173request/response自定义请求与响应对象默认取应用组件request与responseinit()中自动注入见 RateLimiter.php#L84-L92测试见testInitFilledRequest/testInitNotFilledRequest等。实践小结三步接入限流在 user 表新增rate_limit或复用统一上限、allowance、allowance_updated_at字段在Useridentity 类中实现getRateLimit()、loadAllowance()、saveAllowance()三个方法读写对应字段追求性能时可改用缓存/NoSQL控制器继承yii\rest\Controller即自动获得限流能力如需自定义窗口、关闭响应头或更换用户获取方式在behaviors()中调整rateLimiter配置即可。限流检查发生在认证之后、响应格式化之前且仅对实现了RateLimitInterface且已登录的用户生效匿名用户与未实现接口的 identity 会被跳过并记录日志。整个机制基于漏桶算法实现代码路径清晰配合 RateLimiterTest.php 中的测试用例你可以快速验证不同窗口、不同配额下的 429 行为与响应头数值。延伸阅读REST 控制器完整说明含请求处理周期REST 认证机制限流前置步骤错误处理与异常响应429 异常如何被格式化输出限流接口与过滤器源码RateLimitInterface.php、RateLimiter.php、TooManyRequestsHttpException.php赞分享后端Web框架【免费下载链接】yii2Yii 2: The Fast, Secure and Professional PHP Framework项目地址https://gitcode.com/gh_mirrors/yi/yii2点击查看免费下载相关推荐Yii 2 REST 接口限流Rate Limiting实战指南基于 RateLimiter 与 RateLimitInterface 的 API 防滥用方案Yii 2 REST 接口限流Rate Limiting实战指南基于 RateLimiter 与 RateLimitInterface 的 API 防滥用后端Web框架Yii 2 REST API 限流Rate Limiting实战指南基于 RateLimiter 过滤器与 RateLimitInterface 的请求频率控制Yii 2 REST API 限流Rate Limiting实战指南基于 RateLimiter 过滤器与 RateLimitInterface 的请求频后端Web框架Yii2 REST API 限流Rate Limiting实战指南从 RateLimitInterface 到 RateLimiter 过滤器Yii2 REST API 限流Rate Limiting实战指南从 RateLimitInterface 到 RateLimiter 过滤器 Yii2后端Web框架创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Yii 2 REST API 限流（Rate Limiting）完整实战指南：RateLimitInterface 与 RateLimiter 深度解析
后端Web框架【免费下载链接】yii2Yii 2: The Fast, Secure and Professional PHP Framework项目地址https://gitcode.com/gh_mirrors/yi/yii2点击查看免费下载Yii 2 内置了一套基于漏桶算法leaky bucket的 API 限流机制用于防止接口被恶意滥用或超频调用。本文以 Yii 2 官方指南俄语版原始文档 与 英文版原文为骨架结合框架源码与单元测试完整讲解RateLimitInterface三个方法的实现、RateLimiter过滤器的自动检查流程、429 响应与X-Rate-Limit-*响应头的配置方法。读完本文你将能在自己的 REST 控制器中开箱即用地配置每用户 10 分钟最多 100 次调用之类的限流策略并理解其底层判定逻辑。为什么需要限流滥用防护与 429 语义公开的 API 一旦上线就可能面临爬虫、暴力破解、批量拉取等滥用行为。限流rate limiting的核心目标是在一个时间窗口内限制每个调用方通常按用户维度的最大请求次数。例如限制每个用户在 10 分钟内最多调用 100 次 API。当用户在窗口期内发出超过限额的请求时服务端应返回 HTTP 状态码429Too Many Requests请求过多。在 Yii 2 中这个 429 异常由专门的异常类 TooManyRequestsHttpException 表示其构造函数将状态码固定为 429见 TooManyRequestsHttpException.php#L22-L33对应 RFC 6585 §4 中关于 429 的规范定义。第一步让 User Identity 实现 RateLimitInterface启用限流的前提是user identity 类必须实现yii\filters\RateLimitInterface。在 Yii 2 中identity 类由yii\web\User::identityClass配置指定通常对应你的User模型ActiveRecord。该接口定义在 framework/filters/RateLimitInterface.php只要求实现三个方法方法签名职责getRateLimit()getRateLimit($request, $action)返回最大允许请求数与时间窗口大小例如[100, 600]表示600 秒内最多 100 次调用loadAllowance()loadAllowance($request, $action)从持久化存储中加载剩余允许请求数与上次检查时的 UNIX 时间戳saveAllowance()saveAllowance($request, $action, $allowance, $timestamp)将剩余允许请求数与当前 UNIX 时间戳保存回持久化存储从接口的 PHPDoc 可以看到RateLimitInterface.php#L21-L46三个方法都会收到当前Request对象和即将执行的Action这意味着你完全可以根据请求路径、Action 名称实现差异化限流策略。存储方案数据库两列 or 缓存/NoSQL官方文档建议在 user 表中增加两个字段分别记录剩余配额allowance和上次检查时间UNIX 时间戳。loadAllowance()与saveAllowance()就是围绕这两个字段的读写逻辑。为进一步提升性能减少数据库写入也可以把这两条信息存入缓存如yii\caching\Cache或 NoSQL 存储中——因为每次请求都会触发一次读取和一次写入高频接口下数据库压力不容忽视。User 模型的标准实现示例以下示例完整引自官方文档见 docs/guide/rest-rate-limiting.md#L23-L40 与 docs/guide-ru/rest-rate-limiting.md#L25-L42public function getRateLimit($request, $action) { return [$this-rateLimit, 1]; // $rateLimit 次请求 / 每秒 } public function loadAllowance($request, $action) { return [$this-allowance, $this-allowance_updated_at]; } public function saveAllowance($request, $action, $allowance, $timestamp) { $this-allowance $allowance; $this-allowance_updated_at $timestamp; $this-save(); }其中rateLimit、allowance、allowance_updated_at对应 user 表新增的三个列前者是限流上限可在每个用户上配置不同值后两者用于持久化配额状态。示例中窗口大小取1秒若希望每分钟 60 次可改为[60, 60]。第二步RateLimiter 如何自动执行检查一旦 identity 类实现了RateLimitInterfaceYii 就会通过yii\filters\RateLimiter自动进行限流检查。该过滤器在 framework/rest/Controller.php#L54-L75 中作为yii\rest\Controller的默认行为behavior挂载public function behaviors() { return [ contentNegotiator [...], verbFilter [...], authenticator [...], rateLimiter [ class RateLimiter::className(), ], ]; }也就是说只要你的 REST 控制器继承自yii\rest\Controller或其子类yii\rest\ActiveController限流检查就已默认启用无需额外注册。REST 请求处理周期中限流位于第 4 步内容协商 → 请求方法校验 → 用户认证 →限流→ 响应格式化见 Controller.php#L20-L29。beforeAction检查的触发时机与三条分支RateLimiter继承自ActionFilter其检查逻辑在beforeAction()中执行framework/filters/RateLimiter.php#L97-L117若未显式设置user属性则取Yii::$app-getUser()-getIdentity(false)false表示不强制登录避免触发登录流程若user是闭包Closure则调用它动态获取 identity自 2.0.38 起支持适用于不使用标准Yii::$app-user组件的场景例如多用户组件Yii::$app-apiUser只有当user是RateLimitInterface实例时才真正执行检查否则仅记录一条 info 日志后跳过不影响请求继续执行。这一点在 tests/framework/filters/RateLimiterTest.php 中有对应的三条测试用例testBeforeActionUserInstanceOfRateLimitInterface实现接口则检查、testBeforeActionUserNotInstanceOfRateLimitInterface未实现则跳过、testBeforeActionEmptyUser未登录则跳过见 RateLimiterTest.php#L68-L105。checkRateLimit漏桶算法的具体计算核心判定逻辑在checkRateLimit()framework/filters/RateLimiter.php#L127-L147list($limit, $window) $user-getRateLimit($request, $action); list($allowance, $timestamp) $user-loadAllowance($request, $action); $current time(); // 按时间流逝“恢复”配额距上次检查经过的时间 / 窗口 * 上限 $allowance (int) (($current - $timestamp) * $limit / $window); if ($allowance $limit) { $allowance $limit; // 上限封顶 } if ($allowance 1) { $user-saveAllowance($request, $action, 0, $current); $this-addRateLimitHeaders($response, $limit, 0, $window); throw new TooManyRequestsHttpException($this-errorMessage); } $user-saveAllowance($request, $action, $allowance - 1, $current); $this-addRateLimitHeaders($response, $limit, $allowance - 1, (int) (($limit - $allowance 1) * $window / $limit));算法要点配额随时间线性恢复上次检查后每经过一个窗口周期的 1/limit时间就恢复 1 次请求配额(当前时间 - 上次时间戳) * limit / window恢复值封顶为limit配额不足则拒绝恢复后若allowance 1则保存配额 0 并抛出TooManyRequestsHttpException消息默认为Rate limit exceeded.可通过$errorMessage属性自定义见 RateLimiter.php#L59正常请求扣减 1 次配额并保存新的时间戳。测试用例testCheckRateLimitTooManyRequests验证了配额不足时抛出yii\web\TooManyRequestsHttpExceptionRateLimiterTest.php#L107-L117。第三步响应头 X-Rate-Limit-* 与关闭方式启用限流后默认情况下每个响应都会携带以下三个 HTTP 头向客户端通报当前配额状态响应头含义X-Rate-Limit-Limit时间窗口内允许的最大请求数X-Rate-Limit-Remaining当前窗口内剩余可用的请求数X-Rate-Limit-Reset距离恢复满额配额还需等待的秒数这三个头的写入逻辑集中在addRateLimitHeaders()framework/filters/RateLimiter.php#L156-L164且受enableRateLimitHeaders属性控制默认true。测试 RateLimiterTest.php#L135-L153 分别验证了开启时响应头数量为 3、关闭时为 0。如果你不想暴露这些信息例如内部服务间调用可以在 REST 控制器中覆写behaviors()关闭它——这是官方文档给出的标准写法见 docs/guide/rest-rate-limiting.md#L49-L56public function behaviors() { $behaviors parent::behaviors(); $behaviors[rateLimiter][enableRateLimitHeaders] false; return $behaviors; }由于rateLimiter行为是parent::behaviors()的一部分通过数组下标修改其配置即可其余行为内容协商、认证、动词过滤保持不变。进阶RateLimiter 的其他可配置属性除了enableRateLimitHeaders与errorMessageRateLimiter 还暴露以下属性供你在behaviors()中覆盖user显式指定实现RateLimitInterface的 identity 对象自 2.0.38 起支持传入闭包function() { return Yii::$app-apiUser-identity; }便于在未使用标准Yii::$app-user组件时动态获取身份对应 issue #18236测试见 RateLimiterTest.php#L158-L173request/response自定义请求与响应对象默认取应用组件request与responseinit()中自动注入见 RateLimiter.php#L84-L92测试见testInitFilledRequest/testInitNotFilledRequest等。实践小结三步接入限流在 user 表新增rate_limit或复用统一上限、allowance、allowance_updated_at字段在Useridentity 类中实现getRateLimit()、loadAllowance()、saveAllowance()三个方法读写对应字段追求性能时可改用缓存/NoSQL控制器继承yii\rest\Controller即自动获得限流能力如需自定义窗口、关闭响应头或更换用户获取方式在behaviors()中调整rateLimiter配置即可。限流检查发生在认证之后、响应格式化之前且仅对实现了RateLimitInterface且已登录的用户生效匿名用户与未实现接口的 identity 会被跳过并记录日志。整个机制基于漏桶算法实现代码路径清晰配合 RateLimiterTest.php 中的测试用例你可以快速验证不同窗口、不同配额下的 429 行为与响应头数值。延伸阅读REST 控制器完整说明含请求处理周期REST 认证机制限流前置步骤错误处理与异常响应429 异常如何被格式化输出限流接口与过滤器源码RateLimitInterface.php、RateLimiter.php、TooManyRequestsHttpException.php赞分享后端Web框架【免费下载链接】yii2Yii 2: The Fast, Secure and Professional PHP Framework项目地址https://gitcode.com/gh_mirrors/yi/yii2点击查看免费下载相关推荐Yii 2 REST 接口限流Rate Limiting实战指南基于 RateLimiter 与 RateLimitInterface 的 API 防滥用方案Yii 2 REST 接口限流Rate Limiting实战指南基于 RateLimiter 与 RateLimitInterface 的 API 防滥用后端Web框架Yii 2 REST API 限流Rate Limiting实战指南基于 RateLimiter 过滤器与 RateLimitInterface 的请求频率控制Yii 2 REST API 限流Rate Limiting实战指南基于 RateLimiter 过滤器与 RateLimitInterface 的请求频后端Web框架Yii2 REST API 限流Rate Limiting实战指南从 RateLimitInterface 到 RateLimiter 过滤器Yii2 REST API 限流Rate Limiting实战指南从 RateLimitInterface 到 RateLimiter 过滤器 Yii2后端Web框架创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考