1. 什么是长尾?

长尾请求一般是指明显高于均值的那部分占比较小的请求。 业界关于延迟有一个常用的P99标准, 也就是99%的请求延迟要满足在一定耗时以内, 1%的请求会大于这个耗时, 而这1%就可以认为是长尾请求。

 

2. 长尾会导致什么危害

假设,一个服务B,有1%的可能性响应时间大于1s,如果此刻一个上游服务A需要完成一次查询,需要同时查询100次的话,那么服务A响应时间超过1s的概率是63%。

怎么算的?

0.99的概率是小于1s,100次的概率是0.99^100 = 0.37,小于1s响应的时间是37%的概率。

那么请求大于1s的概率就是63%,对比图中蓝线

即使服务处理时间超过1秒的比例仅为 0.01% (对照上图中的绿线,1 in 10000),当需要同时查询的实例数(Numbers of Servers)达到2000时,服务延时大于1秒的请求数将超过18%

 

3. 什么造成的长尾

这就多了去了

共享资源竞争, 周期性的垃圾回收, 运维活动(比如日志备份), 硬件或者软件故障,网络的抖动,都有可能造成。

 

4. 如何解决长尾

微博motan有一种双发机制,它可以有效解决长尾问题,同时能提升系统吞吐量。

传统解决接口超时问题可能通过重试,在一次请求发送之后等待指定的超时时间,如果没有返回则再请求一次,最差情况下要消耗 2 倍的超时时间。

而双发机制则不然,在发送一次请求后等待 P90(在 T1 时间内有 90% 的请求都能返回则称 P90=T1,通常系统的 P90 和程序设置的超时时间相比小很多)时间。

如果请求没有返回则在此刻再次发送一次请求,在超时时间内,这两个请求中取最快返回的那个。

当然,这里有个防雪崩机制,假如,超过一定数量的请求(比如 15%)都在进行双发,则认为服务整体有问题,会自动停止双发。实践证明,双发机制的去长尾效果非常明显

 

 

其二国外有一种C3自适应副本选择机制

C3是一个自适应的副本选择机制, 目标是减少服务长尾对整体响应时间的影响. C3的设计坚持2个原则, 一是自适应, 副本选择必须能够快速的处理服务性能波动; 二是行为良好, 避免惊群效应. C3的主要设计思路包括2个组件:

  1. 副本排序. 使用最少的和相似的server端反馈来指导client端对所有server进行打分和排序. 打分算法还必须考虑多个client的因素以及避免惊群效应.
  2. 分布式速度和压力控制. 每个client需要控制对server端请求发送速度, 采用一种分布式的拥塞控制技术. 当所有的服务端超出请求发送速度时, client端不再继续向server发送请求了.

cassandra已经运用了C3的技术

 

解释一下上面的意思

传统的rpc选择server的时候是通过随机,权重等等,对于server端的性能参考是很低的,通过对server端处理请求速度以及rpc调用的任务队列长度进行排序,打分,选择出那个性能最好的server进行调用。因为这个server端质量好,所以可能导致client都选择这个server,可能导致server压力瞬间很大,client端需要预估server端的容量并且调整发送速率. 每个client对每个server维护了一个基于令牌桶的速率限制器, 限制在一个时间窗口内发送给server的请求数量. 我们定义发送速率为srate. 为了根据感知到的server性能变化来控制速率, client端追踪在这个时间窗口内接收到的请求数量, 也就是接收速率rrate. 速度控制算法的目标是根据rrate及时调整srate.