从头开始的 Golang WebServer：我应该如何实现速率限制？
来源：stackoverflow
时间：2024-04-26 14:09:34 427浏览 收藏
一分耕耘，一分收获！既然打开了这篇文章《从头开始的 Golang WebServer：我应该如何实现速率限制？》，就坚持看下去吧！文中内容包含等等知识点...希望你能在阅读本文后，能真真实实学到知识或者帮你解决心中的疑惑，也欢迎大佬或者新人朋友们多留言评论，多给建议！谢谢！
我正在使用 golang 开发一个网络服务器，以将我所学到的有关该语言及其并发模型的知识付诸实践。
我有一个简单的基于原始套接字的网络服务器，它使用示例 html 响应来回答基本路径。在内部，web 服务器侦听端口 8000，并循环接受传入连接，将它们转发到最大容量为 1000 个待处理连接的缓冲通道。同时，由 20 个工作线程组成的池处理缓冲通道中的请求并写回响应。
现在，最初我的网络服务器主要服务方法是这样的：
func (h httpserver) serve(host, path string) {
connection, err := net.listen("tcp", "0.0.0.0:8000")
if err != nil { ... }
for true {
clientconnection, err := connection.accept()
if err != nil { ... }
select {
case h.connectionsqueue <- clientconnection:
default:
errors.toomanyrequestshandler{}.handle(clientconnection)
}
}
}
网络服务器是这样的结构：
var maxworkers = 20
var maxpendingconnections = 1000
type httpserver struct {
connectionsqueue chan net.conn
}
func buildhttpserver() httpserver {
routedispatcher := routing.makeregisterroute()
routedispatcher.registerroute("/", ui.routeuiindex{})
server := httpserver{
connectionsqueue: make(chan net.conn, maxpendingconnections),
}
for i := 0; i < maxworkers; i++ {
go handler.spawnhandler(server.connectionsqueue, routedispatcher)
}
return server
}
实际上，这已经实现了接受所有传入连接直到达到 maxpendingconnections/通道已满的行为。如果工作人员不堪重负，429 too many requests 开始通过 toomanyrequestshandler 返回给客户端，该处理程序会将该响应写回。
但是，如果我想为此网络服务器中处理请求的速率设置绝对上限怎么办？这里的目标是保证可预测的性能并避免性能下降。因此，我将我的服务功能更改为：
func (h HttpServer) Serve(host, path string) {
acceptRequestRateTicker := time.NewTicker(200 * time.Microseconds)
connection, err := net.Listen("tcp", "0.0.0.0:8000")
if err != nil { ... }
for true {
select {
case <-acceptRequestRateTicker.C:
clientConnection, err := connection.Accept()
if err != nil { ... }
select {
case h.connectionsQueue <- clientConnection:
default:
errors.TooManyRequestsHandler{}.Handle(clientConnection)
}
}
}
这里的要点是，主 goroutine 不接受高于 5000 req/s 的请求速率，每 200 微秒接受一次连接，之后客户端在获取与服务器的连接时将遇到请求超时。这是保证可预测的服务性能和期望的好策略吗？
正确答案
所以，过了一段时间，我已经实现了我想要的目标，简单的解决方案是实现基于令牌的速率限制器。
基本思想很简单，你有一个深度为 n 的包含令牌的桶。每次需要处理请求时，您都会检索可用的令牌之一（如果有），从而将可用令牌的数量减少 1。
如果没有可用的，您有两种选择，要么立即响应 429 too many requests，要么仅在令牌可用时将传入请求排队进行处理。
这两种选择之间存在实施速率限制器的不同原因。 a) 您可以使用它来控制应用程序在稳定状态下运行的性能范围。 b) 由于客户端每秒可以访问您的 api 的请求数有合同，您已将其设置到位。
不排队请求并立即回答 429 too many requests 适合执行 b)。相反，对于 a) 来说，客户端可能更喜欢将其请求延迟到服务器，而不是完全没有收到任何响应，因此，在应用程序的内存限制所给定的某个点之前，对速率受限的请求进行排队是正确的选择。
无论如何，令牌算法的技巧在于控制令牌再次可用的速率。如果我们想要实现 300 req/s 的速率限制，我们希望 goroutine 每 3.33 ms（1000 ms / 300 req/s）在非满桶上补充一个令牌。也就是说，无论传入请求如何消耗存储桶，都会以固定间隔（每秒 300 次或每 3.33 毫秒）进行补充。存储桶大小的目的是允许正确接受突发请求，同时仍然强制执行总体速率。
我通过以下逻辑实现了这一目标：
http_server.go：
const (
max_workers int = 1
)
type httpserver struct {
ratelimiter *limiter.limiter
}
func buildhttpserver() httpserver {
server := httpserver{
ratelimiter: limiter.makeratelimiter(),
}
for i := 0; i < max_workers; i++ {
go handler.spawnhandler(server.ratelimiter.acceptedconnectionsqueue)
}
return server
}
func (h httpserver) serve(host, path string) {
connection, err := net.listen("tcp", "0.0.0.0:8000")
if err != nil { /* ... */ }
for true {
clientconnection, err := connection.accept()
if err != nil { /* ... */ }
if proceed, err := h.ratelimiter.proceedorbufferconnection(clientconnection); err != nil {
/* err != nil means connection was rate limited
* but could not be buffered
*/
consumer.consumer{}.consumeandrespond(clientconnection, responses.toomanyrequestsresponse{})
continue
} else if !proceed {
/* proceed equals false means connection
* was rate limited
*/
continue
}
select {
case h.ratelimiter.acceptedconnectionsqueue <- clientconnection:
default:
/* reaching this case means our workers
* are not able to keep up with the rate at
* which we accept connections. you should detect
* this scenario and increase
* the number of workers or the
* accepted connections buffer size
*/
consumer.consumer{}.consumeandrespond(clientconnection, responses.toomanyrequestsresponse{})
}
}
}
rate_limiter.go：
const (
tokens_depth_size int = 1
accepted_connections_buffer_size int = 20
pending_connections_buffer_size int = 2000
)
type limiter struct {
tokensbucketdepth int
pendingconnectionsqueue chan net.conn
acceptedconnectionsqueue chan net.conn
tokensmutex sync.mutex
}
func makeratelimiter() *limiter {
limiter := limiter{
tokensbucketdepth: tokens_depth_size,
pendingconnectionsqueue: make(chan net.conn, pending_connections_buffer_size),
acceptedconnectionsqueue: make(chan net.conn, accepted_connections_buffer_size),
tokensmutex: sync.mutex{},
}
go refill(&limiter)
return &limiter
}
func (l *limiter) proceedorbufferconnection(conn net.conn) (bool, error) {
l.tokensmutex.lock()
if l.tokensbucketdepth > 0 {
// we have a token, proceed
l.tokensbucketdepth--
l.tokensmutex.unlock()
return true, nil
}
l.tokensmutex.unlock()
/* we did not have a token, try to queue
* the connection in the pending buffer
*/
select {
case l.pendingconnectionsqueue <- conn:
default:
/* our pending buffer is full, there's nothing
* we can do here, we should return too many requests
*/
return false, errors.new("buffer is full, message should be discarded")
}
return false, nil
}
func refill(l *limiter) {
ticker := time.newticker(3333 * time.microsecond)
for {
select {
case <-ticker.c:
l.tokensmutex.lock()
if l.tokensbucketdepth < tokens_depth_size {
select {
case conn := <-l.pendingconnectionsqueue:
select {
case l.acceptedconnectionsqueue <- conn:
default:
select {
case l.pendingconnectionsqueue <- conn:
l.tokensbucketdepth++
default:
consumer.consumer{}.consumeandrespond(conn, responses.toomanyrequestsresponse{})
}
}
default:
l.tokensbucketdepth++
}
}
l.tokensmutex.unlock()
default:
}
}
}
请注意在此场景中限制器如何以单个标记开始。这意味着我们从第一个令牌开始就强制执行速率，并在突发情况下立即排队。您可能想尝试一下这个属性。
运行这个，以下是嘿的结果：
嘿 -n 2000 -c 4 -q 1000 -m get http://localhost:8000/ -t 1
这会发送 2000 个请求，以 1000 个请求/秒的速率分配给 4 个工作人员。
相反，结果是：
summary: total: 6.6374 secs slowest: 0.0376 secs fastest: 0.0001 secs average: 0.0132 secs requests/sec: 301.3217 total data: 58000 bytes size/request: 29 bytes response time histogram: 0.000 [1] | 0.004 [23] | 0.008 [5] | 0.011 [9] | 0.015 [1941] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 0.019 [7] | 0.023 [9] | 0.026 [2] | 0.030 [1] | 0.034 [0] | 0.038 [2] | latency distribution: 10% in 0.0131 secs 25% in 0.0132 secs 50% in 0.0133 secs 75% in 0.0134 secs 90% in 0.0136 secs 95% in 0.0136 secs 99% in 0.0176 secs details (average, fastest, slowest): dns+dialup: 0.0004 secs, 0.0001 secs, 0.0376 secs dns-lookup: 0.0002 secs, 0.0000 secs, 0.0071 secs req write: 0.0000 secs, 0.0000 secs, 0.0004 secs resp wait: 0.0128 secs, 0.0001 secs, 0.0375 secs resp read: 0.0000 secs, 0.0000 secs, 0.0007 secs status code distribution: [200] 2000 responses
正如您所看到的，我们因此实现了 300 个请求/秒的请求处理上限。
但是如果现在我们将填充窗口减半为每 1.667 毫秒，我们会得到：
Summary: Total: 3.3454 secs Slowest: 0.0196 secs Fastest: 0.0015 secs Average: 0.0067 secs Requests/sec: 597.8337
将我们的费率提高两倍。
完整存储库的链接：https://github.com/miguelpais /go-http-server-and-cli
希望这有帮助，请批评我的解决方案。
文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《从头开始的 Golang WebServer：我应该如何实现速率限制？》文章吧，也可关注golang学习网公众号了解相关技术文章。
-
502 收藏
-
502 收藏
-
501 收藏
-
501 收藏
-
501 收藏
-
139 收藏
-
204 收藏
-
325 收藏
-
477 收藏
-
486 收藏
-
439 收藏
-
357 收藏
-
352 收藏
-
101 收藏
-
440 收藏
-
212 收藏
-
143 收藏
-
- 前端进阶之JavaScript设计模式
- 设计模式是开发人员在软件开发过程中面临一般问题时的解决方案，代表了最佳的实践。本课程的主打内容包括JS常见设计模式以及具体应用场景，打造一站式知识长龙服务，适合有JS基础的同学学习。
- 立即学习 542次学习
-
- GO语言核心编程课程
- 本课程采用真实案例，全面具体可落地，从理论到实践，一步一步将GO核心编程技术、编程思想、底层实现融会贯通，使学习者贴近时代脉搏，做IT互联网时代的弄潮儿。
- 立即学习 508次学习
-
- 简单聊聊mysql8与网络通信
- 如有问题加微信：Le-studyg；在课程中，我们将首先介绍MySQL8的新特性，包括性能优化、安全增强、新数据类型等，帮助学生快速熟悉MySQL8的最新功能。接着，我们将深入解析MySQL的网络通信机制，包括协议、连接管理、数据传输等，让
- 立即学习 497次学习
-
- JavaScript正则表达式基础与实战
- 在任何一门编程语言中,正则表达式,都是一项重要的知识,它提供了高效的字符串匹配与捕获机制,可以极大的简化程序设计。
- 立即学习 487次学习
-
- 从零制作响应式网站—Grid布局
- 本系列教程将展示从零制作一个假想的网络科技公司官网，分为导航，轮播，关于我们，成功案例，服务流程，团队介绍，数据部分，公司动态，底部信息等内容区块。网站整体采用CSSGrid布局，支持响应式，有流畅过渡和展现动画。
- 立即学习 484次学习