程序中如何设计backup request功能

retry

集群中有client、server1, server2三台机器，client需要向server请求数据，如果server1响应超时，则请求server2。server1、server2互为备份，包含同样的数据。

client:

for (id = 0; id < 2; id++)
{
   if (timeout == do_request(server[id], timeout, req) )
   {
          continue; // retry next server
   }
}

timeout是外部传给client的总超时数。上面的代码有一个问题：当网络阻塞或者server十分繁忙的时候，do_request会超时，一旦超时，则总超时时间都被耗尽，根本没有剩余时间去重试下一个server。

因此，正确的retry设计需要考虑到“网络阻塞或者server十分繁忙”的情况，分给每个server的timeout时间只能是总timeout的一部分，代码改写如下：

for (id = 0; id < 2; id++)
{
   if (timeout == do_request(server[id], timeout * get_timeout_percent(), req) )
   {
          continue; // retry next server
   }
}

不过，对于server挂掉的情况（socket层面无法连接）do_request请求这个server会立即失败，可以不设置timeout_percent。

backup request

jeff dean的一篇论文中介绍了google利用backup request来大幅度降低响应延迟的问题，在论文中他将这种请求成为tied request。他在achieving rapid response times in large online services这篇ppt中对此进行了专门的论述。

其原理很简单，用一个例子来简单阐述：

集群中有client、server1, server2三台机器，client需要向server请求数据，如果server1响应超时，则请求server2。server1、server2互为备份，包含同样的数据。client收到任意响应数据后立即通知其他请求过的server取消操作。

有两种设计方案：

方案一：

1. client向server1发出req请求，req在server1任务队列中排队
2. server1开始执行req，在执行前给client发一个quick response
3. client如果在超时时间内收到quick response则不发起backup task，否则client一旦超时，就立即发起backup task
4. client收到任意server的结果时，立即给其它所有发给过请求的server发cancel request
5. client先行退出
6. 对于执行任务的server，它如果及时收到了cancel request，则直接取消任务，如果收到不及时，任务已经开始，则还是老老实实做任务。任务做完后丢弃结果。
7. client收到过期的结果直接丢弃

方案二：

1. client向server1发出req请求
2. client等待超时，则立即向server2发req请求
3. 任意server返回了req结果，则发cancel request给其它相关server
4. client收到过期的结果直接丢弃

note：无论方案1还是方案二，实现这样的异步系统的时候都要很小心，一要防止内存泄露，一要方式提前析构导致野指针。

超时如何选择

建议选择p99或者p95，因为backup request操作是用来实现消除长尾的，并不是提升性能的。如果将该值设置过低，则会由于backup request的请求量过大而导致集群压力增大（假设选择p50作为其延时，这样便会有50%的请求向server2发送请求，系统负载便会增大50%）。

如果超时设置的是p999时间，大约1000个请求里只有1个请求会发送backup request，因此额外请求量（也就是开启backup request的额外开销）比例在0.1%左右。依此类推，若想要降低p99时延，则可以将超时设置为p99延迟，由此会增加1%的额外读流量。

设计要点

设计backup request的关键是要防止服务器繁忙时期的请求风暴。在服务器繁忙时期client容易发生等待超时，倾向于发送backup request。大量的backup request会进一步让服务器更繁忙，于是请求风暴诞生了。防止请求风暴的要点是区分普通超时和风暴期超时。

从统计的角度看，普通超时的模式与风暴期超时的模式肯定有很大区别，这是一个入手点。

从使用方式上，区分scan和get也可以一定程度防止请求风暴。在oceanbase中，get请求是对延迟敏感的，scan请求则要求低一些。而恰好get请求对系统的压力也小很多。所以，在oceanbase中可以只对get请求使用backup request。

对于非幂等性操作慎用backup request！！！

小结

retry和backup request之前的区别在于retry不会给server发送cancel request，也不会等待多次请求使用最先返回的响应。

转载csdn且有完善和修改