1 何为过载

“过载”一词，在海量服务的后台开发中，基本都会遇到。何为过载，即当前负载已经超过了系统的最大处理能力。例如，系统每秒能够处理的请求是100个，但实际每秒的请求量却是1000个，就可以判定系统出现了过载。

过载的定义看似简单，但却是处理过载问题的关键。对于任何其他问题，同样得抓住问题的本质，方可不偏离问题核心，万变而不离其宗。

2 过载后果

“过载”的出现，会导致部分服务不可用，如果处置不当，极有可能引起服务完全不可用，乃至雪崩。

我们的系统中，由于是单线程状态机的处理模式，顺序处理所有链接的缓冲区消息，当出现处理能力的下降或者请求量大幅增加，导致处理能力小于请求量的情况下，消息就会在系统缓冲区中堆积，造成消息处理的延迟会持续增加，在正式环境中，链接数目较多，系统缓冲区较大，最终会导致消息处理延迟大到不可接受的程度，最终会导致处理的都是无效消息，造成服务不可用。

当然具体的业务需要具体的分析，把握住问题的影响，才能够做到一切尽在掌握，根据“墨菲定律”，通常对后果的判断不应过于乐观，谨慎行事、考虑充分才能够做到胸有成竹。

3 过载原因

“过载”的出现，不同系统模型的具体原因都会有所不同，例如CPU跑满，频繁读写导致IO瓶颈，内存耗尽，请求量突增等等。但究其根本原因，可以归结为两点：

1、处理能力的下降；

2、请求量的上升。

只有对自身系统的有更深层和透彻的了解，才能更好地考虑如何处置问题。“头疼医头，脚疼医脚”的处理问题方式，只能解决一时之需，对症下药，才是解决问题的根本之道。

任何问题的保护行为可以依据事件发生的阶段分为：

1、 发生前，预防；

2、 发生时，处置；

3、 发生后，恢复。

但在保护的措施中，都和业务的模型有着相关性，没有完全统一的方案，适合自己的才是最好的。

4 过载预防

在过载发生前的预防，就需在系统设计之初，依据具体的业务模型可以考虑预防过载的措施：

1、 优化服务处理流程，降低处理资源消耗，提升自身处理能力；例如CPU消耗型服务，是否可以考虑优化算法，提升处理能力。

2、 分离处理模块；将负载分担到不同的模块或者服务器；例如IO是瓶颈的服务，考虑是否可以将IO模块进行分离。

3、 负载均衡；将请求量分流，降低单服请求量。

4、 轻重模块分离；重要模块单独部署和处理，防止模块之间的互相影响。

5、 前端防御；在前端控制请求频率，缓解后端压力；例如客户端可以做保护措施，控制聊天频率，点击操作失败，可以延时一段时间，才允许用户继续点击；前端服务发现后端出现过载问题，可选择性拒绝服务，降低后端压力。

6、 使用缓冲区；缓冲区的使用，可以帮我们抵挡请求量的抖动，但缓冲区的使用同样也有很多技巧，并非越大越好。首先需要考虑内存，cpu等资源的开销，业务的模型是否需要这么大的缓冲区。例如缓冲区过大，处理完整个缓冲区，都需要几十秒，而前端等待超时则为几秒，那么每次处理缓冲区的内容，都是旧的，前端认为都是超时，服务完全不可用。另外是后端却又处理成功，会导致系统信息不对称，从而导致更为严重的问题，例如，在游戏中购买道具的场景，前端扣用户的钱，认为超时失败而不给用户发对应的物品，后端却又执行成功了，严重运营问题就此产生。

7、 做好监控，及时告警；例如当CPU达到80%时，当处理请求超出一定阈值时，及时告警，做好扩容，优化等其他准备。

当然依据业务模型的不同，还有很多预防的措施，依然是前述做到知底，才能够找出适合自身的方法。

5 过载保护

处理过载的方法有许多，适用于不同的业务场景，并无绝对的最优方案，合适的才是最好的，但能匹配上“合适”一词，是对系统整体和经验的一个考验。下面介绍一些常用的处理方案以及我们是如何做的：

Ø 请求量阈值控制

