浅谈流量限制

关注

原创最新推荐文章于 2026-07-20 12:54:19 发布 511 阅读 AI 写同款· GEO 优化 ›

使用github搭建不限流量的图片床使用github 搭建不限流量的图片床今天突然意识到图展这个国内的图床极不靠谱，国内的这些免费服务不知道什么时候就会关闭，到时候就欲哭无泪了。于是又去找图床，最后还是意识到GitHub最靠谱，还是用GitHub做图床吧。使用GitHub作为图片床步骤相当简单 1. 新建一个 `repository`。 github地址 https://github.com/ 2.将创建好的仓库克隆到... 阅读详情

I/O密集型和CPU密集型

对于IO/Network瓶颈类的程序，其表现是网卡/磁盘IO会先于CPU打满，这种情况即使优化CPU的使用也不能提高整个系统的吞吐量，只能提高磁盘的读写速度，增加内存大小，提升网卡的带宽来提升整体性能。而CPU瓶颈类的程序，则是在存储和网卡未打满之前CPU占用率先到达100%，CPU忙于各种计算任务，IO设备相对则较闲。

无论哪种类型的服务，在资源使用到极限的时候都会导致请求堆积，超时，系统hang死，最终伤害到终端用户。对于分布式的Web服务来说，瓶颈还不一定总在系统内部，也有可能在外部。非计算密集型的系统往往会在关系型数据库环节失守，而这时候Web模块本身还远远未达到瓶颈。

常见的流量限制手段

漏桶

漏桶是指我们有一个一直装满了水的桶，每过固定的一段时间即向外漏一滴水。如果你接到了这滴水，那么你就可以继续服务请求，如果没有接到，那么就需要等待下一滴水

令牌桶

令牌桶则是指匀速向桶中添加令牌，服务请求时需要从桶中获取令牌，令牌的数目可以按照需要消耗的资源进行相应的调整。如果没有令牌，可以选择等待，或者放弃

这两种方法，漏桶流出的速率固定，而令牌桶只要桶中有令牌就可以访问，即令牌桶允许一定程度的并发。令牌桶在桶中没有令牌的情况下会退化成漏桶模型。
在这里插入图片描述

开源github.com/juju/ratelimit提供了几种不同的令牌桶填充方式

默认

func NewBucket(fillInterval time.Duration, capacity int64) *Bucket

fillInterval 指每过多长时间向桶里放一个令牌
capacity是桶的容量，超过桶容量的部分会被直接丢弃
桶初始是满的

批量放令牌

func NewBucketWithRate(rate float64, capacity int64) *Bucket

这个接口每次向桶中放令牌时，是放 quantum 个令牌，而不是一个令牌。会按照提供的比例，每秒钟填充令牌数。例如 capacity 是100，而 rate 是0.1，那么每秒会填充100*0.1=10个令牌

在桶中获取令牌

func (tb *Bucket) Take(count int64) time.Duration {}
func (tb *Bucket) TakeAvailable(count int64) int64 {}
func (tb *Bucket) TakeMaxDuration(count int64, maxWait time.Duration) (time.Duration, bool) {}
func (tb *Bucket) Wait(count int64) {}
func (tb *Bucket) WaitMaxDuration(count int64, maxWait time.Duration) bool {}

原理

从功能上看，令牌桶模型就是对全局计数的加减法操作，使用计数需要我们去加读写锁。在Go语言中，可以通过buffer channel来完成加减令牌的操作：

var tokenBucket = make(chan struct{}, capacity)

每过一段时间向tokenBucket中添加token,如果bucket已经满了，那么直接放弃。这里就是一个生产消费者模型

package main

import (
    "fmt"
    "math/rand"
    "time"
)

var tokenBucket = make(chan struct{}, kCapcity)

const (
    kFillInterval = 1 * time.Millisecond
    kCapcity      = 100
)

func main() {

    fillToken := func() {
        ticker := time.NewTicker(kFillInterval)
        for {
            select {
            case <-ticker.C:
                select {
                case tokenBucket <- struct{}{}:
                default:
                }
                fmt.Println("current token cnt:", len(tokenBucket), time.Now())
            }
        }

    }

    getRandom := func() int {
        seed := rand.Intn(10)
        return seed
    }

    getToken := func() {
        ticker := time.NewTicker(15 * time.Millisecond)
        for {
            select {
            case <-ticker.C:
                num := getRandom()

                for i := 0; i < num; i++ {
                    <-tokenBucket
                }
            }
        }

    }

    go fillToken()
    go getToken()

    time.Sleep(time.Hour)
}

惰性求值

我们来思考一下，令牌桶每隔一段固定的时间向桶中放令牌，如果我们记下上一次放令牌的时间为 t1，和当时的令牌数k1，放令牌的时间间隔为ti，每次向令牌桶中放x个令牌，令牌桶容量为cap。现在如果有人来调用 getToken来取n个令牌，我们将这个时刻记为t2。在t2时刻，令牌桶中理论上应该有多少令牌呢？伪代码如下：

cur = k1 + ((t2 - t1)/ti) * x
cur = cur > cap ? cap : cur

我们用两个时间点的时间差，再结合其它的参数，理论上在取令牌之前就完全可以知道桶里有多少令牌了。那劳心费力地像本小节前面向channel里填充token的操作，理论上是没有必要的。只要在每次 Take 的时候，再对令牌桶中的token数进行简单计算，就可以得到正确的令牌数。在得到正确的令牌数之后，再进行实际的 Take 操作就好，这个 Take 操作只需要对令牌数进行简单的减法即可，记得加锁以保证并发安全。 github.com/juju/ratelimit这个库就是这样做的。

收录于