在应用结构上有这样一个业务场景，机房里部署了多个物理数据库的Proxy无状态节点，业务端通过Proxy节点间接和存储DB交互。Proxy支持了分库分表的特性，管理下层多个物理DB，向上层提供单表抽象。为了支持高可用性，Proxy为多节点部署，业务端可以随机挑选Proxy收发消息。

这里我们讨论业务端SDK的Failover实现方案。SDK需要管理指向多个Proxy连接，每个请求都需要随机挑选某个Proxy连接进行收发消息。当Proxy都正常时，随机算法已经可以满足负载均衡了。但是Proxy是可能会突然宕机的，挂了一个Proxy节点后，SDK需要快速摘除宕机的Proxy连接，将所有的请求都转移到其它节点之上。当这个Proxy节点恢复后，又可以重新将这个节点放回Proxy列表中。

那这种快速的动态调整，SDK又该如何以最简单的方法进行实现呢？一般的思路如下

1. 使用计数机制，当请求出现错误时，比如在一定的时间窗口里出现了N次错误，那就可以标记该Proxy已损坏，从Proxy正常列表中摘除掉该Proxy，同时在恢复列表中加入该Proxy

2. 使用Retry机制，每隔一段时间对恢复列表中的Proxy进行重试，重试一旦正确，就立即将Proxy从恢复列表中转移至正常列表

3. 如果所有的Proxy都损坏了，那最后一个Proxy是不可以随便摘的。如果直接摘掉了，会导致Retry窗口内服务不可用。即使Proxy快速恢复了，也需要等待Retry窗口的时间才可以检测到。一般的做法是，如果所有的Proxy都坏掉了，那请求的随机Proxy列表不再是正常Proxy列表，而是全体Proxy列表。

要对这种思路进行编码实现有一定的复杂度。比如下图是pylibmc的状态转移图，看一眼知道复杂度非同一般。

为降低复杂性，我设计了一个非常简单的方案，可以很好的解决Proxy Failover的问题，步骤如下

1. 给每个Proxy设定一个初值，比如说1024，该值作为随机权重使用

2. 每次请求出现失败一次，就将权值除以一个数，比如说2，数字越大，降权越快。

3. 当权值降低到最小值，比如说1时，不再继续降权。这样可以保持坏掉的Proxy以一个极低的概率得到重试。

4. 只要有任何一个成功的请求，就将权值恢复到初值。

5. 当SDK通过权重随机挑选了一个Proxy进行了一个失败的请求时，将重新随机挑选Proxy进行重试，记录重试次数，直到成功为止或者重试到了一个最大次数上限，向上层抛出异常。

这种方案的优势在于不需要划分出正常列表和恢复列表，没有复杂的状态迁移，而且不需要设置额外定时器进行重试。当所有的节点都坏掉的情况下，所有的Proxy权重也还是一样的。我尝试用代码实现了这个方案，用了非常简洁的十几行代码就搞定了Failover问题。

当然这种方案也不是完美的，它的缺点体现在需要仔细控制权重参数，初始值/降权系数/最小值，特别是最小值，如果设置的太小，而SDK的QPS又太低的话，Proxy可能会长时间得不到恢复，不过这种情况也没有关系，如果QPS太小，要那么多的Proxy做负载均衡也是多余的。