程序中如何设计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且有完善和修改

程序中如何设计backup request功能

上一篇:地形图转obj:如何使用3DMax制作三维地形图


下一篇:Svelte在吹,或许有道理,虚拟DOM纯属是一种开销(翻译版本)