前些日子写的限制请求次数，结果用的时候发现可以更简单实现。

需求：抓数据的网站限定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耗时的操作。

如果要避免白等，就还需要一个精确的周期计数器。两种方案：

1. 类似令牌池，维持一个channel来发放令牌，周期性刷新。就像这里令牌池的实现
2. 维持一个计数器，周期性重置

无论哪种方案都需要加锁。
第一种方案加锁是为了避免在发放令牌的时候遭遇通道关闭（会引发panic）。
第二种在+1和-1甚至比对的时候都要加锁。