服务器程序中如何设计backup task功能
Retry

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

client:

      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 Task

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 response3. client如果在超时时间内收到quick response则不发起backup task，否则client一旦超时，就立即发起backup task3. client收到任意server的结果时，立即给其它所有发给过请求的server发cancel request4. client先行退出5. 对于执行任务的server，它如果及时收到了cancel request，则直接取消任务，如果收到不及时，任务已经开始，则还是老老实实做任务。任务做完后丢弃结果。6. client收到过期的结果直接丢弃方案二：1. client向server1发出req请求2. client等待超时，则立即向server2发req请求3. 任意server返回了req结果，则发cancel request给其它相关server4. client收到过期的结果直接丢弃

note：无论方案1还是方案二，实现这样的异步系统的时候都要很小心，一要防止内存泄露，一要方式提前析构导致野指针。
设计要点设计Backup task的关键是要防止服务器繁忙时期的请求风暴。在服务器繁忙时期client容易发生等待超时，倾向于发送backup request。大量的backup request会进一步让服务器更繁忙，于是请求风暴诞生了。防止请求风暴的要点是区分普通超时和风暴期超时。从统计的角度看，普通超时的模式与风暴期超时的模式肯定有很大区别，这是一个入手点。从使用方式上，区分scan和get也可以一定程度防止请求风暴。在OceanBase中，get请求是对延迟敏感的，scan请求则要求低一些。而恰好get请求对系统的压力也小很多。所以，在OceanBase中可以只对get请求使用backup task。

小结retry和backup task之前的区别在于retry不会给server发送cancel request。