1 背景

动态探测是周期性进行的，全局默认2分钟，支持分频道设置探测频率（最低1s探测频率），这就决定了选路也是周期性的，在两次最优路径更新的时间间隔内，如果回源链路发生波动，则只能依靠失败后重试来解决，如果域名并发量很大，同一时间可能产生大量重试，这样一方面客户体验不好，另一方面也加重了平台的压力。

2 方案

2.1 错误信息格式

路径失败主要包括两种类型，包括父层返回错误和源站返回错误(建联失败或者返回4xx,5xx)，可以通过内部头，把产生错误的源地址、目的地址、目的端口，后端角色和时间戳返回给边缘。

2.2 错误信息存储

边缘需要对错误信息进行存储，并在选路时通过对选路信息和错误信息做对比，剔除掉已经置为不可用的路径信息。

边缘错误信息的存储有两种存储方式：一是lua的共享字典 shared.dict 方式，二是lua的 lrucache 方式

lua共享字典 shared.shict 使用的是共享内存，每次操作都是全局锁，如果高并发环境，不同 worker 之间容易引起竞争。所以单个 shared.dict 的体积不能过大。

lrucache 是 worker 内使用的，由于 Nginx 是单进程方式存在，所以永远不会触发锁，效率上有优势，并且没有 shared.dict 的体积限制，内存上也更弹性，但不同 worker 之间数据不同享，同一缓存数据可能被冗余存储。

比较了上述两种错误信息的存储方式，结合此功能的业务场景是应用在高并发时减少重试的次数，所以考虑使用 lrucache 更合适一些。这样实现出来的效果就跟 nginx 原生的 max_fails 和 fail_timeout 的配置效果相似了（nginx 原生的max_fails 和 fail_timeout 是在单 worker 内进行统计并起作用的）。

2.3 错误路径对比

（1）单位周期内发生M次错误

在单 worker 单位周期为 fail_timeout 设置的时间中，失败达到 max_fails 次数，那么接将把节点标记为不可使用，对于已经标记为down的节点，在这个周期中不再使用包含此节点的路径。

等待下一个周期（同样为fail_timeout）再一次去请求，判断能否连接能否成功，开启下一次的循环。

源ip，目的ip，目的端口加入到匹配判断当中，对于不符合的路径信息剔除掉

（2）连续发生N次错误

在单 worker 单位周期为 fail_timeout 设置的时间中，连续失败达到 conti_max_fails 次数，那么接将把节点标记为不可使用，对于已经标记为down的节点，在这个周期中不再使用包含此节点的路径。等待下一个周期（同样为fail_timeout）再一次去请求，判断能否连接能否成功，开启下一次的循环。

连续发生N次错误和单位周期内发生M次错误，两者是或的关系，当满足其中任何一个条件时，都把后端错误的节点置为down。

3 配置方式

源站的配置方式，可以针对不同源站设置不同的最大失败次数，连续失败次数和失败的超时时间， 父层属于内部节点没必要做分开统计，做成一个统一的配置项即可。