1 前言
过载的出现，理论上都有可能产生，向任何向外提供的服务，发起DDos攻击，都可以认为是过载的发生。在发生过载的情况下，处置不好的话，很可能出现下列情况：
由此我们得出了一个新的处理思路。该思路主要包括三方面：过载识别，过载处理，过载恢复。看似和前述方案有相似之处，但细节上面还是有较大的不同，且看后续论述。
处理能力，难道不就是上篇所述的配置的处理阈值么？但它不会动态变化，我们可以考虑对处理能力进行计算。而请求量，则是由前面一段时间所统计得到。
注：在继续描述之前，我们约定一下，右上角有红色stat字样的,表明该数据是可以通过统计得到的；右上角红色const字样，表明该数据是个常量；其余都是通过计算得到。
图 1
2.2 过载识别的参数 由前可知，统计时间C和单位时间，是需要设定的一个数值，目前该数值为30秒和5秒，经过测试可以满足要求。两个数值越大，过载识别的灵敏度就会越低，越小，则统计会过于频繁，耗费资源，且有抗抖动能力不够。
最初还有一个方案，考虑到过载时刻，极可能对端的系统缓冲区也塞满了数据，则将链接断开再重新简历，缓冲区中的数据自然就会被清空，但该方法过于暴力，而且使用断开链接之后，还需要重新注册服务，其有效处理能力会下降许多。最后也会对此方案做测试数据对比。
该方案的好处，一是考虑到了对端的时间；二是将粒度放大，无需每个请求包都需要判断时间，只需要判断Hello包中的时间戳；三是真正过载的时刻，需要丢弃的包往往数量很大，通过每秒的Hello拒绝丢弃，也可提高丢弃的速率，相对较快的找到有效包。
首先算法中的几个点需要注意：
2、 时间戳由于各种问题修改会导致各个服务器的unixtime不一致的问题，同时没有较好的时间同步机制，解决该问题的方法，在后续将详细阐述；
4、 如果最新Hello包中的时间戳小于本地记录的Hello时间标尺，会将该本地记录的Hello时间标尺替换；
1、不同服务器之间时间不同步；
解决这两个问题，分别采取了以下两个对应的措施：
如图所示，我们将时间延时分隔加大，方便分析数据。图中可见服务器A和服务B中的时间并不一致。
当B接收到了第2个Hello包时，同样计算两端服务器时间戳差值T2 (9s)，比对T1和T2，如果处于阈值范围之内，就表明数据没有过期。
由此可以消除不同服务器之间时间不同步的问题，另外时间戳的粒度以秒为单位就会过粗，因此是以0.1秒为单位，同时参考上述算法，时间标尺是会根据情况进行重置的。
O 时间戳的选择；
方法二：使用clock_gettime函数，使用CLOCK_MONOTONIC或者CLOCK_MONOTONIC_RAW参数。代表从过去某个固定的时间点开始的绝对的逝去时间，它不受任何系统time-of-day时钟修改的影响，如果你想计算出在一台计算机上不受重启的影响，两个事件发生的间隔时间的话，那么它将是最好的选择，但该时间自系统开机后就一直单调地增加（ntp adjtimex会影响其单调性，目前对于我们的需求是足够的），但它不像因用户的调整时间而产生跳变。而CLOCK_MONOTONIC_RAW是完全不受任何影响，是一个绝对的单调递增，是绝佳的选择，但其只能在linux较高版本中使用。
4 过载恢复 过载控制的恢复，需要同时满足以下两个条件才可以恢复:
2、 所有链接都不处于丢包状态；因为如果处于过载丢包状态，其处理数据量的速度是十分快的，如果单用条件1进行判断，一般都能够满足，但此时还是处于过载状态。
5.1 测试方案
O 该消息就是命令测试服务器等待一定的时间，使用等待时间的变化来模拟处理能力的变化。
O 所有Lotus的Hello包间隔为1秒，过高，则有效包执行较低，过低，则粒度过细，需要判断的次数较多。从后续效果上看，1秒的时间间隔是一个较好的选择，但依据业务的不同，可以设置不同的时间间隔。
1、 有效处理额定比率；即发生过载之后，能够处理的有效包，占理论处理能力的比率。比率越高，效果越好。
5.2 原始状态 以下是未做任何过载保护的处理，可以发现不做过载保护的服务，可用性是极差的。
5.3 时间片处理过载 由于本版先后采用了两种过载识别方案：一种是检测循环执行时间和直接使用时间戳是否过期的方式来判断过载；另外一种就是当前所使用的动态过载识别的方式。
从上面的数据，我们可以初步得出以下一些测试结论：
2、 随着时间的增长，有效比率可以稳定在较高的位置上。
5.3.2 动态过载识别 先给出一组数据，可以先看下我们计算出来的处理能力和请求量：
此时每秒都会收到来至于接入服务器Lotus的Hello包，通过下图我们可以看出，每3秒的请求量是1056字节，我们计算出能够处理的请求量大概在2.8M左右，每次主循环大概有567us耗费在处理其他事物上。
收到大量处理耗时较低的数据；
上图是恢复阶段，也见在过载恢复时刻，服务器的状态迅速得到恢复。
从上图可以看出，请求量迅速增加，处理能力从2.8M/s下降到了0.1M/s，触发过载保护，在保护期间丢弃掉过期包，处理能力又恢复成了1.8M/s，但由于目前还处于丢包状态，并不会触发过载恢复。
下面是测试的一些详细数据：
本文由腾讯WeTest团队提供，更多资讯可直接戳链接查看：http://wetest.qq.com/lab/
微信号：TencentWeTest
