过载保护之过载处理新方案

1 前言

世界上不存在绝对完美的系统，我们不是上帝，出现问题是必然的。但出现问题并不可怕，关键是否能够处置好问题。

过载的出现，理论上都有可能产生，向任何向外提供的服务，发起DDos攻击，都可以认为是过载的发生。在发生过载的情况下，处置不好的话，很可能出现下列情况：

 

当出现过载的情况下，拒绝请求是必然的，否则就不能称之为过载，拒绝请求即相当于降低了请求量。但根据业务不同，具体的处置方式，也会有所不同。好的过载处理方式，能够保证系统在过载时，提供较高的稳定处理能力：

 

由此我们得出了一个新的处理思路。该思路主要包括三方面：过载识别，过载处理，过载恢复。看似和前述方案有相似之处，但细节上面还是有较大的不同，且看后续论述。

2 过载识别

此处我们提个新方案：通过对比处理能力和外部请求量大小来识别过载,当请求量超过处理能力的80%，则判定为过载，触发过载处理。80%只是个经验值，触及到这个量，就应该告警，考虑优化扩容事宜。

处理能力，难道不就是上篇所述的配置的处理阈值么？但它不会动态变化，我们可以考虑对处理能力进行计算。而请求量，则是由前面一段时间所统计得到。

2.1 处理能力的计算

处理能力可以定义为在单位时间内，系统能够处理的数据大小。我们系统框架的执行模型大致如下：

注：在继续描述之前，我们约定一下，右上角有红色stat字样的,表明该数据是可以通过统计得到的；右上角红色const字样，表明该数据是个常量；其余都是通过计算得到。

 

 

 V计算

 

图 1

 

图 2

 

 

2.2 过载识别的参数

由前可知，统计时间C和单位时间，是需要设定的一个数值，目前该数值为30秒和5秒，经过测试可以满足要求。两个数值越大，过载识别的灵敏度就会越低，越小，则统计会过于频繁，耗费资源，且有抗抖动能力不够。

3 过载处理

据前篇所述，我们可以采用到达本机系统缓冲区的时间来判断数据包是否过期，但由于相关的一些缺点，并且已有系统的问题，并不方便增加应用缓冲区等问题，而考虑其他的方案。相对较佳方案，兼顾服务质量，我们可每条协议中都带上请求的过期时间戳，过期了就直接将该包丢弃。但很可惜由于历史原因，协议中并没都带上时间戳，协议要全部做修改，几乎不可能，并且由于时间校准等问题，并不方便做修改，因而也放弃了。

最初还有一个方案，考虑到过载时刻，极可能对端的系统缓冲区也塞满了数据，则将链接断开再重新简历，缓冲区中的数据自然就会被清空，但该方法过于暴力，而且使用断开链接之后，还需要重新注册服务，其有效处理能力会下降许多。最后也会对此方案做测试数据对比。

目前所用到的方案，考虑到中转服务器（Lotus和Proxy）会与服务器之间进行Hello包保活，而Hello包中有时间戳，依据该时间戳，连续两个Hello包间隔之间的数据，处于同一个时间片之中。另外很重要的一点是，我们内部链接都是TCP/IP长链接，这样数据包必然会保持一个有序的状态。因此变相将各个包的时间粒度放大，由此来达到过载的控制。

该方案的好处，一是考虑到了对端的时间；二是将粒度放大，无需每个请求包都需要判断时间，只需要判断Hello包中的时间戳；三是真正过载的时刻，需要丢弃的包往往数量很大，通过每秒的Hello拒绝丢弃，也可提高丢弃的速率，相对较快的找到有效包。

3.1 算法

算法流程图如下所示：

首先算法中的几个点需要注意：

1、 如果一个循环内执行时延超过一定阈值（可设置成较长时间），我们就有理由可以断定当前的状态是处于过载，立马触发过载保护。这样做的目的，主要是由于框架是单线程的处理模式，等到每次计算处理能力和请求量的时候，有可能就反应迟钝了。

2、 时间戳由于各种问题修改会导致各个服务器的unixtime不一致的问题，同时没有较好的时间同步机制，解决该问题的方法，在后续将详细阐述；

3、 只会丢弃请求包，对于通知和响应的消息包，不会丢弃，其原因前面也有所描述，此处不再赘述； 

4、 如果最新Hello包中的时间戳小于本地记录的Hello时间标尺，会将该本地记录的Hello时间标尺替换；

3.2 Hello包中的时间戳

之前我们使用gettimeofday或者time函数取得系统当前的时间，该函数返回的是unixtime，但都会收到本地时间设置的影响。主要会存在以下两个问题：

1、不同服务器之间时间不同步；

2、本地时间修改； 

解决这两个问题，分别采取了以下两个对应的措施：

Ø 差值比对；确认当前收到的消息的是否过期。

 

如图所示，我们将时间延时分隔加大，方便分析数据。图中可见服务器A和服务B中的时间并不一致。

1. 服务器启动情况之下，在1s时刻B收到了A的Hello包，B记录其时间戳TB1(10s)，同时记录接收到的本地时间戳TA1(1s)，获得其中的差值∆T1(9s)，将这些数据作为标尺。

2. 当B接收到了第2个Hello包时，同样计算两端服务器时间戳差值∆T2 (9s)，比对∆T1和∆T2，如果处于阈值范围之内，就表明数据没有过期。

3. 当B接收到了第6个Hello包时，计算得到差值为∆T6 (7s)，与标尺差值∆T1，发现超出了阈值，如果此时在已经识别出过载的情况之下，则会丢弃后续的来包，直至新的符合要求的Hello包到达。

