从头开始的 Golang WebServer：我应该如何实现速率限制？

一分耕耘，一分收获！既然打开了这篇文章《从头开始的 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学习网公众号了解相关技术文章。