[GitHub] [incubator-brpc] zyearn opened a new issue #709: 下游全部熔断后恢复机制

[GitBox <gi...@apache.org>]

zyearn opened a new issue #709: 下游全部熔断后恢复机制
URL: https://github.com/apache/incubator-brpc/issues/709
 
 
   一台机器暂时卡死或因某些原因返回错误数过多目前会被熔断器从serverlist中摘除，如果被熔断的机器太多，那么剩下的机器就会负载变大，错误变多，从而更加容易发生熔断，一种极端的case是所有机器都发生了熔断。此时，如果一台机器恢复了，大量的请求蜂拥而至，从而使得该台机器再次熔断，集群永远无法恢复到正常状态。有一种解决办法是服务端设置正确的并发数，对于因超过容量而错误的请求，熔断器不计算这些错误，那么至少能保证一部分请求可用。然而这种方式要求并发数是正确的，在线上一些混部的场景中，业务线很难根据线下的测试来估计线上的并发，不是一种非常灵活的解决方案。另外一个缺点是，在超大请求的情况下，光光是返回ELIMIT就可能把server打爆。此设计想要提供一种通用的熔断恢复机制。
   
   一般而言，业务线会根据峰值QPS来估算出能满足所有请求的必须的server数量n，算上一定比例k的冗余，server总数为kn，那么就算kn-n台server挂了，在正常情况下，整个集群还是能正常工作的。假设现在若干server挂了，导致出现了连环熔断，最终可用server为0，此时进入恢复状态。在恢复状态时行为为
   * 若当前由健康检查恢复的server数量为q，则client保留请求的概率为q/kn，否则丢弃。在这个阶段时，我们要保证的一点是每台server要尽可能打满，由于有kn台server可以服务峰值流量，现在剩下q台，很容易算出能正常服务请求的概率为q/kn，丢弃的概率为1-q/kn。这里会发生一种情况是由于混部、离线任务等原因，各个机器的资源不是一样的，导致发了q/kn的流量过去，server还是被打爆了，从而又进入没有一台server能恢复的死循环。这需要用户来自行来解决这个问题，在这种情况下集群的资源可能本来就是不够用了，需要进行扩容或者其它别的方法把资源留出来。用户需要保证每台server至少能服务1/kn的流量，否则冗余比例应该增大。使用这个机制后，可以保证某一台server恢复后，不会再次进入熔断状态，并等待下一台server恢复。
   * 一直进行上述这个恢复过程，直到q的数值在一段时间T内保持不变，则可以认为目前集群中只有q台可以用。如果一直保持丢弃请求，会发生在流量不高的时候，q台完全足够了，但发生丢流量的情况。此时需要另外一个机制来保证流量不丢。这里可以采用一种比较直观的方式，即把流量重新打到全部可用的机器上，并离开恢复状态。此时如果流量太大超出q台的负载，需要设置server最大并发来拒绝服务，熔断恢复的前提是server/资源已经恢复，所以可以认为设置的最大并发是正确的（这里有一种优化是client根据ELIMIT的数量来直接拒绝请求降低server端的压力，详细见https://landing.google.com/sre/sre-book/chapters/handling-overload/#eq2101）
   * 如果q=kn，即server全部恢复了，那么也会离开恢复状态。
   
   细节确定
   * 如何选定上述T的值？这是个业务相关的值，某些server可能会因为业务原因（load模型数据）卡住，那么T的取值至少是卡住的时间加上健康检查的间隔。
   * 暴露给用户哪些options？最小server数量n，比例k
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@brpc.apache.org
For additional commands, e-mail: dev-help@brpc.apache.org