由此可以消除不同服务器之间时间不同步的问题，另外时间戳的粒度以秒为单位就会过粗，因此是以0.1秒为单位，同时参考上述算法，时间标尺是会根据情况进行重置的。

另外一个很重要的问题就是unix时间会受系统时间的改变而改变，那在过载的情况下，有人或者工具重新设置了一下时间戳，就乱了呢？

Ø 时间戳的选择； 

方法一：我们查找可以使用TSC的方式，来获取精确的时间，且不会因为系统时间的改动而改动，我们假设CPU主频是1MHZ，那么TSC就在1秒内增加1000000。那么获取当前时间伪代码就很简单了。当前时间=时间模块的启动时间+(TSC当前值-TSC初始值)/主频，但该时间由于计算的问题，可能会存在一定的偏差。

方法二：使用clock_gettime函数，使用CLOCK_MONOTONIC或者CLOCK_MONOTONIC_RAW参数。代表从过去某个固定的时间点开始的绝对的逝去时间，它不受任何系统time-of-day时钟修改的影响，如果你想计算出在一台计算机上不受重启的影响，两个事件发生的间隔时间的话，那么它将是最好的选择，但该时间自系统开机后就一直单调地增加（ntp adjtimex会影响其单调性，目前对于我们的需求是足够的），但它不像因用户的调整时间而产生跳变。而CLOCK_MONOTONIC_RAW是完全不受任何影响，是一个绝对的单调递增，是绝佳的选择，但其只能在linux较高版本中使用。

综合考虑，我们目前使用的方法二的CLOCK_MONOTONIC的方法。到此，我们上述的时间戳的问题，就得以解决了。

4 过载恢复

过载控制的恢复，需要同时满足以下两个条件才可以恢复:

1、 请求量低于处理能力；

2、 所有链接都不处于丢包状态；因为如果处于过载丢包状态，其处理数据量的速度是十分快的，如果单用条件1进行判断，一般都能够满足，但此时还是处于过载状态。

5 测试

5.1 测试方案

如图所示为部署图，部署了多个发包工具，通过多个接入服务器（Lotus）向测试服务器发消息。

Ø 该消息就是命令测试服务器等待一定的时间，使用等待时间的变化来模拟处理能力的变化。

Ø 包中也有生成包的时间戳，处理时，会判断该时间戳是否过期，使用该方法来统计执行的是否有效包。

Ø 所有Lotus的Hello包间隔为1秒，过高，则有效包执行较低，过低，则粒度过细，需要判断的次数较多。从后续效果上看，1秒的时间间隔是一个较好的选择，但依据业务的不同，可以设置不同的时间间隔。

由此来测试服务器的过载识别，处理能力，及恢复能力。在测试中，我们关注两个重要的数据：

1、 有效处理额定比率；即发生过载之后，能够处理的有效包，占理论处理能力的比率。比率越高，效果越好。

2、 拥塞恢复时间；即过载停止后，从过载状态恢复到正常的时间。时间越短，效果越好。

5.2 原始状态

以下是未做任何过载保护的处理，可以发现不做过载保护的服务，可用性是极差的。

发了30万个包，其恢复时间就已经无法忍受，另外在实际中，拥塞恢复时间会更加长，因为过载恢复之后，后续肯定还有来包，会一直阻塞，有效比率会更加低。 

5.3 时间片处理过载

由于本版先后采用了两种过载识别方案：一种是检测循环执行时间和直接使用时间戳是否过期的方式来判断过载；另外一种就是当前所使用的动态过载识别的方式。

5.3.1 非动态过载识别

 

从上面的数据，我们可以初步得出以下一些测试结论： 

 

1、 基本处理有效比率可以保持在90%左右；如果处理能力越强（即每个包处理耗时越少），其处理有效比率也会越高。

2、 随着时间的增长，有效比率可以稳定在较高的位置上。

3、 恢复时间和过载时长并没关系，在恢复时，能够较为迅速的恢复处理能力，特别是对于处理能力强的服务，可以出现秒级内的恢复。

5.3.2 动态过载识别

先给出一组数据，可以先看下我们计算出来的处理能力和请求量：

1、 当服务器没有请求时；

此时每秒都会收到来至于接入服务器Lotus的Hello包，通过下图我们可以看出，每3秒的请求量是1056字节，我们计算出能够处理的请求量大概在2.8M左右，每次主循环大概有567us耗费在处理其他事物上。

 

2、 当服务器接收请求时；

收到大量处理耗时较低的数据；

 

如上图可知，处理耗时较低，计算出来的处理能力并未下降，但主循环执行次数迅速下降，统计的请求量迅速增大，立马触发过载处理。

 

上图是恢复阶段，也见在过载恢复时刻，服务器的状态迅速得到恢复。

收到大量处理耗时较高的数据；

 

从上图可以看出，请求量迅速增加，处理能力从2.8M/s下降到了0.1M/s，触发过载保护，在保护期间丢弃掉过期包，处理能力又恢复成了1.8M/s，但由于目前还处于丢包状态，并不会触发过载恢复。

 

从上图可以看出恢复阶段，也是能够较为迅速的恢复。

下面是测试的一些详细数据：

从上表，我们可以发现处理能力与非动态过载识别相差不大，从执行包量上看，会略高于其水平。但由于动态过载识别能够较为准确的识别出过载现象，可以防止出现没有过载而导致的误丢包，可以明确的告知过载情况，总体效果是要好很多的。