CN104951357B - 并行用户态协议栈的管理方法和协议栈系统 - Google Patents
并行用户态协议栈的管理方法和协议栈系统 Download PDFInfo
- Publication number
- CN104951357B CN104951357B CN201410124239.XA CN201410124239A CN104951357B CN 104951357 B CN104951357 B CN 104951357B CN 201410124239 A CN201410124239 A CN 201410124239A CN 104951357 B CN104951357 B CN 104951357B
- Authority
- CN
- China
- Prior art keywords
- load
- protocol stack
- migrated
- supported
- pcb
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5083—Techniques for rebalancing the load in a distributed system
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
- Computer And Data Communications (AREA)
Abstract
本发明实施例提供了一种并行用户态协议栈的管理方法和协议栈系统，该方法包括：监控用户态协议栈中每个协议栈对应的实例的运行状态，一个该实例对应于该用户态协议栈中的一个协议栈；确定第一实例和第二实例，其中第一实例为运行状态异常的实例，第二实例具备迁入第一实例中至少一个待迁移负载的能力；根据第一实例中至少一个待迁移负载在该共享资源池中所对应的PCB在第二实例中重建该至少一个待迁移负载。本发明实施例中，根据异常实例中待迁移负载在共享资源池对应的PCB在具备迁入负载能力的实例中重建待迁移负载，能够克服协议栈共用一个分发模块带来的系统分发瓶颈，快速进行负载均衡和故障恢复，从而提高协议栈系统的性能。
Description
技术领域
本发明实施例涉及计算机领域，并且更具体地，涉及一种并行用户态协议栈的管理方法和协议栈系统。
背景技术
随着以太网技术的发展，10G、40G网卡的出现和普及，传统基于单核的协议栈已经无法跟上网卡速度的需要。此外，处理器体系结构已从强调高频单处理器发展到多核多处理器，计算机的并行处理能力越来越强。
现有技术中，数据包在多个协议栈实例之间分发时，采用公用的分发模块以连接作为粒度进行数据分发，分发模块可能成为系统的分发瓶颈，在负载均衡和负载故障恢复时需要维护大量的数据，消耗较多的系统时间，不利于负载的连接数据的快速恢复。在并行协议栈中如何快速进行负载均衡和故障恢复，是需要考虑解决的问题。
发明内容
本发明实施例提供一种并行用户态协议栈的管理方法和协议栈系统，能够克服协议栈共用一个分发模块带来的系统分发瓶颈，快速进行负载均衡和故障恢复，提高协议栈系统的性能。
第一方面，提供了一种并行用户态协议栈的管理方法，该方法包括：监控用户态协议栈中每个协议栈对应的实例的运行状态，一个该实例对应于该用户态协议栈中的一个协议栈；确定第一实例和第二实例，其中该第一实例为运行状态异常的实例，该第二实例具备迁入该第一实例中至少一个待迁移负载的能力，一个该待迁移负载在该第一实例所对应的协议栈内对应于一个协议控制块PCB，该PCB在共享资源池中对应于一个存储着该待迁移负载连接参数的PCB，该待迁移负载的连接参数能够用于重建该待迁移负载；根据该第一实例中至少一个待迁移负载在该共享资源池中所对应的PCB在该第二实例中重建该至少一个待迁移负载。
结合第一方面，在第一种可能的实现方式中，在该根据该第一实例中至少一个待迁移负载在共享资源池中所对应的协议控制块PCB在该第二实例中重建该至少一个待迁移负载之前，该方法还包括：确定该第一实例中的至少一个待迁移负载。
结合第一方面的第一种可能的实现方式，在第二种可能的实现方式中，该实例的运行状态包括实例的负载状态和存活状态，该监控用户态协议栈中每个协议栈对应的实例的运行状态包括：分别向该用户态协议栈中每个协议栈对应的实例发送心跳消息并监控该心跳消息响应时延，并监控该用户态协议栈中每个协议栈对应的实例在第一预定时间内的实例负载均值，以根据该心跳消息的响应时延和该实例负载均值确定该用户态协议栈中每个协议栈对应的实例的运行状态，其中，一条心跳消息对应于一个该实例；或者分别轮询该用户态协议栈中每个协议栈对应的实例的实例标识，并监控该用户态协议栈中每个协议栈对应的实例在第一预定时间内的实例负载均值，以根据该实例标识和该实例负载均值确定该用户态协议栈中每个协议栈对应的实例的运行状态，其中，该实例标识用于表示实例的存活状态，该实例标识存储于共享内存区域或共享文件，一个该实例标识对应于一个该实例。
结合第一方面的第二种可能的实现方式，在第三种可能的实现方式中，确定第一实例具体实现为：确定距离发送心跳消息时刻达到第二预定时间后仍然未反馈心跳响应的实例为该第一实例；或者，确定第一预定时间内实例标识表示僵死或失效状态的实例为该第一实例。
结合第一方面的第三种可能的实现方式，在第四种可能的实现方式中，确定第二实例具体实现为创建并确定新的实例为该第二实例；此时，根据该第一实例中至少一个待迁移负载在共享资源池中所对应的协议控制块PCB在该第二实例中重建该至少一个待迁移负载具体实现为：根据该至少一个待迁移负载之第一负载在共享资源池中所对应的第一PCB在该第二实例中实现该第一负载与该用户态协议栈的上层服务的对接，并将该第一负载在该第一实例中绑定的第一接收端扩展RSS队列重绑定到该第二实例的该第一负载中，其中，该至少一个待迁移负载包括该第一实例的所有负载。
结合第一方面的第四种可能的实现方式，在第五种可能的实现方式中，该方法还包括：终止该第一实例。
结合第一方面的第二种可能的实现方式，在第六种可能的实现方式中，确定第一实例具体实现为：确定第一预定时间内实例总负载均值大于第一预定阈值的实例为该第一实例。
结合第一方面的第六种可能的实现方式，在第七种可能的实现方式中，确定第二实例具体实现为：如果存在第一预定时间内实例总负载均值低于第二预定阈值的实例，则确定该第一预定时间内实例总负载均值低于第二预定阈值的一个或多个实例作为该第二实例，其中，迁入该第二实例的所有负载的负载值与该第二预定阈值之和小于该第一预定阈值。
结合第一方面的第七种可能的实现方式，在第八种可能的实现方式中，根据该第一实例中至少一个待迁移负载在共享资源池中所对应的协议控制块PCB在该第二实例中重建该至少一个待迁移负载具体实现为：根据该第一实例的至少一个待迁移负载之第二负载在该共享资源池中所对应的第二PCB，将该第二负载在该第一实例中绑定的第二RSS队列的绑定规则修改为绑定到该第二实例的第二负载中，以使得该第二实例实现从该第二RSS队列进行数据包接收及处理的过程；或者，根据该第一实例的至少一个待迁移负载之第二负载在该共享资源池中所对应的第二PCB，在该第一实例中解除该第二负载在该第一实例中绑定的第二RSS队列，并在该第二实例中将该第二RSS队列绑定到该第二负载中，以使得该第二实例实现从该第二RSS队列进行数据包接收及处理的过程。
结合第一方面的第七种可能的实现方式或第一方面的第八种可能的实现方式，在第九种可能的实现方式中，确定该第一实例中的至少一个待迁移负载具体实现为：确定该第一实例中的第三负载为该第一实例的待迁移负载，其中该第三负载在该第一实例中所绑定的第三RSS队列满足以下条件：当该第三RSS队列绑定到该第二实例时该第二实例的连接数、接收字节数、发送字节数3个参数中至少有2个参数不大于该第一实例的相应参数。
结合第一方面的第六种可能的实现方式，在第十种可能的实现方式中，确定第二实例具体实现为：如果不存在预定时间内实例总负载均值低于第二预定阈值的实例，则创建并确定新的实例为该第二实例。
结合第一方面的第十种可能的实现方式，在第十一种可能的实现方式中，根据该第一实例中至少一个待迁移负载在共享资源池中所对应的协议控制块PCB在该第二实例中重建该至少一个待迁移负载具体实现为：根据该第一实例的至少一个待迁移负载之第二负载在该共享资源池中所对应的第二PCB在该第二实例中实现该第二负载与该用户态协议栈的上层服务的对接以使得该第二实例实现与该第二负载对应的应用app的交互，并在该第一实例中解除该第二负载在该第一实例中绑定的第二RSS队列，在该第二实例中将该第二RSS队列绑定到该第二负载中，以使得该第二实例实现从该第二RSS队列进行数据包接收及处理的过程。
结合第一方面的第十种可能的实现方式或第一方面的第十一种可能的实现方式，在第十二种可能的实现方式中，确定该第一实例中的至少一个待迁移负载具体实现为：确定该第一实例中的第三负载为该第一实例的待迁移负载，该第三负载在该第一实例中所绑定的第三RSS队列满足以下条件：该第三RSS队列的连接数、接收字节数、发送字节数3个参数中都达到该第一实例的所有负载中对应参数的均值。
第二方面，提供了一种协议栈系统，该系统包括：监控单元，用于监控该协议栈系统的用户态协议栈中每个协议栈对应的运行状态，一个该实例对应于该用户态协议栈中的一个协议栈；确定单元，用于确定第一实例和第二实例，该第一实例为运行状态异常的实例，该第二实例具备迁入该第一实例中至少一个待迁移负载的能力，一个该待迁移负载在该第一实例所对应的协议栈内对应于一个协议控制块PCB，该PCB在该协议栈系统的共享资源池中对应于一个存储着该待迁移负载的连接参数的PCB，该待迁移负载的连接参数能够用于重建该待迁移负载；负载迁移单元，用于根据该第一实例中至少一个待迁移负载在该共享资源池中所对应的PCB在该第二实例中重建该至少一个待迁移负载。
结合第二方面，在第一种可能的实现方式中，该确定单元还用于确定该第一实例中的至少一个待迁移负载。
结合第二方面的第一种可能的实现方式，在第二种可能的实现方式中，该实例的运行状态包括实例的负载状态和存活状态，该监控单元具体用于：分别向该用户态协议栈中每个协议栈对应的实例发送心跳消息并监控该心跳消息响应时延，并监控该用户态协议栈中每个协议栈对应的实例在第一预定时间内的实例负载均值，以根据该心跳消息的响应时延和该实例负载均值确定该用户态协议栈中每个协议栈对应的实例的运行状态，其中，一条心跳消息对应于一个该实例；或者，分别轮询该用户态协议栈中每个协议栈对应的实例的实例标识，并监控该用户态协议栈中每个协议栈对应的实例在第一预定时间内的实例负载均值，以根据该实例标识和该实例负载均值确定该用户态协议栈中每个协议栈对应的实例的运行状态，其中，该实例标识用于表示实例的存活状态，该实例标识存储于共享内存区域或共享文件，一个该实例标识对应于一个该实例。
结合第二方面的第二种可能的实现方式，在第三种可能的实现方式中，在用于确定第一实例的过程中，该确定单元具体用于：确定距离发送心跳消息时刻达到第二预定时间后仍然未反馈心跳响应的实例为该第一实例；或者，确定第一预定时间内实例标识都表示僵死或失效状态的实例为该第一实例。
结合第二方面的第三种可能的实现方式，在第四种可能的实现方式中，在用于确定第二实例的过程中，该确定单元具体用于创建并确定新的实例为该第二实例；该负载迁移单元具体用于根据该至少一个待迁移负载之第一负载在共享资源池中所对应的第一PCB在该第二实例中实现该第一负载与该用户态协议栈的上层服务的对接，并将该第一负载在该第一实例中绑定的第一接收端扩展RSS队列重绑定到该第二实例的该第一负载中，其中，该至少一个待迁移负载包括该第一实例的所有负载。
结合第二方面的第四种可能的实现方式，在第五种可能的实现方式中，该系统还包括：实例停止单元，用于终止该第一实例。
结合第二方面的第二种可能的实现方式，在第六种可能的实现方式中，在用于确定第一实例的过程中，该确定单元具体用于：确定第一预定时间内实例总负载均值大于第一预定阈值的实例为该第一实例。
结合第二方面的第六种可能的实现方式，在第七种可能的实现方式中，在用于确定该第二实例的过程中，该确定单元具体用于：如果存在第一预定时间内实例总负载均值低于第二预定阈值的实例，则确定预定时间内实例总负载均值低于第二预定阈值的一个或多个实例作为该第二实例，其中，迁入该第二实例的所有负载的负载值与该第二预定阈值之和小于该第一预定阈值。
结合第二方面的第七种可能的实现方式，在第八种可能的实现方式中，该负载迁移单元具体用于：根据该第一实例的至少一个待迁移负载之第二负载在该共享资源池中所对应的第二PCB，将该第二负载在该第一实例中绑定的第二RSS队列的绑定规则修改为绑定到该第二实例的第二负载中，以使得该第二实例实现从该第二RSS队列进行数据包接收及处理的过程；或者，根据该第一实例的至少一个待迁移负载之第二负载在该共享资源池中所对应的第二PCB，在该第一实例中解除该第二负载在该第一实例中绑定的第二RSS队列，并在该第二实例中将该第二RSS队列绑定到该第二负载中，以使得该第二实例实现从该第二RSS队列进行数据包接收及处理的过程。
结合第二方面的第七种可能的实现方式或第二方面的第八种可能的实现方式，在第九种可能的实现方式中，在用于确定该第一实例中的至少一个待迁移负载的过程中，该确定单元具体用于：确定该第一实例中的第三负载为该第一实例的待迁移负载，该第三负载在该第一实例中所绑定的第三RSS队列满足以下条件：当该第三RSS队列绑定到该第二实例时该第二实例的连接数、接收字节数、发送字节数3个参数中至少有2个参数不大于该第一实例的相应参数。确定该第一实例中的至少一个待迁移负载具体实现为：确定该第一实例中的第三负载为该第一实例的待迁移负载，其中该第三负载在该第一实例中所绑定的第三RSS队列满足以下条件：当该第三RSS队列绑定到该第二实例时该第二实例的连接数、接收字节数、发送字节数3个参数中至少有2个参数不大于该第一实例的相应参数。
结合第二方面的第六种可能的实现方式，在第十种可能的实现方式中，在用于确定第二实例的过程中，该确定单元具体用于：如果不存在预定时间内实例总负载均值低于第二预定阈值的实例，则创建并确定新的实例为该第二实例。
结合第二方面的第十种可能的实现方式，在第十一种可能的实现方式中，该负载迁移单元具体用于：根据该第一实例的至少一个待迁移负载之第二负载在该共享资源池中所对应的第二PCB在该第二实例中实现该第二负载与该用户态协议栈的上层服务的对接以使得该第二实例实现与该第二负载对应的应用app的交互，并在该第一实例中解除该第二负载在该第一实例中绑定的第二RSS队列，在该第二实例中将该第二RSS队列绑定到该第二负载中，以使得该第二实例实现从该第二RSS队列进行数据包接收及处理的过程。根据该第一实例中至少一个待迁移负载在共享资源池中所对应的协议控制块PCB在该第二实例中重建该至少一个待迁移负载具体实现为：根据该第一实例的至少一个待迁移负载之第二负载在该共享资源池中所对应的第二PCB在该第二实例中实现该第二负载与该用户态协议栈的上层服务的对接以使得该第二实例实现与该第二负载对应的应用app的交互，并在该第一实例中解除该第二负载在该第一实例中绑定的第二RSS队列，在该第二实例中将该第二RSS队列绑定到该第二负载中，以使得该第二实例实现从该第二RSS队列进行数据包接收及处理的过程。
结合第二方面的第十种可能的实现方式或第二方面的第十一种可能的实现方式，在第十二种可能的实现方式中，在用于确定该第一实例中的至少一个待迁移负载的过程中，该确定单元具体用于：
确定该第一实例中的第三负载为该第一实例的待迁移负载，该第三负载在该第一实例中所绑定的第三RSS队列满足以下条件：该第三RSS队列的连接数、接收字节数、发送字节数3个参数中都达到该第一实例的所有负载中对应参数的均值。确定该第一实例中的至少一个待迁移负载具体实现为：确定该第一实例中的第三负载为该第一实例的待迁移负载，该第三负载在该第一实例中所绑定的第三RSS队列满足以下条件：该第三RSS队列的连接数、接收字节数、发送字节数3个参数中都达到该第一实例的所有负载中对应参数的均值。
基于以上技术方案，本发明实施例的并行用户态协议栈的管理方法和协议栈系统，通过根据异常实例中待迁移负载在共享资源池对应的PCB在具备迁入负载能力的实例中重建待迁移负载，能够克服协议栈共用一个分发模块带来的系统分发瓶颈，快速进行负载均衡和故障恢复，从而提高协议栈系统的性能。
附图说明
为了更清楚地说明本发明实施例的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本发明实施例并行用户态协议栈的管理方法流程图。
图2是本发明实施例并行用户态协议栈的另一管理方法流程图。
图3是本发明实施例故障线程恢复的流程示意图。
图4是本发明实施例线程负载均衡的流程示意图。
图5是本发明实施例线程负载均衡的另一流程示意图。
图6是本发明实施例协议栈系统的结构示意图。
图7是本发明实施例协议栈系统的另一结构示意图。
图8是本发明实施例协议栈系统的再一结构示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
为了方便理解本发明实施例，首先在此介绍本发明实施例描述中会引入的几个要素。
用户栈与内核栈：内核在创建进程/线程的时候，会为进程/线程创建相应的堆栈。每个进程/线程会有两个栈，一个用户栈，存在于用户空间，一个内核栈，存在于内核空间。当进程/线程在用户空间运行时，cpu堆栈指针寄存器里面的内容是用户堆栈地址，使用用户栈；当进程/线程在内核空间时，cpu堆栈指针寄存器里面的内容是内核栈空间地址，使用内核栈。
用户态协议栈：协议栈是操作系统的网络处理部分通常都会包含的模块。当与网络处理部分相关的进程/线程在用户空间运行时，cpu堆栈指针寄存器指向的协议栈即为用户态协议栈，本发明实施例中，用户态协议栈指在用户空间运行的所有协议栈的集合。
连接数：连接的数量。连接作为CPU负载的最终载体，具有直观意义。而且，接收端（Recv）接收到数据时需要进行连接查找，进而转入连接状态处理，因此考虑平衡各协议栈线程连接数量，对优化查找速度也很有意义。
接收字节数（Recv Bytes）：接收端扩展（Receive Side Scaling，RSS）本身主要是针对Recv端的分组发送（Packets dispatch），因此接收包的数据量很能反映对协议栈线程负载的影响。
发送字节数（Send Bytes）：发送分组（Send Packets）由于受到Recv数据与连接亲和性关系的影响，也影响协议栈处理相关连接的Send负载。
图1是本发明实施例并行协议栈的处理方法流程图，图1的方法由协议栈系统执行。
101，监控用户态协议栈中每个协议栈对应的实例的运行状态。
其中，一个该实例对应于该用户态协议栈中的一个协议栈。
应理解，本发明实施例中，实例可以是协议栈系统内的一个进程或一个线程。内核在创建进程/线程的时候，会为进程/线程创建相应的堆栈。每个进程/线程会有两个栈，一个用户栈，存在于用户空间，一个内核栈，存在于内核空间。
应理解，本发明实施例中，用户态协议栈用于表示存在于用户空间的所有协议栈。在用户态协议栈中，可包含一个或多个协议栈，每个协议栈与协议栈系统的一个实例形成一一对应的关系。
应理解，本发明实施例中，实例的运行状态包括实例的负载状态和存活状态。
应理解，实例的负载状态是指当前实例对系统资源的占用情况，通常情况下指该实例对CPU的资源利用率。
102，确定第一实例和第二实例。
其中，第一实例为运行状态异常的实例，第二实例该第二实例具备迁入该第一实例中至少一个待迁移负载的能力。
另外，一个该待迁移负载在该第一实例所对应的协议栈内对应于一个协议控制块PCB，该PCB在共享资源池中对应于一个存储着该待迁移负载的连接参数的PCB，该待迁移负载的连接参数能够用于重建该待迁移负载。
应理解，本发明实施例中，一个负载对应于一个PCB，一个负载在数据处理上等于一个PCB所对应的连接的数据处理量。
当一个实例被创建并初始化后，相应地会生成一个协议栈。如果实例内还不存在任何负载，则协议栈中也不会有PCB的信息。实例中有几个负载，其对应的协议栈中就会有相同个数的PCB。
另外，本发明实施例中，协议栈只是存储着PCB的一些基本信息，例如PCB标识等。共享资源池中存储着PCB的关键数据结构，主要包括连接结构体信息，该连接结构体信息对快速响应恢复连接具有关键作用。
应理解，运行状态异常的实例，一般可包括存活状态异常的实例或负载状态异常的实例。
存活状态异常的实例可包括僵死或失效的实例。
负载状态异常的实例，可包括负载高位运行的实例。在判断实例是否是负载高位运行时，可通过比较一段时间内实例总负载均值与预定阈值的关系来确定实例是否处于负载高位运行状态。
103，根据该第一实例中至少一个待迁移负载在该共享资源池中所对应的协议控制块PCB在该第二实例中重建该至少一个待迁移负载。
本发明实施例中，根据异常实例中待迁移负载在共享资源池对应的PCB在具备迁入负载能力的实例中重建待迁移负载，能够克服协议栈共用一个分发模块带来的系统分发瓶颈，快速进行负载均衡和故障恢复，从而提高协议栈系统的性能。
图2是本发明实施例并行用户态协议栈的另一管理方法流程图。可选地，如图2所示，在步骤103之前，该方法还可包括步骤104：确定该第一实例中的至少一个待迁移负载。
可选地，步骤101具体可实现为：分别向该用户态协议栈中每个协议栈对应的实例发送心跳消息并监控该心跳消息响应时延，并监控该用户态协议栈中每个协议栈对应的实例在第一预定时间内的实例负载均值，以根据该心跳消息的响应时延和该实例负载均值确定该用户态协议栈中每个协议栈对应的实例的运行状态，其中，一条心跳消息对应于一个该实例；或者，分别轮询该用户态协议栈中每个协议栈对应的实例的实例标识，并监控该用户态协议栈中每个协议栈对应的实例在第一预定时间内的实例负载均值，以根据该实例标识和该实例负载均值确定该用户态协议栈中每个协议栈对应的实例的运行状态，其中，该实例标识用于表示实例的存活状态，该实例标识存储于共享内存区域或共享文件，一个该实例标识对应于一个该实例。
可选地，作为一个实施例，步骤102中确定第一实例具体实现为：确定距离发送心跳消息时刻达到第二预定时间后仍然未反馈心跳响应的实例为该第一实例；或者，确定第一预定时间内实例标识表示僵死或失效状态的实例为该第一实例。
在本实施例中，步骤102确定第二实例的过程具体可实现为：创建并确定新的实例为该第二实例。此时，步骤103具体实现为：根据该至少一个待迁移负载之第一负载在共享资源池中所对应的第一PCB在该第二实例中实现该第一负载与该用户态协议栈的上层服务的对接，并将该第一负载在该第一实例中绑定的第一接收端扩展RSS队列重绑定到该第二实例的该第一负载中，其中，该至少一个待迁移负载包括该第一实例的所有负载。
可选地，作为另一实施例，步骤102中确定第一实例的过程具体实现为：确定第一预定时间内实例总负载均值大于第一预定阈值的实例为该第一实例。
可选地，在本实施例的一种具体实现方式中，步骤102中确定第二实例具体可实现为：如果存在第一预定时间内实例总负载均值低于第二预定阈值的实例，则确定预定时间内实例总负载均值低于第二预定阈值的一个或多个实例作为该第二实例，其中，迁入该第二实例的所有负载的负载值与该第二预定阈值之和小于该第一预定阈值。
进一步地，在当前的具体实现方式中，步骤103具体可实现为：根据该第一实例的至少一个待迁移负载之第二负载在该共享资源池中所对应的第二PCB，将该第二负载在该第一实例中绑定的第二RSS队列的绑定规则修改为绑定到该第二实例的第二负载中，以使得该第二实例实现从该第二RSS队列进行数据包接收及处理的过程；或者，根据该第一实例的至少一个待迁移负载之第二负载在该共享资源池中所对应的第二PCB，在该第一实例中解除该第二负载在该第一实例中绑定的第二RSS队列，并在该第二实例中将该第二RSS队列绑定到该第二负载中，以使得该第二实例实现从该第二RSS队列进行数据包接收及处理的过程。
另外，在当前的具体实现方式中，步骤104具体可实现为：确定该第一实例中的第三负载为该第一实例的待迁移负载，该第三负载在该第一实例中所绑定的第三RSS队列满足以下条件：当该第三RSS队列绑定到该第二实例时该第二实例的连接数、接收字节数、发送字节数3个参数中至少有2个参数不大于该第一实例的相应参数。
可选地，在本实施例的一种具体实现方式中，步骤102中确定第二实例具体可实现为：如果不存在预定时间内实例总负载均值低于第二预定阈值的实例，则创建并确定新的实例为该第二实例。
进一步地，在当前的具体实现方式中，步骤103具体可实现为：根据该第一实例的至少一个待迁移负载之第二负载在该共享资源池中所对应的第二PCB在该第二实例中实现该第二负载与该用户态协议栈的上层服务的对接以使得该第二实例实现与该第二负载对应的应用app的交互，并在该第一实例中解除该第二负载在该第一实例中绑定的第二RSS队列，在该第二实例中将该第二RSS队列绑定到该第二负载中，以使得该第二实例实现从该第二RSS队列进行数据包接收及处理的过程。
另外，在当前的具体实现方式下，步骤104具体可实现为：确定该第一实例中的第三负载为该第一实例的待迁移负载，该第三负载在该第一实例中所绑定的第三RSS队列满足以下条件：该第三RSS队列的连接数、接收字节数、发送字节数3个参数中都达到该第一实例的所有负载中对应参数的均值。
下面，将结合具体的实施例，对本发明实施例的方法作进一步的描述。下述具体实施例中，以协议栈线程作为用户态协议栈的实例进行描述。
图3是本发明实施例故障线程恢复的流程示意图。
在图3所示的场景中，用户态协议栈包含正在运行的应用所对应的多个协议栈。协议栈内协议控制块（Protocol Control Block，PCB）的关键数据结构存储于系统内存的共享资源池中。共享资源池在图3表现为协议控制块分配池（PCB Alloc），存储着PCB的关键数据结构，主要包括连接结构体信息，可用于快速响应恢复连接。协议栈中，PCB作为表示连接的主要数据结构，因此可以将其作为协议栈工作负载的主要衡量指标。如图3所示，用户态协议栈可包括协议栈stack1、stack2和stack3。其中，stack1所对应的线程包括2个负载，其对应的PCB分别为PCB1和PCB4；stack2所对应的线程包括1个负载，其对应的PCB为PCB3；stack3所对应的线程包括1个负载，其对应的PCB为PCB2。
S301，协议栈系统监控用户态协议栈中每个协议栈对应的实例的运行状态。
协议栈系统可通过多种方式监控用户态协议栈中每个协议栈对应的实例的运行状态。其中，实例的运行状态可包括实例的负载状态和存活状态。
实例的存活状态包括实例是否僵死（或失效）。对于僵死（或失效）的实例，协议栈系统应启动实例恢复流程。
实例的负载状态包括实例是处于高位运行、低位运行还是其它。其中，低位运行的实例，具备迁入负载的能力。对于高位运行的实例，应启动负载均衡流程，将实例内的部分负载迁出。
本发明实施例中，协议栈系统通过向每个协议栈对应的实例发送心跳消息并监控每个协议栈对应的实例对各自的心跳消息的响应时延以及监控第一预定时间内的实例负载均值来监控实例的运行状态。其中，一条心跳消息对应于一个该实例。
如图3所示，协议栈系统通过一个公共线程（Common Thread）对线程进行监控。本发明实施例中，Common Thread可包括一个看门狗（Watch Dog）模块，用于实现对线程的计时监控。Common Thread可通过Watch Dog可分别向用户态协议栈的每个协议栈对应的线程发送心跳（keep alive）消息。用户态协议栈的每个协议栈对应的线程接收到心跳消息后，可反馈心跳响应。此外，Common Thread还可监控线程的负载情况，可通过Watch Dog进行监控，或者通过访问线程的负载参数获取，其具体实现可参考现有技术，本发明实施例在此不再赘述。
Common Thread可监控线程的存活状态。Common Thread可向用户态协议栈的每个协议栈对应的线程发送心跳消息并监控每个协议栈对应的对各自的心跳消息的响应时延。如果Common Thread在向线程发送心跳消息后的第二预定时间内接收到线程反馈的心跳响应，则Common Thread可认为该线程的存活状态为有效状态（或活动状态）；反之，如果Common Thread在向线程发送心跳消息后的第二预定时间内没有接收到线程反馈的心跳响应，则Common Thread可认为该线程的存活状态为僵死或失效状态。其中，该第二预定时间由协议栈系统确定。
另外，Common Thread还可监控线程的负载状态。应理解，为避免瞬时峰值及瞬时低值导致对负载状态的误判，可取一段时间内的线程负载均值作为线程负载状态的判断标准。Common Thread可确定第一预定时间内线程的总负载均值大于第一预定阈值的实例为高位运行的线程，Common Thread还可确定第一预定时间内线程总负载均值低于第二预定阈值的线程为低位运行线程。其中，第一预定时间、第一预定阈值、第二预定阈值均可由协议栈系统确定。
S302，协议栈系统指示创建新的实例作为第二实例。
当协议栈系统监控到僵死（或失效）的实例后，可创建一个新的实例，并确定该新建实例为第二实例，用于恢复僵死（或失效）的实例。
不妨假设图3中stack1所对应的线程在第二预定时间内没有反馈心跳响应，则此时Common Thread可确认stack1所对应的线程为僵死（或失效）的线程。
此时，Common Thread可新建一个线程，并在用户态协议栈中建立相应的栈元素stack4，完成线程的初始化工作。线程初始化的具体流程可参考现有技术，本发明实施例在此不再赘述。
S303，第二实例绑定RSS队列。
第二实例可获取第一实例中的所有负载对应的PCB的标识信息，从共享资源池中获取对应的PCB信息，并基于共享资源池中对应的PCB信息，将原先第一实例所绑定的RSS队列绑定到第二实例中。
在图3中，共享资源池为协议控制块分配池（PCB Alloc），存储着协议栈的实例中所有负载的PCB。PCB中包括连接的主要数据结构。
根据第一实例中的负载对应的PCB
第二实例可根据第一实例中的负载对应的PCB，获取第一实例中的负载所绑定的RSS队列，并将第一实例中的负载所绑定的RSS队列绑定到第二实例中。
如图3所示，stack4所对应的线程从stack1或stack1所对应的线程中获取负载所对应的协议控制块PCB1和PCB4，并从PCB1和PCB4中获取绑定到stack1所对应的线程的的RSS队列信息，并将该RSS队列重绑定到stack4所对应的线程中。
S304，第二实例与用户态协议栈的上层服务对接。
第二实例还可根据第一实例中的负载对应的PCB建立与用户态协议栈的上层服务的对接。
具体地，如图3所示，stack4所对应的线程可根据PCB Alloc中的PCB1和PCB4，重新绑定stack4所对应的线程与上层套接字应用接口层（SocketAPI）中的消息盒子（msg box），完成线程与协议栈上层服务的重新对接，从而恢复线程与应用（app）的交互。
另外，应理解，步骤S303和步骤S304之间不存在先后的关系，新建实例在完成初始化之后，可先绑定RSS队列，也可先完成与协议栈上层服务的重新对接，本发明实施例在此不作限制。
S305，协议栈系统销毁第一实例。
在第二实例完成对第一实例的恢复过程后，可销毁第一实例。
基于系统的稳定性考虑，在恢复过程完成后，原有僵死（或失效）的实例需要被销毁。
如图3所示，当stack1所对应的线程的负载在stack4所对应的线程中重建以后，stack1所对应的线程应被销毁，其对应的栈stack1也会被释放。
本发明实施例中，协议栈系统基于僵死（或失效）的实例的负载在共享资源池的PCB在新建立的实例中重建负载，可以对失效协议栈负责的连接信息快速接管，快速恢复，下至网卡信息，上至与应用（app）交互的信息，都能快速恢复，损失很小。
另外，本发明实施例中，协议控制块信息，保持一种全局共享的存储机制，对于恢复处理中的连接非常有用，尤其对传输控制协议(Transmission Control Protocol TCP)监听（Listen）、UDP连接、超文本传输协议（HypertextTransfer Protocol，HTTP）1.1协议中的长连接等对短暂中断不敏感的连接，可以达到无损恢复的目的；而对于其他类的TCP连接等，可能由于中断导致超时断开或者TCP窗口进入慢速启动的模式，但这些都是协议栈本身可以正确处理恢复到正确的状态，对系统整体状态无影响。
另外，在图3的实施例中，也可从现有低位运行的线程中选择一个或多个作为第二实例，并在第二实例中重建第一实例的负载，然后再执行销毁第一实例的操作。
图4是本发明实施例线程负载均衡的流程示意图。
在图4所示的场景中，用户态协议栈包含正在运行的应用所对应的多个协议栈。协议栈内协议控制块（Protocol Control Block，PCB）的关键数据结构存储于系统内存的共享资源池中。共享资源池在图4表现为协议控制块分配池（PCB Alloc），存储着PCB的关键数据结构，主要包括连接结构体信息，可用于快速响应恢复连接。协议栈中，PCB作为表示连接的主要数据结构，因此可以将其作为协议栈工作负载的主要衡量指标。如图4所示，用户态协议栈可包括协议栈stack1、stack2、stack3、stack4。其中，stack1所对应的线程内存在2个负载，其对应的PCB分别为PCB1和PCB4；stack2所对应的线程内存在1个负载，其对应的PCB为PCB3；stack3所对应的线程内存在1个负载，其对应的PCB为PCB2；stack4所对应的线程内存在1个负载，其对应的PCB为PCB5。
S401，协议栈系统监控用户态协议栈中每个协议栈对应的实例的运行状态。
步骤S401与图3的步骤S301类似，本发明实施例在此不再赘述。
S402，协议栈系统分别向第一实例和第二实例发送指示消息。
协议栈系统根据监控的结果，可确定需要迁出负载的实例和能够迁入负载的实例。
如果用户态协议栈的多个实例中存在至少一个高位运行的实例，则可确定该至少一个高位运行的实例为第一实例。
同时，如果用户态协议栈的多个实例中存在至少一个低位运行的实例，则可确定该至少一个低位运行的实例中的一个或多个实例为第二实例。
如图4所示，不妨假设步骤S401中，协议栈系统通过公共线程（Common Thread）监控到stack1所对应的线程高位运行，stack4和stack2所对应的线程低位运行，也就是说stack1所对应的线程的负载需要迁出，stack4和stack2所对应的线程具备迁入负载的能力。
此时，Common Thread可确定stack1所对应的线程为第一实例，并确定stack4或stack2所对应的线程为第二实例，或者确定stack4和stack2所对应的线程都为第二实例。由于stack1所对应的线程只有PCB1和PCB4对应的两个负载，显然只要迁出一个负载即可，只需要一个第二实例。本发明实施例中，选中stack4所对应的线程为第二实例。
首先，Common Thread可向stack1所对应的线程发送第一指示（notify）消息，指示stack1所对应的线程确定迁出负载并解除对迁出负载所对应的RSS队列的绑定。
stack1所对应的线程接收到第一指示消息后，首先要确定待迁出负载。
要达到负载均衡，必然要慎重选择重新绑定的问题：对迁出负载的线程达到了有效减负的目的；对迁入的线程，不能过分导致单方面负载很高，因此需要在迁入和迁出线程间达到1个平衡。
上层，可以进行各队列对RSS队列负载的影响进行排序，进而更好的进行负载均摊。并综合考虑发送和接收等各方面影响。
TCP/UDP连接，以及要处理的其他类型协议，有各自的特点，每个连接的双向负载是变化的，生存时间也是不确定的，非常精细的划分和配比对系统的开销很大。
因此，综合考虑，希望利用最小的开销，达到最好的负载均衡效果，采用以下几个维度来衡量重新绑定的选取过程：连接数，接收字节数（Recv Bytes）和发送字节数（SendBytes）。
连接数：连接的数量，连接作为CPU负载的最终载体，具有直观意义；而且，Recv到数据时需要进行连接查找，进而转入连接状态处理，因此考虑平衡各协议栈线程连接数量，对优化查找速度也很有意义。
Recv Bytes：rss本身主要是针对Recv端的数据包调度（Packets Dispatch），因此接收包的数据量很能反映对协议栈线程负载的影响。
Send Bytes：发送数据包（Send Packets）由于受到Recv端数据与连接亲和性关系的影响，也会影响协议栈处理相关连接的Send负载。
本发明实施例中，负载均衡在原有线程间进行。因此，迁出的负载应满足：迁移前负载轻的线程（第二实例），迁移后的负载总值不应高于迁出线程（第一实例）未迁移前的负载总值；迁移前负载轻的线程（第二实例），迁移后绑定的所有RSS队列的连接数，RecvBytes和Send Bytes3个参数中至少有2个参数的值不应超出迁出线程（第一实例）未迁移前的对应参数值。
不妨假设stack1所对应的线程中PCB4所对应的负载满足迁出负载的判定条件，则第一实例可将确定PCB4所对应的负载为待迁出负载。
stack1所对应的线程可将PCB4的标识或PCB4所对应的负载的标识反馈给CommonThread，并执行步骤S403。
另外，Common Thread在接收到stack1所对应的线程的反馈后，可向stack4所对应的线程发送第二指示消息，指示stack4所对应的线程准备迁入负载。该第二指示消息中可携带待迁入负载的信息。
S403，第一实例对待迁移负载的队列解除绑定。
如图4所示，stack1所对应的线程在确定PCB4对应的负载为待迁出负载后，可解绑定PCB4所对应的负载在stack1所对应的线程所绑定的RSS队列。
S404，第二实例绑定待迁移负载的队列。
第二实例在收到第二指示消息后，可根据待迁移负载在共享资源池中的PCB，将待迁移负载在第一实例所绑定的RSS队列绑定到第二实例中，并将接收从该RSS队列进行接收数据包的过程，以及由此产生的数据包处理过程。
本发明实施例中，stack4所对应的线程可根据第二指示消息中PCB4的标识信息或PCB4所对应的负载的标识信息，从协议控制块分配池PCB Alloc中获取PCB4的信息并基于PCB4的信息在stack4所对应的线程重建负载，并将PCB4所对应的负载在stack1所对应的线程中绑定的RSS队列重绑定到stack4所对应的线程PCB4对应的负载上。
本发明实施例中，通过待迁移负载在共享资源池的PCB在原有实例间进行负载均衡，避免了负载均衡时不必要的数据传输，提高了负载均衡的效率。
另外，本发明实施例中，还可以直接修改待迁移负载所绑定的RSS队列的绑定规则，直接将迁移负载所绑定的RSS队列的绑定规则修改为绑定到第二实例对应的负载上，避免第一实例解绑定和第二实例绑定的操作。监控实例状态和确定高位运行实例的待迁移负载的步骤可参考本发明实施例的相关过程，本发明实施例在此不再赘述。
图5是本发明实施例线程负载均衡的另一流程示意图。
在图5所示的场景中，用户态协议栈包含正在运行的应用所对应的多个协议栈。协议栈内协议控制块（Protocol Control Block，PCB）的关键数据结构存储于系统内存的共享资源池中。共享资源池在图5表现为协议控制块分配池（PCB Alloc），存储着PCB的关键数据结构，主要包括连接结构体信息，可用于快速响应恢复连接。协议栈中，PCB作为表示连接的主要数据结构，因此可以将其作为协议栈工作负载的主要衡量指标。如图5所示，用户态协议栈可包括协议栈stack1、stack2和stack3。其中，stack1所对应的线程包括2个负载，其对应的PCB分别为PCB1和PCB4；stack2所对应的线程包括1个负载，其对应的PCB为PCB3；stack3所对应的线程包括1个负载，其对应的PCB为PCB2。
S501，协议栈系统监控用户态协议栈中每个协议栈对应的实例的运行状态。
步骤S501与图3的步骤S301类似，本发明实施例在此不再赘述。
S502，协议栈系统向第一实例发送指示消息。
协议栈系统根据监控的结果，可确定需要迁出负载的实例和能够迁入负载的实例。
如果用户态协议栈中每个协议栈对应的实例中存在至少一个高位运行的实例，则可确定该至少一个高位运行的实例为第一实例。
如图5所示，不妨假设步骤S501中，协议栈系统通过公共线程（Common Thread）监控到stack1所对应的线程高位运行，stack2和stack3所对应的线程不具备迁入负载的能力。
首先，Common Thread可向stack1所对应的线程发送第一指示（notify）消息，指示stack1所对应的线程确定迁出负载并解除对迁出负载所绑定的RSS队列的绑定。
stack1所对应的线程接收到第一指示消息后，首先要确定待迁出负载。
类似的，为了利用最小的开销，达到最好的负载均衡效果，可采用以下几个维度来衡量重新绑定的选取过程：连接数，Recv Bytes和Send Bytes三个参数。
本发明实施例中，负载均衡在从原有线程迁入新建线程。在挑选迁出负载时，应选择连接数，Recv Bytes和Send Bytes三个参数整体上达到均值的RSS队列所对应的负载进行迁移。或者，可以分别对连接数，Recv Bytes和Send Bytes三个参数设定三个预定参数阈值，选择三个参数整体上达到对应的预定参数阈值的负载作为待迁出负载。
不妨假设PCB4对应的负载所绑定的RSS满足迁出负载的判定条件，则stack1所对应的线程可将PCB4的标识或PCB4所对应的负载的标识反馈给Common Thread，并解绑定PCB4所对应的负载在stack1所对应的线程所绑定的RSS队列。
stack1所对应的线程确定待迁移负载后，可向Common Thread反馈待迁移负载的信息，例如待迁移负载的标识，或者待迁移负载对应的PCB的标识，等等，并执行步骤S504。
同时，如果用户态协议栈的多个实例中不存在至少一个低位运行的实例，则协议栈系统可指示创建新的实例作为第二实例，即执行步骤S503。
S503，协议栈系统指示创建新的实例作为第二实例。
当协议栈系统监控到高位运行的实例且现有实例中不存在低位运行的实例，协议栈系统可创建一个新的实例，并确定该新建实例为第二实例，用于迁入负载以实现负载均衡。
如图5所示，协议栈系统通过Common Thread发送一条新建线程（new stack）的指令，创建新的线程，即stack4所对应的线程，并确定stack4所对应的线程为第二实例，同时完成对新建线程的初始化操作。线程初始化的具体流程可参考现有技术，本发明实施例在此不再赘述。
S504，第一实例对待迁移负载的队列解除绑定。
如图5所示，stack1所对应的线程在确定PCB4对应的负载为待迁出负载后，可解绑定PCB4所对应的负载在stack1所对应的线程所绑定的RSS队列。
S505，第二实例绑定待迁移负载的队列。
stack4所对应的线程可根据协议控制块分配池（PCB Alloc）中的PCB4的信息，将PCB4所对应的负载在stack1所对应的线程中所绑定的RSS队列绑定到第二实例中。此时，stack4所对应的线程将接收从这个队列进行接收数据包的过程，以及由此产生的数据包处理过程。
S506，第二实例与协议栈上层服务实现对接。
第二实例为新建实例，还需完成与用户态协议栈的上层服务的对接，才能实现与负载对应的应用的交互。
本发明实施例中，stack4所对应的线程可根据协议控制块分配池中的PCB4的信息，重新绑定stack4所对应的线程与上层套接字应用接口层（Socket API）中的消息盒子（msg box），完成线程与协议栈上层服务的重新对接，从而恢复线程与应用（app）的交互。
应理解，步骤S505和步骤S506之间不存在时间上的先后关系。
本发明实施例中，通过待迁移负载在共享资源池的PCB在新建实例迁入高负载实例的负载，从而实现负载均衡，避免了负载均衡时不必要的数据传输，提高了负载均衡的效率。
除了上述图3-图5所示实施例的监控实例运行状态的方法外，协议栈系统还可通过其它方式来监控实例的运行状态。本发明的另一种监控方式，协议栈系统可用实例标识来表征实例的存活状态，并通过监控实例的实例标识监控实例的存活状态，通过预定时间内实例的总负载均值来监控实例的负载状态，从而实现对实例的运行状态的监控。其中，每个实例标识对应于协议栈的一个实例，该实例标识可存储于内存共享空间，或者是共享文件，协议栈系统可通过轮询计时器轮询实例的实例标识。协议栈系统可用轮询计时器代替图3-图5中的Watch Dog，通过轮询计时器轮询线程的存活标识以实现对线程的存活状态的监控。其中，线程的存活标识可存储于内存共享空间，或者是共享文件，并与线程一一对应。另外，对实例的负载监控及实例负载迁移、负载重建的具体实现可参考图3-图5所示的实施例，本发明实施例在此不再赘述。当然，还可能存在其它监控实例运行状态的方式，本发明实施例对此不作限制。
图6是本发明实施例协议栈系统600的结构示意图。协议栈系统600可包括监控单元601、确定单元602和负载迁移单元603。
监控单元601，用于监控用户态协议栈中每个协议栈对应的实例的运行状态。
其中，一个该实例对应于该用户态协议栈中的一个协议栈。
应理解，本发明实施例中，实例可以是协议栈系统内的一个进程或一个线程。内核在创建进程/线程的时候，会为进程/线程创建相应的堆栈。每个进程/线程会有两个栈，一个用户栈，存在于用户空间，一个内核栈，存在于内核空间。
应理解，本发明实施例中，用户态协议栈用于表示存在于用户空间的所有协议栈。在用户态协议栈中，可包含一个或多个协议栈，每个协议栈与协议栈系统的一个实例形成一一对应的关系。
应理解，本发明实施例中，实例的运行状态包括实例的负载状态和存活状态。
确定单元602，用于确定第一实例和第二实例。
其中，第一实例为运行状态异常的实例，第二实例该第二实例具备迁入该第一实例中至少一个待迁移负载的能力。
另外，一个该待迁移负载在该第一实例所对应的协议栈内对应于一个协议控制块PCB，该PCB在共享资源池中对应于一个存储着该待迁移负载的连接参数的PCB，该待迁移负载的连接参数能够用于重建该待迁移负载。
应理解，本发明实施例中，一个负载对应于一个PCB，一个负载在数据处理上等于一个PCB所对应的连接的数据处理量。
当一个实例被创建并初始化后，相应地会生成一个协议栈。如果实例内还不存在任何负载，则协议栈中也不会有PCB的信息。实例中有几个负载，其对应的协议栈中就会有相同个数的PCB。
另外，本发明实施例中，协议栈只是存储着PCB的一些基本信息，例如PCB标识等。共享资源池中存储着PCB的关键数据结构，主要包括连接结构体信息，该连接结构体信息对快速响应恢复连接具有关键作用。
应理解，运行状态异常的实例，一般可包括存活状态异常的实例或负载状态异常的实例。
存活状态异常的实例可包括僵死或失效的实例。
负载状态异常的实例，可包括负载高位运行的实例。在判断实例是否是负载高位运行时，可通过比较一段时间内实例总负载均值与预定阈值的关系来确定实例是否处于负载高位运行状态。
负载迁移单元603，用于根据该第一实例中至少一个待迁移负载在共享资源池中所对应的协议控制块PCB在该第二实例中重建该至少一个待迁移负载。
本发明实施例中，协议栈系统600根据异常实例中待迁移负载在共享资源池对应的PCB在具备迁入负载能力的实例中重建待迁移负载，能够克服协议栈共用一个分发模块带来的系统分发瓶颈，快速进行负载均衡和故障恢复，从而提高协议栈系统的性能。
可选地，确定单元602还可用于确定该第一实例中的至少一个待迁移负载。
可选地，监控单元601具体用于：分别向该用户态协议栈中每个协议栈对应的实例发送心跳消息并监控该心跳消息响应时延，并监控该用户态协议栈中每个协议栈对应的实例在第一预定时间内的实例负载均值，以根据该心跳消息的响应时延和该实例负载均值确定该用户态协议栈中每个协议栈对应的实例的运行状态，其中，一条心跳消息对应于一个该实例；或者，分别轮询该用户态协议栈中每个协议栈对应的实例的实例标识，并监控该用户态协议栈中每个协议栈对应的实例在第一预定时间内的实例负载均值，以根据该实例标识和该实例负载均值确定该用户态协议栈中每个协议栈对应的实例的运行状态，其中，该实例标识用于表示实例的存活状态，该实例标识存储于共享内存区域或共享文件，一个该实例标识对应于一个该实例。
可选地，作为一个实施例，在用于确定第一实例的过程中，确定单元602具体用于：确定距离发送心跳消息时刻达到第二预定时间后仍然未反馈心跳响应的实例为该第一实例；或者，确定第一预定时间内实例标识都表示僵死或失效状态的实例为该第一实例。
本实施例中，在用于确定第二实例的过程中，确定单元602具体用于创建并确定新的实例为该第二实例；负载迁移单元603具体用于根据该至少一个待迁移负载之第一负载在共享资源池中所对应的第一PCB在该第二实例中实现该第一负载与该用户态协议栈的上层服务的对接，并将该第一负载在该第一实例中绑定的第一接收端扩展RSS队列重绑定到该第二实例的该第一负载中，其中，该至少一个待迁移负载包括该第一实例的所有负载。
图7是本发明实施例协议栈系统600的另一结构示意图。如图7所示，协议栈系统600还可包括：实例停止单元604，用于终止该第一实例。
可选地，作为另一实施例，在用于确定第一实例的过程中，确定单元602具体用于：确定第一预定时间内实例总负载均值大于第一预定阈值的实例为该第一实例。
可选地，在本具体实现方式的一种场景中，在用于确定第二实例的过程中，确定单元602具体用于：如果存在第一预定时间内实例总负载均值低于第二预定阈值的实例，则确定预定时间内实例总负载均值低于第二预定阈值的一个或多个实例作为该第二实例，其中，迁入该第二实例的所有负载的负载值与该第二预定阈值之和小于该第一预定阈值。
进一步地，在当前的具体实现方式中，负载迁移单元603具体用于：根据该第一实例的至少一个待迁移负载之第二负载在该共享资源池中所对应的第二PCB，将该第二负载在该第一实例中绑定的第二RSS队列的绑定规则修改为绑定到该第二实例的第二负载中，以使得该第二实例实现从该第二RSS队列进行数据包接收及处理的过程；或者，根据该第一实例的至少一个待迁移负载之第二负载在该共享资源池中所对应的第二PCB，在该第一实例中解除该第二负载在该第一实例中绑定的第二RSS队列，并在该第二实例中将该第二RSS队列绑定到该第二负载中，以使得该第二实例实现从该第二RSS队列进行数据包接收及处理的过程。
另外，在当前的具体实现方式中，在用于确定该第一实例中的至少一个待迁移负载的过程中，确定单元602具体用于：确定该第一实例中的第三负载为该第一实例的待迁移负载，该第三负载在该第一实例中所绑定的第三RSS队列满足以下条件：当该第三RSS队列绑定到该第二实例时该第二实例的连接数、接收字节数、发送字节数3个参数中至少有2个参数不大于该第一实例的相应参数。
可选地，在本实施例的一种具体实现方式中，在用于确定第二实例的过程中，确定单元602具体用于：如果不存在预定时间内实例总负载均值低于第二预定阈值的实例，则创建并确定新的实例为该第二实例。
进一步地，在当前的具体实现方式中，负载迁移单元603具体用于：根据该第一实例的至少一个待迁移负载之第二负载在该共享资源池中所对应的第二PCB在该第二实例中实现该第二负载与该用户态协议栈的上层服务的对接以使得该第二实例实现与该第二负载对应的应用app的交互，并在该第一实例中解除该第二负载在该第一实例中绑定的第二RSS队列，在该第二实例中将该第二RSS队列绑定到该第二负载中，以使得该第二实例实现从该第二RSS队列进行数据包接收及处理的过程。
另外，在当前的具体实现方式中，在用于确定该第一实例中的至少一个待迁移负载的过程中，确定单元602具体用于：确定该第一实例中的第三负载为该第一实例的待迁移负载，该第三负载在该第一实例中所绑定的第三RSS队列满足以下条件：该第三RSS队列的连接数、接收字节数、发送字节数3个参数中都达到该第一实例的所有负载中对应参数的均值。
协议栈系统600还可执行图1、图2的方法，并能实现协议栈系统在上述如图1至图5所示的实施例的功能，具体实现可参考图1至图5所示实施例，本发明实施例在此不再赘述。
图8是本发明实施例协议栈系统800的结构示意图。协议栈系统可包括IO通道801、处理器802和存储器803。
IO通道801、处理器802和存储器803通过总线804系统相互连接；总线804可以是ISA总线、PCI总线或EISA总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图8中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
存储器803，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器803可能包含高速RAM存储器，也可能还包括非易失性存储器（non-volatile memory），例如至少一个磁盘存储器。
处理器802执行存储器803所存放的程序，用于监控用户态协议栈中每个协议栈对应的实例的运行状态，确定第一实例和第二实例，并根据该第一实例中至少一个待迁移负载在存储器803的共享资源池中所对应的协议控制块PCB在该第二实例中重建该至少一个待迁移负载。其中，一个该实例对应于该用户态协议栈中的一个协议栈，该第一实例为运行状态异常的实例，该第二实例具备迁入该第一实例中至少一个待迁移负载的能力，一个该待迁移负载在该第一实例所对应的协议栈内对应于一个协议控制块PCB，该PCB在共享资源池中对应于一个存储着该待迁移负载的连接参数的PCB，该待迁移负载的连接参数能够用于重建该待迁移负载。
应理解，本发明实施例中，用户态协议栈用于表示存在于用户空间的所有协议栈。在用户态协议栈中，可包含一个或多个协议栈，每个协议栈与协议栈系统的一个实例形成一一对应的关系。
应理解，本发明实施例中，一个负载对应于一个PCB，一个负载在数据处理上等于一个PCB所对应的连接的数据处理量。
存储器803可以包括只读存储器和随机存取存储器，并向处理器802提供指令和数据。存储器803的一部分还可以包括非易失性随机存取存储器（NVRAM）。
上述如本发明图1至图5任一实施例揭示的方法可以应用于处理器802中，或者由处理器802实现。处理器802可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器802中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器802可以是通用处理器，包括中央处理器（Central Processing Unit，简称CPU）、网络处理器（Network Processor，简称NP）等；还可以是数字信号处理器（DSP）、专用集成电路（ASIC）、现成可编程门阵列（FPGA）或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本发明实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器803，处理器802读取存储器803中的信息，结合其硬件完成上述方法的步骤。
可选地，处理器802还用于确定该第一实例中的至少一个待迁移负载。
可选地，在用于监控用户态协议栈中多个实例的运行状态的过程中，处理器802具体用于：分别向该用户态协议栈中每个协议栈对应的实例发送心跳消息并监控该心跳消息响应时延，并监控该用户态协议栈中每个协议栈对应的实例在第一预定时间内的实例负载均值，以根据该心跳消息的响应时延和该实例负载均值确定该用户态协议栈中每个协议栈对应的实例的运行状态，其中，一条心跳消息对应于一个该实例；或者，分别轮询该用户态协议栈中每个协议栈对应的实例的实例标识，并监控该用户态协议栈中每个协议栈对应的实例在第一预定时间内的实例负载均值，以根据该实例标识和该实例负载均值确定该用户态协议栈中每个协议栈对应的实例的运行状态，其中，该实例标识用于表示实例的存活状态，该实例标识存储于共享内存区域或共享文件，一个该实例标识对应于一个该实例。
可选地，作为一个实施例，在用于确定第一实例的过程中，处理器802具体用于：确定距离发送心跳消息时刻达到第二预定时间后仍然未反馈心跳响应的实例为该第一实例；或者，确定第一预定时间内实例标识都表示僵死或失效状态的实例为该第一实例。
本实施例中，在用于确定第二实例的过程中，处理器802具体用于创建并确定新的实例为该第二实例；在用于根据该第一实例中至少一个待迁移负载在存储器803的共享资源池中所对应的协议控制块PCB在该第二实例中重建该至少一个待迁移负载的过程中，处理器802具体用于根据该至少一个待迁移负载之第一负载在共享资源池中所对应的第一PCB在该第二实例中实现该第一负载与该用户态协议栈的上层服务的对接，并将该第一负载在该第一实例中绑定的第一接收端扩展RSS队列重绑定到该第二实例的该第一负载中，其中，该至少一个待迁移负载包括该第一实例的所有负载。此时，处理器802还可用于终止该第一实例。
可选地，作为另一实施例，在用于确定第一实例的过程中，处理器802具体用于：确定第一预定时间内实例总负载均值大于第一预定阈值的实例为该第一实例。
可选地，在本具体实现方式的一种场景中，在用于确定第二实例的过程中，处理器802具体用于：如果存在第一预定时间内实例总负载均值低于第二预定阈值的实例，则确定预定时间内实例总负载均值低于第二预定阈值的一个或多个实例作为该第二实例，其中，迁入该第二实例的所有负载的负载值与该第二预定阈值之和小于该第一预定阈值。
进一步地，在当前的具体实现方式下，在用于根据该第一实例中至少一个待迁移负载在存储器803的共享资源池中所对应的协议控制块PCB在该第二实例中重建该至少一个待迁移负载的过程中，处理器802具体用于：根据该第一实例的至少一个待迁移负载之第二负载在该共享资源池中所对应的第二PCB，将该第二负载在该第一实例中绑定的第二RSS队列的绑定规则修改为绑定到该第二实例的第二负载中，以使得该第二实例实现从该第二RSS队列进行数据包接收及处理的过程；或者，根据该第一实例的至少一个待迁移负载之第二负载在该共享资源池中所对应的第二PCB，在该第一实例中解除该第二负载在该第一实例中绑定的第二RSS队列，并在该第二实例中将该第二RSS队列绑定到该第二负载中，以使得该第二实例实现从该第二RSS队列进行数据包接收及处理的过程。
另外，在当前的具体实现方式下，在用于确定该第一实例中的至少一个待迁移负载的过程中，处理器802具体用于：确定该第一实例中的第三负载为该第一实例的待迁移负载，该第三负载在该第一实例中所绑定的第三RSS队列满足以下条件：当该第三RSS队列绑定到该第二实例时该第二实例的连接数、接收字节数、发送字节数3个参数中至少有2个参数不大于该第一实例的相应参数。
可选地，在本实施例的一种具体实现方式中，在用于确定第二实例的过程中，处理器802具体用于：如果不存在预定时间内实例总负载均值低于第二预定阈值的实例，则创建并确定新的实例为该第二实例。
进一步地，在当前的具体实现方式下，在用于根据该第一实例中至少一个待迁移负载在存储器803的共享资源池中所对应的协议控制块PCB在该第二实例中重建该至少一个待迁移负载的过程中，处理器802具体用于：根据该第一实例的至少一个待迁移负载之第二负载在该共享资源池中所对应的第二PCB在该第二实例中实现该第二负载与该用户态协议栈的上层服务的对接以使得该第二实例实现与该第二负载对应的应用app的交互，并在该第一实例中解除该第二负载在该第一实例中绑定的第二RSS队列，在该第二实例中将该第二RSS队列绑定到该第二负载中，以使得该第二实例实现从该第二RSS队列进行数据包接收及处理的过程。
另外，在当前的具体实现方式下，在用于确定该第一实例中的至少一个待迁移负载的过程中，处理器802具体用于：确定该第一实例中的第三负载为该第一实例的待迁移负载，该第三负载在该第一实例中所绑定的第三RSS队列满足以下条件：该第三RSS队列的连接数、接收字节数、发送字节数3个参数中都达到该第一实例的所有负载中对应参数的均值。
协议栈系统800还可执行图1、图2的方法，并能实现协议栈系统在上述如图1至图5所示的实施例的功能，具体实现可参考图1至图5所示实施例，本发明实施例在此不再赘述。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，Random Access Memory）、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。
Claims (26)
1.一种并行用户态协议栈的管理方法，其特征在于，包括：
监控用户态协议栈中每个协议栈对应的实例的运行状态，一个所述实例对应于所述用户态协议栈中的一个协议栈；
确定第一实例和第二实例，其中所述第一实例为运行状态异常的实例，所述第二实例具备迁入所述第一实例中至少一个待迁移负载的能力，一个所述待迁移负载在所述第一实例所对应的协议栈内对应于一个协议控制块PCB，所述PCB在共享资源池中对应于一个存储着所述待迁移负载连接参数的PCB，所述待迁移负载的连接参数能够用于重建所述待迁移负载；
根据所述第一实例中至少一个待迁移负载在所述共享资源池中所对应的PCB在所述第二实例中重建所述至少一个待迁移负载。
2.如权利要求1所述的方法，其特征在于，在所述根据所述第一实例中至少一个待迁移负载在共享资源池中所对应的PCB在所述第二实例中重建所述至少一个待迁移负载之前，所述方法还包括：
确定所述第一实例中的至少一个待迁移负载。
3.如权利要求2所述的方法，其特征在于，所述实例的运行状态包括实例的负载状态和存活状态，所述监控用户态协议栈中每个协议栈对应的实例的运行状态包括：
分别向所述用户态协议栈中每个协议栈对应的实例发送心跳消息并监控所述心跳消息响应时延，并监控所述用户态协议栈中每个协议栈对应的实例在第一预定时间内的实例负载均值，以根据所述心跳消息的响应时延和所述实例负载均值确定所述用户态协议栈中每个协议栈对应的实例的运行状态，其中，一条心跳消息对应于一个所述实例；或者
分别轮询所述用户态协议栈中每个协议栈对应的实例的实例标识，并监控所述用户态协议栈中每个协议栈对应的实例在第一预定时间内的实例负载均值，以根据所述实例标识和所述实例负载均值确定所述用户态协议栈中每个协议栈对应的实例的运行状态，其中，所述实例标识用于表示实例的存活状态，所述实例标识存储于共享内存区域或共享文件，一个所述实例标识对应于一个所述实例。
4.如权利要求3所述的方法，其特征在于，所述确定第一实例包括：
确定距离发送心跳消息时刻达到第二预定时间后仍然未反馈心跳响应的实例为所述第一实例；或者
确定第一预定时间内实例标识表示僵死或失效状态的实例为所述第一实例。
5.如权利要求4所述的方法，其特征在于，
所述确定第二实例包括：创建并确定新的实例为所述第二实例；
所述根据所述第一实例中至少一个待迁移负载在共享资源池中所对应的PCB在所述第二实例中重建所述至少一个待迁移负载包括：
根据所述至少一个待迁移负载之第一负载在共享资源池中所对应的第一PCB在所述第二实例中实现所述第一负载与所述用户态协议栈的上层服务的对接，并将所述第一负载在所述第一实例中绑定的第一接收端扩展RSS队列重绑定到所述第二实例的所述第一负载中，其中，所述至少一个待迁移负载包括所述第一实例的所有负载。
6.如权利要求5所述的方法，其特征在于，还包括：终止所述第一实例。
7.如权利要求3所述的方法，其特征在于，
所述确定第一实例包括：确定第一预定时间内实例总负载均值大于第一预定阈值的实例为所述第一实例。
8.如权利要求7所述的方法，其特征在于，所述确定第二实例包括：
如果存在第一预定时间内实例总负载均值低于第二预定阈值的实例，则确定所述第一预定时间内实例总负载均值低于第二预定阈值的一个或多个实例作为所述第二实例，其中，迁入所述第二实例的所有负载的负载值与所述第二预定阈值之和小于所述第一预定阈值。
9.如权利要求8所述的方法，其特征在于，所述根据所述第一实例中至少一个待迁移负载在共享资源池中所对应的PCB在所述第二实例中重建所述至少一个待迁移负载包括：
根据所述第一实例的至少一个待迁移负载之第二负载在所述共享资源池中所对应的第二PCB，将所述第二负载在所述第一实例中绑定的第二接收端扩展RSS队列的绑定规则修改为绑定到所述第二实例的第二负载中，以使得所述第二实例实现从所述第二RSS队列进行数据包接收及处理的过程；或者
根据所述第一实例的至少一个待迁移负载之第二负载在所述共享资源池中所对应的第二PCB，在所述第一实例中解除所述第二负载在所述第一实例中绑定的第二RSS队列，并在所述第二实例中将所述第二RSS队列绑定到所述第二负载中，以使得所述第二实例实现从所述第二RSS队列进行数据包接收及处理的过程。
10.如权利要求8或9所述的方法，其特征在于，所述确定所述第一实例中的至少一个待迁移负载包括：
确定所述第一实例中的第三负载为所述第一实例的待迁移负载，所述第三负载在所述第一实例中所绑定的第三接收端扩展RSS队列满足以下条件：当所述第三RSS队列绑定到所述第二实例时所述第二实例的连接数、接收字节数、发送字节数3个参数中至少有2个参数不大于所述第一实例的相应参数。
11.如权利要求7所述的方法，其特征在于，所述确定第二实例包括：如果不存在预定时间内实例总负载均值低于第二预定阈值的实例，则创建并确定新的实例为所述第二实例。
12.如权利要求11所述的方法，其特征在于，所述根据所述第一实例中至少一个待迁移负载在共享资源池中所对应的PCB在所述第二实例中重建所述至少一个待迁移负载包括：
根据所述第一实例的至少一个待迁移负载之第二负载在所述共享资源池中所对应的第二PCB在所述第二实例中实现所述第二负载与所述用户态协议栈的上层服务的对接以使得所述第二实例实现与所述第二负载对应的应用app的交互，并在所述第一实例中解除所述第二负载在所述第一实例中绑定的第二接收端扩展RSS队列，在所述第二实例中将所述第二RSS队列绑定到所述第二负载中，以使得所述第二实例实现从所述第二RSS队列进行数据包接收及处理的过程。
13.如权利要求11或12所述的方法，其特征在于，所述确定所述第一实例中的至少一个待迁移负载包括：
确定所述第一实例中的第三负载为所述第一实例的待迁移负载，所述第三负载在所述第一实例中所绑定的第三接收端扩展RSS队列满足以下条件：所述第三RSS队列的连接数、接收字节数、发送字节数3个参数中都达到所述第一实例的所有负载中对应参数的均值。
14.一种协议栈系统，其特征在于，包括：
监控单元，用于监控所述协议栈系统的用户态协议栈中每个协议栈对应的实例的运行状态，一个所述实例对应于所述用户态协议栈中的一个协议栈；
确定单元，用于确定第一实例和第二实例，所述第一实例为运行状态异常的实例，所述第二实例具备迁入所述第一实例中至少一个待迁移负载的能力，一个所述待迁移负载在所述第一实例所对应的协议栈内对应于一个协议控制块PCB，所述PCB在所述协议栈系统的共享资源池中对应于一个存储着所述待迁移负载的连接参数的PCB，所述待迁移负载的连接参数能够用于重建所述待迁移负载；
负载迁移单元，用于根据所述第一实例中至少一个待迁移负载在所述共享资源池中所对应的PCB在所述第二实例中重建所述至少一个待迁移负载。
15.如权利要求14所述的系统，其特征在于，所述确定单元还用于确定所述第一实例中的至少一个待迁移负载。
16.如权利要求15所述的系统，其特征在于，所述实例的运行状态包括实例的负载状态和存活状态，所述监控单元具体用于：
分别向所述用户态协议栈中每个协议栈对应的实例发送心跳消息并监控所述心跳消息响应时延，并监控所述用户态协议栈中每个协议栈对应的实例在第一预定时间内的实例负载均值，以根据所述心跳消息的响应时延和所述实例负载均值确定所述用户态协议栈中每个协议栈对应的实例的运行状态，其中，一条心跳消息对应于一个所述实例；或者
分别轮询所述用户态协议栈中每个协议栈对应的实例的实例标识，并监控所述用户态协议栈中每个协议栈对应的实例在第一预定时间内的实例负载均值，以根据所述实例标识和所述实例负载均值确定所述用户态协议栈中每个协议栈对应的实例的运行状态，其中，所述实例标识用于表示实例的存活状态，所述实例标识存储于共享内存区域或共享文件，一个所述实例标识对应于一个所述实例。
17.如权利要求16所述的系统，其特征在于，在用于确定所述第一实例的过程中，所述确定单元具体用于：
确定距离发送心跳消息时刻达到第二预定时间后仍然未反馈心跳响应的实例为所述第一实例；或者
确定第一预定时间内实例标识都表示僵死或失效状态的实例为所述第一实例。
18.如权利要求17所述的系统，其特征在于，
在用于确定所述第二实例的过程中，所述确定单元具体用于创建并确定新的实例为所述第二实例；
所述负载迁移单元具体用于根据所述至少一个待迁移负载之第一负载在所述共享资源池中所对应的第一PCB在所述第二实例中实现所述第一负载与所述用户态协议栈的上层服务的对接，并将所述第一负载在所述第一实例中绑定的第一接收端扩展RSS队列重绑定到所述第二实例的所述第一负载中，其中，所述至少一个待迁移负载包括所述第一实例的所有负载。
19.如权利要求18所述的系统，其特征在于，所述系统还包括：实例停止单元，用于终止所述第一实例。
20.如权利要求16所述的系统，其特征在于，
在用于确定所述第一实例的过程中，所述确定单元具体用于确定第一预定时间内实例总负载均值大于第一预定阈值的实例为所述第一实例。
21.如权利要求20所述的系统，其特征在于，
在用于确定所述第二实例的过程中，如果存在第一预定时间内实例总负载均值低于第二预定阈值的实例，则所述确定单元具体用于确定所述第一预定时间内实例总负载均值低于第二预定阈值的一个或多个实例作为所述第二实例，其中，迁入所述第二实例的所有负载的负载值与所述第二预定阈值之和小于所述第一预定阈值。
22.如权利要求21所述的系统，其特征在于，所述负载迁移单元具体用于：
根据所述第一实例的至少一个待迁移负载之第二负载在所述共享资源池中所对应的第二PCB，将所述第二负载在所述第一实例中绑定的第二接收端扩展RSS队列的绑定规则修改为绑定到所述第二实例的第二负载中，以使得所述第二实例实现从所述第二RSS队列进行数据包接收及处理的过程；或者
根据所述第一实例的至少一个待迁移负载之第二负载在所述共享资源池中所对应的第二PCB，在所述第一实例中解除所述第二负载在所述第一实例中绑定的第二RSS队列，并在所述第二实例中将所述第二RSS队列绑定到所述第二负载中，以使得所述第二实例实现从所述第二RSS队列进行数据包接收及处理的过程。
23.如权利要求21或22所述的系统，其特征在于，在用于确定所述第一实例中的至少一个待迁移负载的过程中，所述确定单元具体用于：确定所述第一实例中的第三负载为所述第一实例的待迁移负载，所述第三负载在所述第一实例中所绑定的第三接收端扩展RSS队列满足以下条件：当所述第三RSS队列绑定到所述第二实例时所述第二实例的连接数、接收字节数、发送字节数3个参数中至少有2个参数不大于所述第一实例的相应参数。
24.如权利要求20所述的系统，其特征在于，在用于确定所述第二实例的过程中，如果不存在预定时间内实例总负载均值低于第二预定阈值的实例，则所述确定单元具体用于创建并确定新的实例为所述第二实例。
25.如权利要求24所述的系统，其特征在于，所述负载迁移单元具体用于：
根据所述第一实例的至少一个待迁移负载之第二负载在所述共享资源池中所对应的第二PCB在所述第二实例中实现所述第二负载与所述用户态协议栈的上层服务的对接以使得所述第二实例实现与所述第二负载对应的应用app的交互，并在所述第一实例中解除所述第二负载在所述第一实例中绑定的第二接收端扩展RSS队列，在所述第二实例中将所述第二RSS队列绑定到所述第二负载中，以使得所述第二实例实现从所述第二RSS队列进行数据包接收及处理的过程。
26.如权利要求24或25所述的系统，其特征在于，在用于确定所述第一实例中的至少一个待迁移负载的过程中，所述确定单元具体用于：
确定所述第一实例中的第三负载为所述第一实例的待迁移负载，所述第三负载在所述第一实例中所绑定的第三接收端扩展RSS队列满足以下条件：所述第三RSS队列的连接数、接收字节数、发送字节数3个参数中都达到所述第一实例的所有负载中对应参数的均值。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201410124239.XA CN104951357B (zh) | 2014-03-28 | 2014-03-28 | 并行用户态协议栈的管理方法和协议栈系统 |
| PCT/CN2014/095248 WO2015143904A1 (zh) | 2014-03-28 | 2014-12-29 | 并行用户态协议栈的管理方法和协议栈系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201410124239.XA CN104951357B (zh) | 2014-03-28 | 2014-03-28 | 并行用户态协议栈的管理方法和协议栈系统 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN104951357A CN104951357A (zh) | 2015-09-30 |
| CN104951357B true CN104951357B (zh) | 2018-06-26 |
Family
ID=54166026
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201410124239.XA Active CN104951357B (zh) | 2014-03-28 | 2014-03-28 | 并行用户态协议栈的管理方法和协议栈系统 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN104951357B (zh) |
| WO (1) | WO2015143904A1 (zh) |
Families Citing this family (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105893141A (zh) * | 2015-12-17 | 2016-08-24 | 乐视致新电子科技（天津）有限公司 | 一种多核处理器调控方法及装置及使用该方法的移动终端 |
| CN106953857B (zh) * | 2017-03-16 | 2020-03-10 | 郑州云海信息技术有限公司 | 一种基于cs架构的服务器端多线程管理方法 |
| CN108737465A (zh) * | 2017-04-19 | 2018-11-02 | 中兴通讯股份有限公司 | 一种用户协议栈运行方法和装置 |
| CN108549574B (zh) * | 2018-03-12 | 2022-03-15 | 深圳市万普拉斯科技有限公司 | 线程调度管理方法、装置、计算机设备和存储介质 |
| CN108984376B (zh) * | 2018-05-31 | 2021-11-19 | 创新先进技术有限公司 | 一种系统异常检测方法、装置及设备 |
| CN109032799A (zh) * | 2018-07-25 | 2018-12-18 | 郑州云海信息技术有限公司 | 存储资源管理方法、装置、设备及可读存储介质 |
| CN111294220B (zh) * | 2018-12-07 | 2022-06-21 | 网宿科技股份有限公司 | 基于nginx的网络隔离配置方法和装置 |
| CN109547580B (zh) * | 2019-01-22 | 2021-05-25 | 网宿科技股份有限公司 | 一种处理数据报文的方法和装置 |
| CN111756780B (zh) * | 2019-03-27 | 2022-04-22 | 厦门网宿有限公司 | 一种同步连接信息的方法和负载均衡系统 |
| CN110278161B (zh) * | 2019-05-06 | 2020-08-11 | 阿里巴巴集团控股有限公司 | 基于用户态协议栈的报文分流方法、装置及系统 |
| US10904719B2 (en) | 2019-05-06 | 2021-01-26 | Advanced New Technologies Co., Ltd. | Message shunting method, device and system based on user mode protocol stack |
| CN110493329A (zh) * | 2019-08-08 | 2019-11-22 | 西藏宁算科技集团有限公司 | 一种基于用户态协议栈的并发推送服务方法和系统 |
| CN111143062A (zh) * | 2019-12-19 | 2020-05-12 | 上海交通大学 | 一种用户态协议栈对外部负载进程的均衡分割策略 |
| CN111240833B (zh) * | 2019-12-31 | 2023-03-17 | 厦门网宿有限公司 | 一种资源迁移方法及装置 |
| CN114064302B (zh) * | 2020-07-30 | 2024-05-14 | 华为技术有限公司 | 一种进程间通信的方法及装置 |
| CN115766044A (zh) * | 2021-08-31 | 2023-03-07 | 华为技术有限公司 | 一种基于用户态协议栈的通信方法及相应装置 |
| CN116820801A (zh) * | 2023-06-15 | 2023-09-29 | 中科驭数（北京）科技有限公司 | Io多路复用机制的优化方法、装置及设备 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101001255A (zh) * | 2006-12-19 | 2007-07-18 | 华为技术有限公司 | 对会话初始化协议栈进行负载控制的方法和装置 |
| CN101741832A (zh) * | 2008-11-25 | 2010-06-16 | 宝利通公司 | 利用相同ip端口在应用的多个实例之间分派接收的会话的方法和系统 |
| CN101859263A (zh) * | 2010-06-12 | 2010-10-13 | 中国人民解放军国防科学技术大学 | 一种支持在线迁移的虚拟机间快速通信方法 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7567504B2 (en) * | 2003-06-30 | 2009-07-28 | Microsoft Corporation | Network load balancing with traffic routing |
-
2014
- 2014-03-28 CN CN201410124239.XA patent/CN104951357B/zh active Active
- 2014-12-29 WO PCT/CN2014/095248 patent/WO2015143904A1/zh active Application Filing
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101001255A (zh) * | 2006-12-19 | 2007-07-18 | 华为技术有限公司 | 对会话初始化协议栈进行负载控制的方法和装置 |
| CN101741832A (zh) * | 2008-11-25 | 2010-06-16 | 宝利通公司 | 利用相同ip端口在应用的多个实例之间分派接收的会话的方法和系统 |
| CN101859263A (zh) * | 2010-06-12 | 2010-10-13 | 中国人民解放军国防科学技术大学 | 一种支持在线迁移的虚拟机间快速通信方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN104951357A (zh) | 2015-09-30 |
| WO2015143904A1 (zh) | 2015-10-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN104951357B (zh) | 并行用户态协议栈的管理方法和协议栈系统 | |
| CN102859491B (zh) | 通过利用接收侧缩放(rss)软件为网络适配器动态添加或移除队列对的资源关联 | |
| CN106339058B (zh) | 动态管理电力供应的方法和系统 | |
| TWI559153B (zh) | 分散式計算架構 | |
| US10341196B2 (en) | Reliably updating a messaging system | |
| CN106462498B (zh) | 用于数据存储系统的模块化交换架构 | |
| US20200218684A1 (en) | Technologies for accelerator fabric protocol multipathing | |
| EP2701074B1 (en) | Method, device, and system for performing scheduling in multi-processor core system | |
| CN102147746B (zh) | 动态线程池管理系统及管理方法 | |
| CN109729106B (zh) | 处理计算任务的方法、系统和计算机程序产品 | |
| CN102576309B (zh) | 当在运行于相同数据处理系统上的应用程序之间通信时,通过旁路网络栈而在逻辑分区系统中的分区之间的通信 | |
| CN110022267A (zh) | 网络数据包处理方法及装置 | |
| CN108134830A (zh) | 基于消息队列的负载均衡方法、系统、装置及存储介质 | |
| TW200826594A (en) | Network interface techniques | |
| CN108153590A (zh) | 管理硬件资源 | |
| CN102567090A (zh) | 在计算机处理器中创建执行线程的方法和系统 | |
| CN111104210A (zh) | 一种任务处理方法、装置及计算机系统 | |
| DE102020114142A1 (de) | Technologien für unterbrechungs-disassoziierte warteschlangenbildung für multi-warteschlangen-i/o-vorrichtungen | |
| CN109327383A (zh) | 一种故障处理方法及设备 | |
| US9853933B2 (en) | Message queue replication with message ownership migration | |
| CN108881060A (zh) | 一种处理通信报文的方法及装置 | |
| CN107659511B (zh) | 一种过载控制方法、主机和存储介质以及程序产品 | |
| CN116204448A (zh) | 一种多端口固态硬盘及其控制方法、装置、介质、服务器 | |
| CN109684256A (zh) | 服务器及数据传输方法 | |
| CN109688011A (zh) | 一种基于OpenStack的agent选择方法及装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |