常见qps限制方式

本文介绍了在不同场景下如何控制对下游服务的访问QPS,包括单进程/单携程、单机和多机器任务的情况。对于单进程/单携程,可以通过估算执行时间调整QPS;单机情况下,使用队列和计数器实现,并注意并发控制;多机器任务则需要借助外部组件如Redis进行协调控制。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

生产环境经常会跑一些离线任务,或者有一些异步任务在问题恢复后积压需要放水,此时我们需要控制对下游的访问qps,避免打挂下游,有多种方式去实现。

当你是一个单进程/单携程

通常是一些小的回扫任务,多用于处理临时任务。
因为是单个进程/携程,简单的话可以首先time.Sleep()较长一段时间,同时打一下执行时间的大概日志,然后根据实际调用下游的时间,估出一个值调整下游的qps。如果下游超时不稳定有尾请求,也可以手工设置一个超时,避免qps达不到预期

func Process() {
    while True {
    	startTime = time.Now.Unix()
		go func() {
			ch <-handler()
		}()
		select {
		case  <-ch:
			log.Printf("time used: %v", time.Now.Unix() - startTime)
			time.Sleep(xxx)
		// 增加一个超时避免进程阻死不执行
		case <-time.After(time.Second * x):
		   log.Printf("time too long, can't execute")
		   continue
	}	
}

/*
实际执行的函数
func handler() {}
*/

稍微复杂可控的话, 可以像下文单机一样加一个counter来判断qps量即可,而且因为是单进程/携程,不用考虑竞争问题,不用加锁

当你是一个单机

我们有多个进程/携程在处理,我们需要在内存中维持一个queue和一个counter。进来的任务进queue,携程实时地根据counter来判定qps(counter的处理需要加锁,避免并发任务导致锁不准)

type Limiter struct {
	Lock     sync.Mutex
	Counter int
}

func Init() *Limiter {
	
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值