在系统部署上线之前，预估好系统的处理能力，限定最大同时能够处理的请求量、流量或者链接数。当请求量快接近于最大处理能力时，则告警，超过范围，则触发拒绝请求机制。由此可见对于阈值的设置是一个很关键的环节，阈值过高，依然可能导致过载，阈值过低，则又导致负载上不去。阈值的设置也会是一个不断调优的过程。该方法的优点和缺陷都很明显。

优点：识别和处理简单；

缺点：阈值的设定需要一定的经验，会有一定的难度，同时如果处理能力发生变化时，阈值就很难动态发生变化。

Ø 监控系统资源

服务器监控CPU，内存等资源的使用情况，设定阈值，超出阈值，则可以认为过载，从而触发拒绝请求机制。

优点：使用动态的资源数据，从相对根本的原因上识别过载，而无需过多关心具体的业务处理；

缺点：一是处理相对复杂；二是在某些场景下，资源数据的耗尽并不意味着出现过载的情况。例如服务开了较大的内存池，看起来内存资源耗尽了，实际上负载是足够的，又如现在都是多核服务器跑着多进程或者多线程的服务，单一的CPU耗尽也不能够代表服务就出现过载，但又可能产生过载，这就和具体业务有关；三是在某些场景下，出现过载的情况，也不一定会耗尽资源，例如当前所有的服务都在等待之中（可能是后端的回复或者其他），同样也不会对CPU、内存、io、网络等资源造成影响，但依然进入了过载。总体来说该方式适合的场景相对会简单点。

Ø 检测请求到达时间

依据请求处理的时延来判断是否过载。记录请求到达的时间戳，和处理请求结束的时间戳，得到请求到达自身服务器处理的时延，超出阈值，则可判定为超时失效，可以直接丢弃。使用独立模块读取系统缓冲区中数据，打上时间戳，存入消息缓冲区，在处理时，超过一定时延的请求，则拒绝处理，因为可以认为即使处理了也是无用的。从中可以看出时间戳很关键（为啥会单独提出这个问题，因为在后续的方案设计中，时间戳依然是解决过载问题的关键点，此处先卖个关子）。

A、 时间戳如果使用本地读取时刻调用系统的时间函数获取，就没有考虑消息包到达系统缓冲区的时间，因此是万万不能这样做。

B、 到可以通过ioctl调用SIOCGSTAMP的接口，获得时间戳，但这会加大系统开销，原因是每次recv完，都需要重新设置一下ioctl一次。并且不是线程安全的。

C、 使用socket选项SO_TIMESTAMP，通过带外数据获取到数据到达系统缓冲区的时间。

其处理方式如下图所示：

通过这种方式已经能够很好地解决负载问题，通过如此，并不需要设置过于繁琐的配置或者去识别过载的问题，目前此方法在SPP的框架中在使用。个人觉得可能存在的一些问题在于：

1、 完全使用时间戳过期的方式来判断，并不一定适合所有场景，假设处理耗时过长，而在缓冲区中也呆了较长时间，但请求量并不大，服务器未过载，在处理一些需要强写入的情况下，单靠该机制也会稍许欠妥。但如果加入一些协议上层机制，告诉该消息务必执行，也是可避免的。

2、 在出现过载的情况之下，很可能会导致整体的服务都会产生一个固定的延时，因为每次抛弃到可执行的范围内，至少会有一个超时时间范围内的延时，如果是较长的服务链的话，最前面的等待服务很可能会出现超时，因此其延时的设置相对也很困难，过小就太过灵敏，过大就会出现刚所述的问题。

3、 该方式只是管理了到达本服务器缓冲区之后的问题，并没有考虑整条服务链上的延时，很可能到达本服务器缓冲区时，就已经过期了，并且有可能这些数据在对端缓冲区已经产生了堆积，但到本端，并不会判断其过期。

4、 剩下还有一些内容可以做更多优化：另外SO_TIMESTAMP使用的是系统时间，会受系统时间修改的影响，但这个问题也不大，因为即使修改了，影响的只是本次系统缓冲区的数据。其他可以考虑业务的轻重程度，做按服务来丢弃。