apache
backup request可以支持下游错误率高于一定阈值时不生效吗？
我们是对backuprequest做了优化处理，只允许x%的请求发起backuprequest，并且backuprequest的阈值不是固定值，而是跟随延时的P99或者P95一起波动
我们是对backuprequest做了优化处理，只允许x%的请求发起backuprequest，并且backuprequest的阈值不是固定值，而是跟随延时的P99或者P95一起波动
有代码吗？这个需求挺常见的
容灾方面是不是可以全面一点？ （周期或者滑动窗口）统计请求的成功率，根据成功率可以做以下策略：
- lb选实例时，减少访问可用性弱的实例；
- 减少重试（包括backup request）。
- 其他，待补充。
https://grpc.io/docs/guides/request-hedging/ grpc也有类似的请求策略，叫Hedged Request，为了防止雪崩，做了一个类似令牌的限制策略
容灾方面是不是可以全面一点？ （周期或者滑动窗口）统计请求的成功率，根据成功率可以做以下策略：
- lb选实例时，减少访问可用性弱的实例；
- 减少重试（包括backup request）。
- 其他，待补充。
- lb可以参考现有的la或者通过LoadBalancerExtension()->RegisterOrDie("namexxxx", new LBXXX)自定义新的。
- 但减少重试是个lazy行为，一开始发起A、B、C请求都配上backup_request，到backup_request_ms后，A已完成，只有B、C需要backup_request，假如此时只允许50%触发backup_request。就得在HandleBackupRequest里一开始拦截一下，避免触发EBACKUPREQUEST。这个feature需要支持下。
在HandleBackupRequest里一开始拦截一下，避免触发EBACKUPREQUEST。
需要这么及时地拦截吗？
ChannelOptions支持一个backup_request_policy，支持动态backup_request时间，这样处理起来更统一，更能满足多样的需求吧。
不在HandleBackupRequest里及时拦截的话，backup_request就发给下游server了，可能造成单server请求暴增。
ChannelOptions加backup_request_policy，是打散backup_request_ms吗？现在controller就可以设置请求粒度的backup_request_ms。而且 backup_request最好是在< backup_request_ms内没响应的多个请求中选择触发某几个。
拦截是基于什么指标呢？这个指标不灵敏的话，在HandleBackupRequest或者backup_request_policy拦截，差别不大吧。
controller设置backup_request_policy也是请求粒度的。
最简单的可以是允许backup_request_ms时未响应request做随机拦截，随机数可以做到，比如未响应请求里面只允许10%做去做backup_request。或者按请求优先级，这个先忽略。
因为一开始发请求时，哪些请求在backup_request_ms未响应是未知的，所以都controller set_backup_request_policy，等backup_request_ms时间到了，此时怎么做10%真正触发backup_request呢？
嗯嗯，理解这个场景了。其实跟RetryPolicy一样，让用户决定是否要继续发请求。
或许backup_request_policy可以都支持：
- 支持动态timeout；
- 支持在HandleBackupRequest拦截。
顺便提下，希望policy可以拿到对应的controller对象，进而取xxx某个属性，做优先级加权计算判断是否触发backup_request。
嗯嗯，理解这个场景了。其实跟RetryPolicy一样，让用户决定是否要继续发请求。
或许backup_request_policy可以都支持：
- 支持动态timeout；
- 支持在HandleBackupRequest拦截。
@icexin @GreateCode @xiaoma2015 @NuttyNull 提了个PR，大家看看有什么建议？