-
Notifications
You must be signed in to change notification settings - Fork 16
蹲饼器策略
洛梧藤 edited this page Sep 10, 2022
·
2 revisions
大概分析一下蹲饼策略
- 数据源分组,默认自己独立一组,可设置分组ID,ID相同的共同一组,设总分组数量为G
- 设平台限制频率(硬编码默认值,可接收Dun-Cookies-Info.json的配置下发)为C
- 设用户设置的蹲饼频率为M,用户启用的该平台的数据源数量为N
- 设X=M/C,Y=M/N,Z=M/G
- X的含义是指定蹲饼频率下可接受的数据源数量
- Y的含义是在所有数据源满足用户设置的蹲饼频率的情况下实际平均请求间隔
- Z的含义是在所有分组满足用户设置的蹲饼频率的情况下实际平均请求间隔
- 可以得到如下等式M=XC=YN=ZG
-
第一种情况,由4可知,当X>=N时,必然满足Y>=C
- 所以当X>=N时,能够同时满足用户的蹲饼频率、平台限制,因此所有数据源都按照用户设置的频率蹲饼,结束策略
-
第二种情况,由4可知,当G<=X<N时,必然满足Z>=C
- 所以当G<=X<N时,设原本每个分组可用的蹲饼请求为该分组的数据源数量
- 然后轮流减掉每个分组可用的蹲饼请求(最小为1)
- 重复上一条直至 X>=每个分组可用的数据源请求之和
- 设置每个分组的蹲饼频率为M。由于Z>=C,所以M>=CG,所以完成上一条的重复后整体满足平台限制。同时重要饼满足用户设置的频率(因为对应分组只有他一个),而共享分组的数据源相应降低频率,结束策略
-
第三种情况,当X<G时,所有分组的平均蹲饼频率必然无法满足用户设置的频率
- 此时每个分组的蹲饼频率都强制设为B=CG,且一定满足B>M
- 此时重要饼的频率将比用户设置的频率降低:B - M
- 此时不重要饼的频率将比用户设置的频率降低:B*该分组数据源数量 - M
- 结束策略
- 第一种情况例子:
- 假设a是重要组 里面只有一个数据源,b是不重要组里面有3个数据源
- 然后平台间隔是2s,那么在用户设置间隔8s时刚好可以不减
- 这种情况下蹲饼周期是这样的:
- 0s-a, 2s-b1, 4s-b2, 6s-b3, 8s-a, 10s-b1, 12s-b2, 14s-b3
- 第二种情况例子:
- 如果用户设置间隔是4s,其他条件如上
- 这时候就会减,减到所有平台可用请求=(用户间隔/平台间隔)
- 可用请求数量初始按数据源分配的,所以一开始是 (1+3) ≠ (4 / 2)
- 然后轮流减,a最低为1不会减,然后b减 (1+2) ≠ (4 / 2)
- 还是不满足就继续减 (1+1) = (4 / 2)
- 此时满足了,然后a和b的数量都是1了
- 现在的周期就是:
- 0s-a, 2s-b1, 4s-a, 6s-b2, 8s-a, 10s-b3
- a的频率满足了4s然后降了b的频率
- 第三种情况例子:
- 如果用户设置为5秒,平台间隔为10秒
- 有3个数据源,a组重要组一个,b组重要组一个,c组不重要组3个
- 因为有3组,平台最小间隔5秒,一轮蹲完最小间隔=(3*5) > 10,无论如何无法满足用户蹲饼间隔
- 所以按平台最小蹲饼间隔*组数量计算
- 该种情况周期为
- 0s-a, 5s-b, 10s-c1, 15s-a, 20s-b, 25s-c2, 30s-a, 35s-b, 40s-c3, 45s-a, 50s-b, 55s-c1,