服务器过载保护（下篇）——过载处理新方案

来源：互联网发布：平安科技数据生态圈编辑：程序博客网时间：2024/05/16 06:14

转自：http://blog.csdn.net/wetest_tencent/article/details/51206578

本文由腾讯WeTest团队提供，更多资讯可直接戳链接查看：http://wetest.qq.com/lab/
微信号：TencentWeTest

文/iven

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较高版本中使用。