backup request可以支持下游错误率高于一定阈值时不生效吗？

[NuttyNull]

是不是可以一定程度防止雪崩？

[xiaoma2015]

我们是对backuprequest做了优化处理，只允许x%的请求发起backuprequest，并且backuprequest的阈值不是固定值，而是跟随延时的P99或者P95一起波动

[icexin]

我们是对backuprequest做了优化处理，只允许x%的请求发起backuprequest，并且backuprequest的阈值不是固定值，而是跟随延时的P99或者P95一起波动

有代码吗？这个需求挺常见的

[chenBright]

容灾方面是不是可以全面一点？
（周期或者滑动窗口）统计请求的成功率，根据成功率可以做以下策略：

1. lb选实例时，减少访问可用性弱的实例；
2. 减少重试（包括backup request）。
3. 其他，待补充。

[icexin]

https://grpc.io/docs/guides/request-hedging/ grpc也有类似的请求策略，叫Hedged Request，为了防止雪崩，做了一个类似令牌的限制策略

[GreateCode]

容灾方面是不是可以全面一点？ （周期或者滑动窗口）统计请求的成功率，根据成功率可以做以下策略：

1. lb选实例时，减少访问可用性弱的实例；
2. 减少重试（包括backup request）。
3. 其他，待补充。

1. lb可以参考现有的la或者通过LoadBalancerExtension()->RegisterOrDie("namexxxx", new LBXXX)自定义新的。
2. 但减少重试是个lazy行为，一开始发起A、B、C请求都配上backup_request，到backup_request_ms后，A已完成，只有B、C需要backup_request，假如此时只允许50%触发backup_request。就得在HandleBackupRequest里一开始拦截一下，避免触发EBACKUPREQUEST。这个feature需要支持下。

[chenBright]

在HandleBackupRequest里一开始拦截一下，避免触发EBACKUPREQUEST。

需要这么及时地拦截吗？

ChannelOptions支持一个backup_request_policy，支持动态backup_request时间，这样处理起来更统一，更能满足多样的需求吧。

[GreateCode]

不在HandleBackupRequest里及时拦截的话，backup_request就发给下游server了，可能造成单server请求暴增。

ChannelOptions加backup_request_policy，是打散backup_request_ms吗？现在controller就可以设置请求粒度的backup_request_ms。而且 backup_request最好是在< backup_request_ms内没响应的多个请求中选择触发某几个。

[chenBright]

拦截是基于什么指标呢？这个指标不灵敏的话，在HandleBackupRequest或者backup_request_policy拦截，差别不大吧。

controller设置backup_request_policy也是请求粒度的。

[GreateCode]

最简单的可以是允许backup_request_ms时未响应request做随机拦截，随机数可以做到，比如未响应请求里面只允许10%做去做backup_request。或者按请求优先级，这个先忽略。

因为一开始发请求时，哪些请求在backup_request_ms未响应是未知的，所以都controller set_backup_request_policy，等backup_request_ms时间到了，此时怎么做10%真正触发backup_request呢？

[chenBright]

嗯嗯，理解这个场景了。其实跟RetryPolicy一样，让用户决定是否要继续发请求。

或许backup_request_policy可以都支持：

1. 支持动态timeout；
2. 支持在HandleBackupRequest拦截。

[GreateCode]

下周能提个pr吗，我们想用~~

[chenBright]

我下周找时间搞一下。

[GreateCode]

顺便提下，希望policy可以拿到对应的controller对象，进而取xxx某个属性，做优先级加权计算判断是否触发backup_request。

[chenBright]

可以拿到controller的。