awesome-fenix
awesome-fenix copied to clipboard
「Comment」https://icyfenix.cn/distribution/traffic-management/traffic-control.html
https://icyfenix.cn/distribution/traffic-management/traffic-control.html
“只要在令牌中增加一个时间戳记录,每次获取令牌前,比较一下时间戳与当前时间,就可以轻易计算出这段时间需要放多少令牌进去,然后一次过放完全部令牌即可”一次性写错了。 这句话的意思是在获取令牌时顺便放令牌吗
@UUNNFLY “只要在令牌中增加一个时间戳记录,每次获取令牌前,比较一下时间戳与当前时间,就可以轻易计算出这段时间需要放多少令牌进去,然后一次过放完全部令牌即可”一次性写错了。 这句话的意思是在获取令牌时顺便放令牌吗
在每次取令牌时放也可以,一般来说,考虑到实现效率,在每次取不到令牌时放会更合适些。
“以上这三点都是基于都调用计数的指标”是否多了一个“都”
TCP 用到滑动窗口算法的应该是流量控制,不是拥塞控制
TCP 用到滑动窗口算法的应该是流量控制,不是拥塞控制
感谢指正,已更新。
假设不考虑顺序且请求分发是均衡的,在保证不超时的前提下,整个集群能持续承受最多每秒多少笔业务操作?
答:40 × 10 ÷ 5 = 80 TPS
shouldn't it simply be 40 TPS
?
40 × 10 ÷ 5 = 80 TPS 这个单个服务的0.5s是平均情况,也有快速的情况,80是个参考值,具体的应该压测,或者流量回放更准确一些
40 × 10 ÷ 5 = 80TPS,这个计算公式想不明白。能解答一下QPS是怎么换算到TPS的吗?
@HsiangCheng 40 × 10 ÷ 5 = 80TPS,这个计算公式想不明白。能解答一下QPS是怎么换算到TPS的吗?
集群每秒总的能力是40 × 10,每个业务1秒处理完成需要的能力是5 这样每秒就可以处理80次业务
尽管扫描支付二维码时尽管客户端只发送了一个请求
这句话多了尽管俩字,正确的应该是:尽管扫描支付二维码时客户端只发送了一个请求
整个集群能持续承受最多每秒多少笔业务,4010/5 = 80 笔。这里应该是错了,单个服务是40。10个服务合起来整个业务数,也不可能超过单个服务的请求数。应该4010/10=40笔。40*10是一秒钟10个服务处理的所有请求数,每一个业务需要处理10个请求。
@etatata 整个集群能持续承受最多每秒多少笔业务,4010/5 = 80 笔。这里应该是错了,单个服务是40。10个服务合起来整个业务数,也不可能超过单个服务的请求数。应该4010/10=40笔。40*10是一秒钟10个服务处理的所有请求数,每一个业务需要处理10个请求。
但是,这一个业务的10个请求不是必须要在1秒内发生的。这个业务走完一个流程是5s,所以是400/5不是400/10.前提是不考虑执行顺序而且请求均衡
@younghluuu
@etatata 整个集群能持续承受最多每秒多少笔业务,4010/5 = 80 笔。这里应该是错了,单个服务是40。10个服务合起来整个业务数,也不可能超过单个服务的请求数。应该4010/10=40笔。40*10是一秒钟10个服务处理的所有请求数,每一个业务需要处理10个请求。
但是,这一个业务的10个请求不是必须要在1秒内发生的。这个业务走完一个流程是5s,所以是400/5不是400/10.前提是不考虑执行顺序而且请求均衡
还是没有明白为什么要除5, 是怎么得出来的5啊,
@younghluuu
@etatata 整个集群能持续承受最多每秒多少笔业务,4010/5 = 80 笔。这里应该是错了,单个服务是40。10个服务合起来整个业务数,也不可能超过单个服务的请求数。应该4010/10=40笔。40*10是一秒钟10个服务处理的所有请求数,每一个业务需要处理10个请求。
但是,这一个业务的10个请求不是必须要在1秒内发生的。这个业务走完一个流程是5s,所以是400/5不是400/10.前提是不考虑执行顺序而且请求均衡
这个单位是有问题的吧,400的单位是 query/s,5的单位是 s/t,最后得出来并不是 t/s。如果是 400q/s ÷ 10q/t = 40t/s 这样感觉是对的,但是整个题目就和超时时间无关了
我觉得应该是 40t/s * 10s * (10s/5s) /10s = 80t/s。简化后就是 40t/s * (10s/5s) ,这样就很好理解来了,就是算倍数而已。
漏桶在代码实现上非常简单,它其实就是一个以请求对象作为元素的先入先出队列(FIFO Queue),队列长度就相当于漏桶的大小,当队列已满时便拒绝新的请求进入
这里的描述看起来不完整,并没有说清楚是如何实现按给定速率流出的;另我看 uber ratelimit 的实现,其中并没有用到 queue, 简化版Python实现如下
class LeakyBucket_V1:
def __init__(self, rate, per=1):
self.per_request = per / rate
self.last = 0
def take(self, n=1):
now = time.time()
sleep_for = self.per_request - (now - self.last)
if sleep_for > 0:
time.sleep(sleep_for)
self.last = now + sleep_for
else:
self.last = now
def testV1():
rl = LeakyBucket_V1(1) # 1 per second
for _ in range(10):
rl.take()
time.sleep(0.1) # simulate hard work
Log.info("<---do a job")