前些日子写的限制请求次数，结果用的时候发现可以更简单实现。
需求：抓数据的网站限定1秒只能有10次请求
由于发起并发请求几乎是0耗时的，所以可以选择同时发完所有的请求，然后等到下一个周期。这样控制周期内请求次数只需要一个ticker就能搞定：发完请求就阻塞一个周期；
而控制同时最大并发只需要一个channel用来计数。计数不能用互斥锁计数器，因为互斥锁不能实现阻塞
package main
import (
"fmt"
"sync"
"time"
)
var (
working chan int //goroutine计数器 用于限制最大并发数
wg sync.WaitGroup
)
func main() {
jobList := []int64{1, 2, 3, 4, 5, 6, 7, 8, 9, 10} //要工作的任务清单
//每秒3个请求 最大同时4个请求
duration := time.Second
concurrency := 3
concurrencyMax := 4
ticker := time.NewTicker(duration)
working = make(chan int, concurrencyMax)
//通过限定1个周期派发3个任务来实现限制请求次数
k := 0 //用于控制周期内发送次数
for c, job := range jobList {
working <- c //计数器+1 可能会发生阻塞
wg.Add(1)
go work(job)
k++
if k == concurrency {
<-ticker.C //等待一个周期 可能会白等
k = 0
}
}
wg.Wait()
}
func work(j int64) {
defer wg.Done()
fmt.Println("doing work#", j)
<-time.After(5 * time.Second) //假设5秒完成
//工作完成后计数器减1
<-working
}
上面这个相对就省事很多了。
但是，如果计数器+1的时候发生阻塞，那么下一个等待周期可能是白等的。
同样的原因，如果发起请求的操作也有耗时，很可能这一批请求发完就已经进入下一个周期，于是不等就有超发的风险，等待有白等的风险。
因此上面的方法仅限于发起并发请求几乎0耗时的操作。
如果要避免白等，就还需要一个精确的周期计数器。两种方案：
- 类似令牌池，维持一个channel来发放令牌，周期性刷新。就像这里令牌池的实现
- 维持一个计数器，周期性重置
无论哪种方案都需要加锁。
第一种方案加锁是为了避免在发放令牌的时候遭遇通道关闭（会引发panic）。
第二种在+1和-1甚至比对的时候都要加锁。
