15 个版本
| 0.6.3 | 2024 年 2 月 16 日 |
|---|---|
| 0.6.0 | 2023 年 7 月 12 日 |
| 0.5.1 | 2022 年 11 月 29 日 |
| 0.4.2 | 2022 年 2 月 9 日 |
| 0.1.2 | 2019 年 11 月 17 日 |
#17 in 网络编程
811,579 每月下载量
在 198 个包（73 个直接） 中使用
135KB
2K SLoC
governor - 用于调节数据流的库
该库是对 Rust 程序中速率限制的通用细胞速率算法（GCRA）的实现。
它旨在帮助您的程序了解其应该对外部服务施加多少压力（在一定程度上，也允许您的服务调节其用户对其施加的压力）。在某种程度上，它的工作方式类似于著名的蒸汽控制器，该库就是从其名称中获得的
实现和限制
此包中的速率限制算法使用通用细胞速率算法（GCRA）实现。GCRA 在功能上等同于漏桶，但比大多数漏桶实现具有一些优势
- 不需要后台“滴答”过程来维护桶的状态，
- 它在请求到达时，以纳秒级的连续方式更新其状态，
- 并且它将状态保存在单个
AtomicU64整数中。
此处使用的速率限制状态不会占用太多内存（只有 64 位！）并且通过比较和交换操作线程安全地更新。与使用 Mutex 的 ratelimit_meter 的实现相比，它在多线程上平均快 10 倍。
限制
速度带来了一些代价：每个速率限制器和其状态在创建后 584 年内才有用。如果您想用这个库为 Long Now Foundation 的计算机供电，请与我们联系。
这与 ratelimit_meter 有何关联？
该项目是基于对 ratelimit_futures 的分叉/重命名/延续，基于一些关键洞察和生态系统的进步
- 2018 版本现在既可用又非常有用。
- Futures 和
async/await已稳定。 ratelimit_meter对于其自身的通用性来说太泛了，实现了同一速率限制算法的两个次优变体。
让我们按顺序来探讨这些内容
Rust 2018
这个crate中的代码针对Rust的2018版进行编写。这使得代码变得更加简洁和符合惯用用法。
async/await
在Rust 1.39之前，使用稳定版本的Futures的唯一方法是使用组合子或手动轮询。有一个crate为ratelimit_meter实现了一个速率限制的future，大约80行代码。在这个crate中，使用async/await只需要大约三行代码。
不再需要两个做同样事情的算法
ratelimit_meter提供了“两个”算法类，LeakyBucket和GCRA。它们的行为完全相同（除了GCRA的第一个单元格是免费的错误），迫使每个用户做出一个最终没有任何意义的决定。
这个crate只实现了GCRA算法（不包括“第一个单元格是免费的”错误），并且以比ratelimit_meter更优的方式实现。
这里的返回值大多是具体类型，而大多数东西接受的唯一类型参数是时钟实现，以便在no_std上编译。
那么，为什么创建一个新的crate呢？
有几个原因，但主要是这些：一是我不满意这个名字，我觉得它已经不再很合适了；二是我觉得这样一个根本新的接口会给用户带来负担，而且很难在旧仓库中逐步实现。这些原因可能不是很好，但就是这样。
依赖关系
~2.5–9.5MB
~82K SLoC