Open ycren993 opened 2 months ago
https://github.com/youngyangyang04/RPC-Java/blob/ab0870519c49f198e0d603315d749e3de34c1537/version4/src/main/java/part1/Server/ratelimit/impl/TokenBucketRateLimitImpl.java#L38 (1) 如果进入if块时curCapacity只能为0,代码是否可以优化成这样 ![Uploading image.png…]() 可读性应该会更好。 (2) curCapacity为int类型,若当前时间戳与上次时间戳差值除以RATE得到一个高精度数值,没有进行int强制转换前,得到一种极端情况,令牌为1.98个,此处强行转换int,导致丢失0.98个令牌,且更新当前时间戳,0.98个令牌是否会永久丢失,若1.99时又过来一个请求,应该会被丢弃,拒绝该请求,一定程度上会导致流量较期待降低,如果这个问题确实存在,应该流量是会普遍降低,因为是向左取整(不管是1.001,还是1.999,都取得1),如果短期快速更新,认为可以采用四舍五入的方式,长期来看应该还是提升精度更佳。
不好意思最近没有关注项目的issue。 1.图片未成功加载 2.取整问题确实会导致请求一定的限制;所以这里的精度即RATE是可以改变的,依实际场景而定吧
https://github.com/youngyangyang04/RPC-Java/blob/ab0870519c49f198e0d603315d749e3de34c1537/version4/src/main/java/part1/Server/ratelimit/impl/TokenBucketRateLimitImpl.java#L38 (1) 如果进入if块时curCapacity只能为0,代码是否可以优化成这样 ![Uploading image.png…]() 可读性应该会更好。 (2) curCapacity为int类型,若当前时间戳与上次时间戳差值除以RATE得到一个高精度数值,没有进行int强制转换前,得到一种极端情况,令牌为1.98个,此处强行转换int,导致丢失0.98个令牌,且更新当前时间戳,0.98个令牌是否会永久丢失,若1.99时又过来一个请求,应该会被丢弃,拒绝该请求,一定程度上会导致流量较期待降低,如果这个问题确实存在,应该流量是会普遍降低,因为是向左取整(不管是1.001,还是1.999,都取得1),如果短期快速更新,认为可以采用四舍五入的方式,长期来看应该还是提升精度更佳。