一种多线程转发的负载均衡方法及相关装置与流程

1.本技术涉及计算机技术领域，尤其涉及一种多线程转发的负载均衡方法及相关装置。


背景技术：

2.openflow虚拟交换机(openflow virtual switch，ovs)是一种多层虚拟交换机，用于通过编程扩展实现大规模网络自动化。ovs强大的openflow流表能力能够解决各层次的业务功能问题，因此ovs广泛应用于虚拟网络转发中。但是在云计算领域，虚拟网络节点的集群规模不断扩大，对网络性能的要求不断提高。在ovs的解决方案中，硬件网卡驱动工作在内核态，依赖软中断处理收包事件，严重限制了转发性能。
3.为解决网卡收包性能瓶颈问题，在ovs的基础上，数据平面开发套件(data plane development kit，dpdk)技术应运而生。dpdk是一个数据平面开发工具集，能够将用户态的数据绕过内核直接转发到网卡。在ovs dpdk的解决方案中，轮询模式驱动程序(poll mode driver，pmd)线程负责处理dpdk数据路径上的数据包收发工作。pmd线程周期性轮询虚拟网卡队列，一旦获取到虚拟网卡队列中的数据包，则对数据包进行解析和转发。
4.目前，pmd线程与虚拟网卡队列之间是预先绑定的。每个虚拟网卡队列与唯一对应的一个pmd线程绑定，一个pmd线程则可以与一个或多个虚拟网卡队列绑定。然而，在实际的转发场景下，虚拟网卡队列的负载会不断变化，固定不变的绑定方式会造成pmd线程上的负载不均，导致资源得不到充分利用。


技术实现要素：

5.本技术提供了一种多线程转发的负载均衡方法，通过从处理虚拟网卡队列的多个线程中，选择负载较大的线程以及负载较小的线程，并将负载较大的线程所处理的虚拟网卡队列切换至负载较小的线程中，实现线程间的负载均衡，保证计算资源能够得到充分利用，提高了计算计算资源的利用率。
6.本技术第一方面提供一种多线程转发的负载均衡方法，可以应用于服务器。该多线程转发的负载均衡方法包括：服务器在多个线程中确定第一线程和第二线程。其中，所述多个线程均用于处理虚拟网卡队列中的数据包，所述多个线程例如可以为pmd线程。所述第一线程的负载大于第一阈值，所述第二线程的负载小于第二阈值，所述第一阈值大于所述第二阈值。当线程的负载大于第一阈值时，则可以认为线程的负载过高；当线程的负载小于第二阈值时，则可以认为线程的负载过低。
7.服务器在所述第一线程所对应的多个虚拟网卡队列中确定第一队列，所述第一线程用于处理所述多个虚拟网卡队列中的数据包。其中，第一队列可以是包括一个或多个虚拟网卡队列。
8.服务器将所述第一队列切换至第二线程，以使得所述第二线程处理所述第一队列中的数据包。在第一队列切换至第二线程后，第一线程则不再负责处理第一队列中的数据
包。
9.本方案中，通过从处理虚拟网卡队列的多个线程中，选择负载较大的线程以及负载较小的线程，并将负载较大的线程所处理的虚拟网卡队列切换至负载较小的线程中，实现线程间的负载均衡，保证计算资源能够得到充分利用，提高了计算资源的利用率。
10.在一种可能的实现方式中，所述服务器将所述第一队列切换到所述第二线程，包括：服务器将所述第一队列标记为调度模式，所述调度模式用于指示所述第一队列为待切换线程的队列。在第一队列被标记为调度模式的情况下，服务器则不会再将第一队列标记为中断收包模式，以保证第一队列后续能够顺利切换至第二线程。服务器将处于调度模式的所述第一队列从所述第一线程切换至所述第二线程，由第二线程负责处理第一队列中的数据包。服务器将切换至所述第二线程的所述第一队列标记为轮询收包模式，所述轮询收包模式用于指示所述第二线程以轮询的方式处理所述第一队列中的数据包。
11.本方案中，通过将待切换线程的虚拟网卡队列标记为调度模式后，再对被标记为调度模式的虚拟网卡队列执行线程切换，从而能够避免虚拟网卡队列在切换线程的过程中被多个线程同时处理，保证了线程切换过程的顺利进行。
12.在一种可能的实现方式中，服务器在所述第一线程所对应的多个虚拟网卡队列中确定第一队列，包括：服务器在所述第一线程所对应的多个虚拟网卡队列中确定被标记为轮询收包模式的一个或多个虚拟网卡队列；服务器在所述一个或多个虚拟网卡队列中确定需要被切换至第二线程的所述第一队列。
13.在一种可能的实现方式中，所述在所述第一线程所对应的多个虚拟网卡队列中确定第一队列，包括：根据所述第一线程的负载和所述第二阈值，确定第一负载量，所述第一负载量为第一线程能够转移的最大负载量。服务器根据所述第二线程的负载和所述第一阈值，确定第二负载量，所述第二负载量为第二线程能够接收的最大负载量。服务器根据所述第一负载量和所述第二负载量确定所述第一队列，所述第一负载量和所述第二负载量均大于或等于所述第一队列对应的负载量。也就是说，所述第一队列对应的负载量既小于所述第一负载量又小于所述第二负载量。
14.例如，服务器可以通过将第一线程的负载与第二阈值相减，得到第一负载量；服务器可以通过将第一阈值与第二线程的负载相减，得到第二负载量。
15.基于第一线程的负载和第二线程的负载来综合确定待切换至第二线程的队列，可以保证队列在切换线程后，第一线程的负载不会降低至第二阈值以下或者第二线程的负载不会增加至第一阈值以上，从而保证了队列不会在线程间来回切换。
16.在一种可能的实现方式中，所述方法还包括：若所述第一线程连续轮询被标记为轮询收包模式的第二队列的次数大于第三阈值，且所述第一线程连续轮询所述第二队列的期间均没有接收到数据包，则将所述第二队列标记为中断收包模式。
17.其中，所述多个虚拟网卡队列包括所述第二队列，所述中断收包模式用于指示所述第一线程在获取到所述第二队列的中断信号后，触发处理所述第二队列中的数据包。
18.简单来说，对于被标记轮询收包模式的第二队列，如果第一线程持续轮询该第二队列的期间均没有获取到数据包，且第一线程已经轮询了第二队列一定次数，则可以认为第二队列在未来的时间内大概率也是不会产生数据包的。因此，服务器可以将当前处于轮询收包模式的第二队列改为中断收包模式，从而使得第一线程不再周期性地轮询第二队
列，减少轮询空队列的资源消耗，节省处理器资源。
19.在一种可能的实现方式中，所述方法还包括：若所述第一线程获取到来自于被标记为中断收包模式的第三队列的中断信号，则将所述第三队列标记为轮询收包模式。
20.其中，所述中断收包模式用于指示所述第一线程在获取到所述第三队列的中断信号后触发处理所述第三队列中的数据包，所述轮询收包模式用于指示所述第一线程以轮询的方式处理所述第三队列中的数据包。
21.简单来说，对于被标记为中断收包模式的第三队列，如果第三线程获取到了来自于第三队列的中断信号，则可以认为第三队列在未来的时间内大概率也是会持续产生数据包的。因此，服务器可以将当前处于中断收包模式的第三队列改为轮询收包模式，从而使得第一线程能够周期性地轮询第三队列，提高第一线程的处理效率。
22.在一种可能的实现方式中，所述方法还包括：服务器获取所述多个线程在第一时间段内的负载；服务器根据所述多个线程在第一时间段内的负载预测所述多个线程在第二时间段的负载，所述第二时间段位于所述第一时间段之后；若所述多个线程在第二时间段的负载大于第四阈值，则创建新的线程，所述新的线程用于处理虚拟网卡队列中的数据包；若所述多个线程在第二时间段的负载小于第五阈值，则在所述多个线程中删除部分线程。
23.本方案中，在预测得知所述多个线程在未来一段时间内的负载较高时，服务器可以创建新的线程，以便于及时应对未来一段时间内较高的业务流量，保证突发的业务流量能够得到及时有效的处理，确保业务的可靠性。在预测得知所述多个线程在未来一段时间内的负载较低时，服务器可以将负载最低的线程上的虚拟网卡队列分担给其他的线程，并删除该线程，以释放该线程对应的处理器资源，节约计算资源。
24.在一种可能的实现方式中，所述在所述多个线程中删除部分线程，包括：在所述多个线程中确定待删除的线程和待保留的线程；将所述待删除的线程所对应的虚拟网卡队列切换到所述待保留的线程；删除所述待删除的线程。
25.在一种可能的实现方式中，所述第一线程的负载包括所述第一线程对应的处理器资源利用率。
26.本技术第二方面提供一种调度装置，包括：获取单元和处理单元。所述处理单元用于：在多个线程中确定第一线程和第二线程，其中，所述多个线程均用于处理虚拟网卡队列中的数据包，所述第一线程的负载大于第一阈值，所述第二线程的负载小于第二阈值，所述第一阈值大于所述第二阈值；在所述第一线程所对应的多个虚拟网卡队列中确定第一队列，所述第一线程用于处理所述多个虚拟网卡队列中的数据包；将所述第一队列切换至第二线程，以使得所述第二线程处理所述第一队列中的数据包。
27.在一种可能的实现方式中，所述处理单元还用于：将所述第一队列标记为调度模式，所述调度模式用于指示所述第一队列为待切换线程的队列；将处于调度模式的所述第一队列从所述第一线程切换至所述第二线程；将切换至所述第二线程的所述第一队列标记为轮询收包模式，所述轮询收包模式用于指示所述第二线程以轮询的方式处理所述第一队列中的数据包。
28.在一种可能的实现方式中，所述处理单元还用于：在所述第一线程所对应的多个虚拟网卡队列中确定被标记为轮询收包模式的一个或多个虚拟网卡队列；在所述一个或多个虚拟网卡队列中确定所述第一队列。
29.在一种可能的实现方式中，所述处理单元还用于：根据所述第一线程的负载和所述第二阈值，确定第一负载量，所述第一负载量为第一线程能够转移的最大负载量；根据所述第二线程的负载和所述第一阈值，确定第二负载量，所述第二负载量为第二线程能够接收的最大负载量；根据所述第一负载量和所述第二负载量确定所述第一队列，所述第一负载量和所述第二负载量均大于或等于所述第一队列对应的负载量。
30.在一种可能的实现方式中，所述处理单元还用于：若所述第一线程连续轮询被标记为轮询收包模式的第二队列的次数大于第三阈值，且所述第一线程连续轮询所述第二队列的期间均没有接收到数据包，则将所述第二队列标记为中断收包模式；其中，所述多个虚拟网卡队列包括所述第二队列，所述中断收包模式用于指示所述第一线程在获取到所述第二队列的中断信号后，触发处理所述第二队列中的数据包。
31.在一种可能的实现方式中，所述处理单元还用于：若所述第一线程获取到来自于被标记为中断收包模式的第三队列的中断信号，则将所述第三队列标记为轮询收包模式；其中，所述中断收包模式用于指示所述第一线程在获取到所述第三队列的中断信号后触发处理所述第三队列中的数据包，所述轮询收包模式用于指示所述第一线程以轮询的方式处理所述第三队列中的数据包。
32.在一种可能的实现方式中，所述获取单元，用于获取所述多个线程在第一时间段内的负载；所述处理单元还用于：根据所述多个线程在第一时间段内的负载预测所述多个线程在第二时间段的负载，所述第二时间段位于所述第一时间段之后；若所述多个线程在第二时间段的负载大于第四阈值，则创建新的线程，所述新的线程用于处理虚拟网卡队列中的数据包；若所述多个线程在第二时间段的负载小于第五阈值，则在所述多个线程中删除部分线程。
33.在一种可能的实现方式中，所述处理单元还用于：在所述多个线程中确定待删除的线程和待保留的线程；将所述待删除的线程所对应的虚拟网卡队列切换到所述待保留的线程；删除所述待删除的线程。
34.在一种可能的实现方式中，所述第一线程的负载包括所述第一线程对应的处理器资源利用率。
35.本技术第三方面提供一种终端，该终端包括：存储器和处理器；所述外存储器存储有代码，所述处理器被配置为执行所述代码，当所述代码被执行时，所述终端执行如第一方面中的任意一种实现方式的方法。
36.本技术第四方面提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行如第一方面中的任意一种实现方式的方法。
37.本技术第五方面提供一种计算机程序产品，当其在计算机上运行时，使得计算机执行如第一方面中的任意一种实现方式的方法。
38.本技术第六方面提供一种芯片，包括一个或多个处理器。处理器中的部分或全部用于读取并执行存储器中存储的计算机程序，以执行上述任一方面任意可能的实现方式中的方法。
39.可选地，该芯片该包括存储器，该存储器与该处理器通过电路或电线与存储器连接。可选地，该芯片还包括通信接口，处理器与该通信接口连接。通信接口用于接收需要处
理的数据和/或信息，处理器从该通信接口获取该数据和/或信息，并对该数据和/或信息进行处理，并通过该通信接口输出处理结果。该通信接口可以是输入输出接口。本技术提供的方法可以由一个芯片实现，也可以由多个芯片协同实现。
附图说明
40.图1为本技术实施例提供的一种应用场景的架构示意图；
41.图2为本技术实施例提供的一种终端101的结构示意图；
42.图3为本技术实施例提供的一种多线程转发的负载均衡方法的流程示意图；
43.图4为本技术实施例提供的一种服务器的架构示意图；
44.图5为本技术实施例提供的一种虚拟网卡队列的收包模式之间切换示意图；
45.图6为本技术实施例提供的一种调整pmd数量的流程示意图；
46.图7为本技术实施例提供的一种调度装置700的结构示意图；
47.图8为本技术实施例提供的一种计算机可读存储介质的结构示意图。
具体实施方式
48.下面结合附图，对本技术的实施例进行描述，显然，所描述的实施例仅仅是本技术一部分的实施例，而不是全部的实施例。本领域普通技术人员可知，随着技术的发展和新场景的出现，本技术实施例提供的技术方案对于类似的技术问题，同样适用。
49.本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或模块的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或模块，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或模块。在本技术中出现的对步骤进行的命名或者编号，并不意味着必须按照命名或者编号所指示的时间/逻辑先后顺序执行方法流程中的步骤，已经命名或者编号的流程步骤可以根据要实现的技术目的变更执行次序，只要能达到相同或者相类似的技术效果即可。
50.在云网络数据面上，通常采用ovs来实现虚拟网络中数据包的转发。ovs支持标准的管理接口和协议，以及跨多个物理服务器的数据包分发。ovs强大的openflow流表能力能够解决各层次的业务功能问题。但是在云计算领域，虚拟网络节点的集群规模不断扩大，对网络性能的要求不断提高。在ovs的解决方案中，硬件网卡驱动工作在内核态，依赖软中断处理收包事件，严重限制了转发性能。
51.为解决网卡收包性能瓶颈问题，数据平面开发套件(data plane development kit，dpdk)技术应运而生。dpdk是一个开源的快速包处理开发工具集，实现了一套完整的基于linux操作系统但又不同于linux操作系统的用户空间实时运行环境。不同于linux操作系统以通用性设计为目的，dpdk专注于网络应用中数据包的高性能处理。具体地，dpdk中的应用程序是运行在用户空间上，并利用dpdk提供的数据平面库来收发数据包，绕过了linux内核协议栈对数据包的处理过程，实现数据包的高速转发。在ovs的基础上，基于dpdk的高速数据包吞吐优势，能够在以软件为主体的虚拟化环境中实现网络的高性能化。dpdk中高
性能的网卡驱动、大页内存以及无锁化结构设计，都能够极大地提升ovs的转发性能。
52.在虚拟网络中，虚拟网卡(virtual network interface card，vnic)是实现数据包转发的核心。具体地，虚拟网卡是使用网络底层编程技术实现的一个驱动软件。在安装虚拟网卡后，主机上会增加一个非真实的网卡，并可以像其它网卡一样进行配置。服务程序可以在应用层打开虚拟网卡，如果应用软件(例如网络浏览器)向虚拟网卡发送数据，则服务程序可以读取到该数据。如果服务程序写合适的数据到虚拟网卡，应用软件也可以接收得到服务程序写入的数据。一般地，虚拟网卡具有对应的虚拟网卡队列，虚拟网卡队列中包括有待转发的数据包。
53.在ovs dpdk的解决方案中，轮询模式驱动程序(poll mode driver，pmd)线程负责处理dpdk数据路径上的数据包收发工作。在pmd线程的工作过程中，pmd线程周期性轮询虚拟网卡队列，一旦获取到虚拟网卡队列中的数据包，则对数据包进行解析和转发。
54.目前，pmd线程与虚拟网卡队列之间是预先绑定的。每个虚拟网卡队列与唯一对应的一个pmd线程绑定，一个pmd线程则可以与一个或多个虚拟网卡队列绑定。然而，在实际的转发场景下，虚拟网卡队列的负载会不断变化。由于每个pmd都绑定有不同的虚拟网卡队列，随着虚拟网卡队列的负载的不断变化，固定不变的绑定方式会造成pmd线程上的负载不均，导致计算资源得不到充分利用。
55.有鉴于此，本技术实施例提供了一种多线程转发的负载均衡方法，通过从处理虚拟网卡队列的多个队列中，选择负载较大的队列以及负载较小的队列，并将负载较大的队列所处理的虚拟网卡队列切换至负载较小的队列中，实现线程间的负载均衡，保证计算资源能够得到充分利用，提高了计算资源的利用率。
56.可以参阅图1，图1为本技术实施例提供的一种应用场景的架构示意图。该应用场景的架构包括：软件模块和硬件模块；其中，软件模块包括虚拟机(virtual machine，vm)1、虚拟机2和虚拟交换机(virtual switch，vswitch)；硬件模块包括物理网卡。虚拟机1中包括虚拟网卡1，虚拟机2中包括虚拟网卡2，虚拟交换机中包括pmd驱动、端口管理模块、转发规则管理模块和虚拟网卡3。
57.虚拟机是指通过虚拟机软件可以在一台物理计算机上模拟出的计算机。虚拟机能够像真正的计算机进行工作。虚拟机上可以安装操作系统和应用程序，虚拟机还可访问网络资源。对于在虚拟机中运行的应用程序而言，虚拟机就像是在真正的计算机中进行工作。例如，图1中的虚拟机1和虚拟机2分别承载有不同的业务。
58.虚拟交换机则是用于负责虚拟机之间的数据转发和控制。例如，图1中的虚拟交换机则用于负责虚拟机1和虚拟机2之间的数据交换。虚拟交换机能够从虚拟机1接收数据包，并将数据包转发至虚拟机2，以实现虚拟机1和虚拟机2之间的数据交换。
59.此外，虚拟交换机中的pmd驱动用于在用户态实现对网卡收发数据包行为的控制，以减少陷入、陷出内核的消耗，提高性能。端口管理模块实现端口的添加和删除。转发规则管理模块实现路由规则的添加和删除，并根据路由规则决定数据包的走向。物理网卡的功能则是以比特流的方式接收和发送数据。
60.本技术实施例所提供的多线程转发的负载均衡方法的产品实现形态可以是部署在终端上的程序代码，尤其是部署在云网络的服务器上。本技术实施例所提供的程序代码运行在云网络的数据面，即虚拟机之间的数据包转发流程中。例如，本技术实施例所提供的
程序代码运行于图1中的虚拟机交换机内，并在pmd驱动之上，能够用于实现pmd线程的调度。
61.示例性地，本技术实施例所涉及的终端例如可以是服务器、个人电脑(personal computer，pc)、笔记本电脑、手机(mobile phone)、平板电脑、移动互联网设备(mobile internet device，mid)、可穿戴设备，虚拟现实(virtual reality，vr)设备、增强现实(augmented reality，ar)设备、工业控制(industrial control)中的无线终端、无人驾驶(self driving)中的无线终端、远程手术(remote medical surgery)中的无线终端、智能电网(smart grid)中的无线终端、运输安全(transportation safety)中的无线终端、智慧城市(smart city)中的无线终端、智慧家庭(smart home)中的无线终端等。该终端可以是运行安卓系统、ios系统、windows系统以及其他系统的设备。
62.可以参阅图2，图2为本技术实施例提供的一种终端101的结构示意图。如图2所示，终端101包括处理器103，处理器103和系统总线105耦合。处理器103可以是一个或者多个处理器，其中每个处理器都可以包括一个或多个处理器核。显示适配器(video adapter)107，显示适配器可以驱动显示器109，显示器109和系统总线105耦合。系统总线105通过总线桥111和输入输出(i/o)总线耦合。i/o接口115和i/o总线耦合。i/o接口115和多种i/o设备进行通信，比如输入设备117(如：触摸屏等)，外存储器121,(例如，硬盘、软盘、光盘或优盘)，多媒体接口等)。收发器123(可以发送和/或接收无线电通信信号)，摄像头155(可以捕捉静态和动态数字视频图像)和外部usb端口125。其中，可选地，和i/o接口115相连接的接口可以是usb接口。
63.其中，处理器103可以是任何传统处理器，包括精简指令集计算(reduced instruction set computing，risc)处理器、复杂指令集计算(complex instruction set computing，cisc)处理器或上述的组合。可选地，处理器可以是诸如asic的专用装置。
64.终端101可以通过网络接口129和软件部署服务器149通信。示例性的，网络接口129是硬件网络接口，比如，网卡。网络127可以是外部网络，比如因特网，也可以是内部网络，比如以太网或者虚拟私人网络(virtual private network，vpn)。可选地，网络127还可以是无线网络，比如wifi网络，蜂窝网络等。
65.硬盘驱动器接口131和系统总线105耦合。硬件驱动接口和硬盘驱动器133相连接。内存135和系统总线105耦合。运行在内存135的数据可以包括终端101的操作系统(os)137、应用程序143和调度表。
66.操作系统包括shell 139和内核(kernel)141。shell 139是介于使用者和操作系统的内核间的一个接口。shell是操作系统最外面的一层。shell管理使用者与操作系统之间的交互：等待使用者的输入，向操作系统解释使用者的输入，并且处理各种各样的操作系统的输出结果。
67.内核141由操作系统中用于管理存储器、文件、外设和系统资源的那些部分组成。内核141直接与硬件交互，操作系统内核通常运行进程，并提供进程间的通信，提供cpu时间片管理、中断、内存管理和io管理等等。
68.示例性地，在终端101为智能手机的情况下，应用程序143包括即时通讯相关的程序。在一个实施例中，在需要执行应用程序143时，终端101可以从软件部署服务器149下载应用程序143。
69.为了便于叙述，以下以终端为云网络上的服务器为例，介绍本技术实施例提供的多线程转发的负载均衡方法。可以参阅图3，图3为本技术实施例提供的一种多线程转发的负载均衡方法的流程示意图。如图3所示，该多线程转发的负载均衡方法包括以下的步骤301-303。
70.步骤301，服务器在多个线程中确定第一线程和第二线程，其中，所述多个线程均用于处理虚拟网卡队列中的数据包，所述第一线程的负载大于第一阈值，所述第二线程的负载小于第二阈值，所述第一阈值大于所述第二阈值。
71.本实施例中，在公有云场景下，作为计算节点的服务器中可以创建有一个或多个虚拟机。每个虚拟机中包括一个或多个虚拟网卡。每个虚拟网卡中可能具有一个或多个虚拟网卡队列。虚拟网卡队列中则包括有待转发的数据包。一般来说，作为计算节点的服务器上可能同时存在有几百甚至上千个虚拟网卡队列。
72.为处理虚拟网卡队列中的数据包，服务器中可以创建有多个线程，该多个线程均用于处理虚拟网卡队列中的数据包，即对虚拟网卡队列中的数据包进行解析和转发。服务器中所创建的每个线程均可以是对应于一个或多个虚拟网卡队列，且线程间所对应的虚拟网卡队列是互不重合的。也就是说，每个虚拟网卡队列在同一时间内只能够对应于一个线程。
73.示例性地，服务器所创建的线程可以为pmd线程，该pmd线程可以是用于负责dpdk数据路径上的数据包的收发工作。
74.一般来说，不同的虚拟网卡队列对应于虚拟机中不同的业务，不同的虚拟网卡队列中的数据包通常是由不同的业务所产生的。然而，不同的业务在不同的时间段所产生的数据包是不相同的，且业务所产生的数据包是随着时间不断变化的。因此，在实际的业务场景下，不同的虚拟网卡队列中的数据包的数量是不一样的。并且，在大多数情况下，虚拟机中的业务并非是时刻都会具有交换数据的需求，因此大部分的虚拟网卡队列是没有数据包的，只有少部分的虚拟网卡队列上具有待处理的数据包。
75.这样一来，随着时间的推移，虚拟网卡队列中的数据包的数量发生变化，使得负责处理虚拟网卡队列的线程的负载也不断变化。在一些情况下，由于虚拟网卡队列中数据包的数量发生变化，可能会出现线程间负载不均衡的现象，即部分线程的负载过高，而部分线程的负载过低。
76.因此，本实施例中设置了两个阈值，即第一阈值和第二阈值。当线程的负载大于第一阈值时，则可以认为线程的负载过高；当线程的负载小于第二阈值时，则可以认为线程的负载过低。基于预先所设置的第一阈值和第二阈值，服务器可以在负责处理虚拟网卡队列的多个线程中，确定负载大于第一阈值的第一线程以及负载小于第二阈值的第二线程。
77.可选的，线程的负载可以是指线程对应的处理器资源利用率。
78.在一些场景中，每个线程都是由单独的一个中央处理器(central processing unit，cpu)运行的，且每个cpu的资源都是相同的。因此，在该场景下，服务器可以基于每个cpu的资源利用率来确定每个线程的负载。其中，cpu资源利用率是指在一定的时间段内，有效的cpu周期的数量与该时间段内cpu周期的总数之间的比值。有效的cpu周期的数量是指线程处理虚拟网卡队列中的数据包所消耗的cpu周期的数量。在基于每个cpu的资源利用率来确定每个线程的负载的情况下，第一阈值的取值范围例如可以为80％-90％，第二阈值的
取值范围例如可以为50％-60。示例性地，第一阈值的取值可以为90％，第一阈值的取值可以为60％。第一阈值和第二阈值也可以是其他的取值，本实施例并不对此做具体限定。
79.其中，cpu周期也称为机器周期。在计算机中，为了便于管理，常把一条指令的执行过程划分为若干个阶段(如取指、译码、执行等)，每一阶段完成一个基本操作。完成一个基本操作所需要的时间称为机器周期。一般情况下，一个机器周期由若干个时钟周期组成。
80.步骤302，服务器在所述第一线程所对应的多个虚拟网卡队列中确定第一队列，所述第一线程用于处理所述多个虚拟网卡队列中的数据包。
81.在确定负载大于第一阈值的第一线程之后，服务器则可以在第一线程所对应的多个虚拟网卡队列中确定需要切换至第二线程的第一队列。其中，第一队列可以是包括一个或多个虚拟网卡队列。
82.可选的，为了避免在将第一队列切换到第二线程之后，第一线程的负载降低至第二阈值以下或者第二线程的负载增加至第一阈值以上，服务器可以基于第一线程和第二线程当前的负载来确定第一队列。
83.示例性地，服务器首先可以根据所述第一线程的负载和所述第二阈值，确定第一负载量，所述第一负载量为第一线程能够转移给第二线程的最大负载量。由于第一线程在将第一队列转移至第二线程之后，第一线程的负载不能够变化为低于第二阈值，因此服务器可以通过将第一线程的负载与第二阈值相减，得到第一负载量。例如，假设第一线程转移队列前的负载为95％，第二阈值为60％，则第一负载量为95％-60％＝35％。
84.其次，服务器根据所述第二线程的负载和所述第一阈值，确定第二负载量，所述第二负载量为第二线程能够接收第一线程所转移的最大负载量。由于第二线程在负责了第一线程所转移的第一队列之后，第二线程的负载不能够变化为大于第一阈值，因此服务器可以通过将第一阈值与第二线程的负载相减，得到第二负载量。例如，假设第二线程在队列转移前的负载为65％，第一阈值为90％，则第二负载量为90％-65％＝25％。
85.最后，根据所述第一负载量和所述第二负载量确定所述第一队列，所述第一负载量和所述第二负载量均大于或等于所述第一队列对应的负载量。具体地，服务器可以是确定第一线程对应的多个虚拟网卡队列中每个虚拟网卡队列对应的负载量，然后基于各个虚拟网卡队列对应的负载量确定最终的第一队列，以保证第一队列对应的负载量小于第一负载量和第二负载量。其中，虚拟网卡队列对应的负载量可以是指第一线程在处理该虚拟网卡队列时所占用的处理器资源，例如上述的cpu资源利用率。
86.例如，假设第一负载量为35％，第二负载量为25％，则服务器所确定的第一队列对应的负载量小于25％。具体地，服务器可以是确定第一线程对应的一个或多个虚拟网卡队列为第一队列，只需要确保服务器所确定的第一队列中的一个或多个虚拟网卡队列对应的负载量之和既小于第一负载量又小于第二负载量即可。
87.步骤303，服务器将所述第一队列切换至第二线程，以使得所述第二线程处理所述第一队列中的数据包。
88.在服务器确定第一线程中需要切换至第二线程的第一队列之后，服务器则可以将第一队列切换至第二线程，由第二线程负责处理第一队列中的数据包。在第一队列切换至第二线程后，第一线程则不再负责处理第一队列中的数据包。
89.本实施例中，通过从处理虚拟网卡队列的多个线程中，选择负载较大的线程以及
负载较小的线程，并将负载较大的线程所处理的虚拟网卡队列切换至负载较小的线程中，实现线程间的负载均衡，保证计算资源能够得到充分利用，提高了计算资源的利用率。
90.可以理解的是，在实际业务场景下，大多数的虚拟网卡队列上是没有数据包的。那么在这种场景下，如果线程周期性地轮询虚拟网卡队列，则会频繁地轮询到空队列，而浪费cpu资源。
91.基于此，本实施例中为虚拟网卡队列提供了两种收包模式，分别为轮询收包模式和中断收包模式。当虚拟网卡队列处于轮询收包模式时，负责该虚拟网卡队列的线程则周期性地轮询该虚拟网卡队列，以实现接收和转发该虚拟网卡队列中的数据包。当虚拟网卡队列处于中断收包模式时，负责该虚拟网卡队列的线程不再轮询该虚拟网卡队列，而是在获取到来自于虚拟网卡队列的中断信号时，中断其正常行为，转为触发处理该虚拟网卡队列中的数据包。
92.一般来说，基于中断收包模式的方式来处理虚拟网卡队列的优点是响应及时。如果虚拟网卡队列中的数据量较小，则不会占用太多的cpu周期。但是，在虚拟网卡队列中的数据量大时，则会产生过多的中断，而每个中断都需要消耗不少的cpu周期，从而导致效率反而不如轮询收包模式高。
93.相反地，轮询收包模式更适用于需要处理大量数据的场景。因为线程每次轮询虚拟网卡队列都不需要消耗过多的cpu周期。轮询收包模式的缺点是：在虚拟网卡队列中的数据很少甚至是没有数据的情况下，线程也要持续轮询虚拟网卡队列，从而需要持续占用cpu周期。
94.也就是说，在虚拟网卡队列中持续产生数据包的情况下，相较于在获取到来自于虚拟网卡队列的中断信号后再处理虚拟网卡队列中的数据包，线程通过周期性地轮询虚拟网卡队列的方式来处理虚拟网卡队列中的数据包的效率更高。
95.因此，本实施例中，服务器可以基于虚拟网卡队列中的实际数据变化情况，控制虚拟网卡队列在中断收包模式和轮询收包模式之间切换。
96.在一个可能的实施例中，若服务器中的第一线程连续轮询被标记为轮询收包模式的第二队列的次数大于第三阈值，且所述第一线程连续轮询所述第二队列的期间均没有接收到数据包，则将所述第二队列标记为中断收包模式。其中，第二队列是第一线程对应的多个虚拟网卡队列中的队列。其中，第三阈值的取值可以根据实际需要来调整。在计算资源较为紧张的情况下，第三阈值的取值可以调整为较小的值；在需要响应要求较高的情况下，第三阈值的取值则可以调整为较大的值。示例性地，第三阈值的取值可以为1000。
97.简单来说，对于被标记轮询收包模式的第二队列，如果第一线程持续轮询该第二队列的期间均没有获取到数据包，且第一线程已经轮询了第二队列一定次数，则可以认为第二队列在未来的时间内大概率也是不会产生数据包的。因此，服务器可以将当前处于轮询收包模式的第二队列改为中断收包模式，从而使得第一线程不再周期性地轮询第二队列，减少轮询空队列的资源消耗，节省处理器资源。
98.在另一个可能的实施例中，若服务器中的第一线程获取到来自于被标记为中断收包模式的第三队列的中断信号，则将所述第三队列标记为轮询收包模式。此外，第一线程在获取到第三队列的中断信号之后，第一线程则触发处理第三队列中的数据包。其中，第三队列是第一线程对应的多个虚拟网卡队列中的队列。第三队列所标记的中断收包模式用于指
示所述第一线程在获取到所述第三队列的中断信号后触发处理所述第三队列中的数据包，第三队列后续所标记的轮询收包模式则用于指示所述第一线程以轮询的方式处理所述第三队列中的数据包。
99.简单来说，对于被标记为中断收包模式的第三队列，如果第三线程获取到了来自于第三队列的中断信号，则可以认为第三队列在未来的时间内大概率也是会持续产生数据包的。因此，服务器可以将当前处于中断收包模式的第三队列改为轮询收包模式，从而使得第一线程能够周期性地轮询第三队列，提高第一线程的处理效率。
100.可选的，在线程所对应的虚拟网卡队列可以被标记为轮询收包模式或中断收包模式的情况下，服务器在确定线程中需要切换至其他线程的虚拟网卡队列时，可以是在被标记轮询收包模式的虚拟网卡队列中进行确定。
101.示例性地，在服务器需要确定第一线程中待切换至第二线程的虚拟网卡队列时，服务器可以在所述第一线程所对应的多个虚拟网卡队列中确定被标记为轮询收包模式的一个或多个虚拟网卡队列。然后，服务器在所述被标记为轮询收包模式的一个或多个虚拟网卡队列中确定需要被切换至第二线程的第一队列。
102.由于被标记为中断收包模式的虚拟网卡队列是没有数据包的队列，因此线程不需要消耗额外的计算资源来处理被标记为中断收包模式的虚拟网卡队列。即被标记为中断收包模式的虚拟网卡队列对应的负载量较小甚至没有。那么，服务器可以在被标记为轮询收包模式的虚拟网卡队列中选择需要切换至第二线程的队列，保证第一线程的负载能够顺利转移至第二线程。
103.具体地，服务器可以是基于以下的步骤来实现将第一队列从第一线程切换至第二线程。
104.首先，服务器可以将所述第一队列标记为调度模式，所述调度模式用于指示所述第一队列为待切换线程的队列。在第一队列被标记为调度模式的情况下，服务器则不会再将第一队列标记为中断收包模式，以保证第一队列后续能够顺利切换至第二线程。此外，在第一队列被标记为调度模式的情况下，第一线程也不会继续处理第一队列中的数据包，以避免在切换过程中第二线程和第一线程可能会处理第一队列中的数据包。
105.然后，服务器将处于调度模式的所述第一队列从所述第一线程切换至所述第二线程，由第二线程负责处理第一队列中的数据包。在第一队列切换至第二线程后，第一线程则不再负责处理第一队列中的数据包。
106.最后，服务器将切换至所述第二线程的所述第一队列标记为轮询收包模式，以指示所述第二线程以轮询的方式处理所述第一队列中的数据包。
107.本实施例中，通过将待切换线程的虚拟网卡队列标记为调度模式后，再对被标记为调度模式的虚拟网卡队列执行线程切换，从而能够避免虚拟网卡队列在切换线程的过程中被多个线程同时处理，保证了线程切换过程的顺利进行。
108.可以理解的是，在公有云场景下，用户的业务强度是不稳定的。以新闻业务模型为例，业务流量的大小会受热点事件的影响。当有爆炸性新闻出现时，新闻业务模型的访问量会突增，导致数据面的转发压力突增，从而超过pmd线程的承载极限。在这种情况下，此时通过调度pmd线程，已无法保证业务功能。并且，当热点事件的热度退去之后，新闻业务模型的访问量将会回归正常水平。此外，在一些特殊的时间段下，新闻业务模型的业务流量通常也
会与常规时间段下的业务流量存在一定的差异。例如，对于新闻业务模型而言，通常周末的访问量会大于工作日的访问量。
109.为了应对以上所述的业务流量不断变化的场景，本技术实施例中通过调整用于处理虚拟网卡队列的线程的数量来适应业务流量的变化。
110.示例性地，服务器可以获取多个线程在第一时间段内的负载，该多个线程均用于处理虚拟网卡队列中的数据包。其中，服务器可以是分别获取多个线程中的每个线程在第一时间段内的负载轨迹，从而确定每个线程在第一时间段内的负载变化情况。
111.然后，服务器根据所述多个线程在第一时间段内的负载预测所述多个线程在第二时间段的负载，所述第二时间段位于所述第一时间段之后。简单来说，第一时间段可以是过去的一段时间，而第二时间段则是未来的一段时间。服务器基于多个线程在过去一段时间内的负载来预测这多个线程在未来一段时间内的负载。其中，第一时间段的时间长度与第二时间段的时间长度可以是相同的或者是不相同的。第一时间段和第二时间段的长度可以根据实际需要来确定，本实施例并不限定第一时间段和第二时间段的时间长度。例如，服务器根据所述多个线程在过去一周内的负载来预测所述多个线程在未来一周内的负载；又或者，服务器根据所述多个线程在过去几个小时内的负载来预测所述多个线程在未来一个小时内的负载。
112.具体地，服务器可以是基于现有的负载预测算法或者是流量预测算法来预测多个线程在第二时间段的负载。例如，服务器可以是基于长短期记忆网络(long short-term memory，lstm)算法来预测多个线程在第二时间段的负载。
113.若所述多个线程在第二时间段的负载大于第四阈值，则创建新的线程，所述新的线程用于处理虚拟网卡队列中的数据包。其中，所述多个线程在第二时间段的负载可以是指多个线程在第二时间段内的平均负载，也可以是指多个线程在第二时间段内总的负载。
114.具体地，在多个线程在第二时间段的负载为多个线程在第二时间段内的平均负载时，所述第四阈值可以是预先设置的；在多个线程在第二时间段的负载为多个线程在第二时间段内总的负载时，所述第四阈值则可以是基于所述多个线程的数量来确定的。例如，在线程的负载以cpu利用率来表示的情况下，在多个线程在第二时间段的负载为多个线程在第二时间段内的平均负载时，第四阈值的取值范围可以为80％-95％，例如第四阈值的取值为90％。类似地，在多个线程在第二时间段的负载为多个线程在第二时间段内总的负载时，如果多个线程的数量为10，则第四阈值的取值范围可以为800％-950％，例如第四阈值的取值为900％。
115.在预测得知所述多个线程在未来一段时间内的负载较高时，服务器可以创建新的线程，以便于及时应对未来一段时间内较高的业务流量，保证突发的业务流量能够得到及时有效的处理，确保业务的可靠性。
116.若所述多个线程在第二时间段的负载小于第五阈值，则在所述多个线程中删除部分线程。示例性地，在线程的负载以cpu利用率来表示的情况下，在多个线程在第二时间段的负载为多个线程在第二时间段内的平均负载时，第四阈值的取值范围可以为50％-60％，例如第四阈值的取值为60％。类似地，在多个线程在第二时间段的负载为多个线程在第二时间段内总的负载时，如果多个线程的数量为10，则第四阈值的取值范围可以为500％-600％，例如第四阈值的取值为600％。
117.具体地，所述服务器在所述多个线程中删除部分线程，包括：服务器在所述多个线程中确定待删除的线程和待保留的线程。例如，服务器可以将所述多个线程中负载最低的一个或多个线程确定为待删除的线程，所述多个线程中除了待删除的线程之外的线程则为待保留的线程。然后，服务器将所述待删除的线程所对应的虚拟网卡队列切换到所述待保留的线程，以使得待删除的线程不再负责处理虚拟网卡队列的数据包。最后，服务器删除所述待删除的线程。
118.这样一来，在预测得知所述多个线程在未来一段时间内的负载较低时，服务器可以将负载最低的线程上的虚拟网卡队列分担给其他的线程，并删除该线程，以释放该线程对应的处理器资源，节约处理器资源。
119.为了便于理解，以下将结合具体的例子介绍本技术实施例所提供的多线程转发的负载均衡方法。
120.具体地，可以参阅图4，图4为本技术实施例提供的一种服务器的架构示意图。如图4所示，服务器中包括虚拟机1、虚拟机2、虚拟交换机和物理网卡。其中，虚拟交换机中包括pmd管理模块、pmd调度模块、收包模式管理模块和pmd驱动。此外，在该服务器中，pmd线程用于负责处理虚拟网卡队列中的数据包，以实现数据包的收发工作。
121.pmd调度模块通过统计各个pmd线程的cpu资源利用率，利用超负荷(overload)阈值(即上述的第一阈值)和低负荷(underload)阈值(即上述的第二阈值)，来实现pmd线程的负载均衡。通过设置overload阈值和underload阈值，当pmd线程的cpu资源利用率大于overload阈值时，将该pmd线程的部分虚拟网卡队列调度给cpu资源利用率小于underload阈值的pmd。并且，在调度过程中，pmd调度模块需要保证在调度完成后，原先cpu资源利用率大于overload阈值的pmd不能变成cpu资源利用率小于underload阈值的pmd。类似地，原先cpu资源利用率小于underload阈值的pmd不能变成cpu资源利用率大于overload阈值的pmd。
122.收发包管理模块负责管理虚拟网卡队列在调度模式、中断收包模式和轮询收包模式三种模式间的智能切换。具体地，收发包管理模块通过将持续无数据包的虚拟网卡队列标记为中断收包模式，让出pmd线程的轮询，减少轮询空队列消耗的cpu资源。当多个pmd线程的负载不均衡时，收发包管理模块将负载高的pmd上部分虚拟网卡队列由轮询收包模式切换为调度模式，并将处于调度模式的虚拟网卡队列切换到负载低的pmd上，并将该虚拟网卡队列的收包模式由调度模式改为轮询收包模式，从而实现线程间的负载均衡。
123.pmd管理模块通过机器学习算法，如lstm算法，对每个pmd线程的cpu资源利用率进行预测，并根据预测结果，周期地对pmd线程的数量进行预调整。
124.示例性地，可以参阅图5，图5为本技术实施例提供的一种虚拟网卡队列的收包模式之间切换示意图。如图5所示，虚拟网卡队列的收包模式之间的切换规则如下s1-s7所示。
125.s1，所有虚拟网卡队列的默认收包模式为轮询收包模式。
126.s2，轮询收包模式
→
中断收包模式：当pmd线程连续轮询一个虚拟网卡队列k次都没有收到数据包，则将这个虚拟网卡队列由轮询模式切换为中断模式。此后，该pmd线程不再轮询该虚拟网卡队列，而是依靠中断信号感知收包事件。
127.s3，中断收包模式
→
轮询收包模式：当切换为中断收包模式的虚拟网卡队列有数据包到来时，则将该虚拟网卡队列从中断中唤醒，从中断收包模式切换为轮询收包模式。
128.s4，轮询收包模式
→
调度模式：当多个pmd线程之间负载不均衡时，利用pmd调度模块的调度规则，负载高的pmd上部分虚拟网卡队列由轮询收包模式切换为调度模式，以将处于调度模式的虚拟网卡队列切换到负载低的pmd上，实现线程间的负载均衡。
129.s5，调度模式
→
轮询收包模式：处于调度模式的虚拟网卡队列被切换至新的pmd线程之后，该虚拟网卡队列由调度模式切换到轮询收包模式，由新的pmd线程对该虚拟网卡队列执行正常的轮询收包。
130.s6，中断收包模式
→
调度模式：不允许。加入中断收包模式的虚拟网卡队列不再影响收发包性能，不参加调度。
131.s7，调度模式
→
中断收包模式：不允许。新加入pmd线程的虚拟网卡队列采用轮询收包模式来进行收发数据包。
132.通过控制队列在轮询收包模式，中断收包模式和调度模式三种模式下的合理切换，能够同时解决多pmd线程多队列场景下的负载不均问题，以及轮询空队列浪费cpu资源的问题。
133.可以参阅图6，图6为本技术实施例提供的一种调整pmd数量的流程示意图。如图6所示，调整pmd数量的流程包括以下的步骤601-603。
134.步骤601，pmd管理模块记录每个pmd线程的cpu资源利用率轨迹。
135.具体地，cpu资源利用率是指在一定的时间段内，有效的cpu周期的数量与该时间段内cpu周期的总数之间的比值。有效的cpu周期的数量是指pmd线程处理虚拟网卡队列中的数据包所消耗的cpu周期的数量。pmd管理模块通过实时观测每个pmd线程的cpu资源利用率，可以记录得到一段时间内每个pmd线程的cpu资源利用率轨迹。
136.步骤602，基于lstm算法对每个pmd线程的cpu资源利用率进行预测。
137.简单来说，pmd管理模块对pmd线程的负载轨迹进行记录后，可以基于lstm算法，根据历史负载轨迹，对未来一段时间的pmd线程的负载进行预测。
138.步骤603，若预测得到pmd线程的平均cpu资源利用率大于overload阈值，则增加pmd线程的数量。
139.例如，当pmd管理模块预测到由于热点事件导致访问量增加时，或周期性地预测到周末的访问量大于工作日的访问量时，提前增加pmd线程的数量，以保证业务的可靠性。
140.步骤604，若预测得到pmd线程的平均cpu资源利用率小于underload阈值，则减少pmd线程的数量。
141.例如，当pmd管理模块识别到热点事件热度将要退去，访问量会减少，或识别到工作日的访问量小于周末的访问量时，pmd管理模块则提前减少pmd线程的数量，保证业务可靠性的同时减少cpu的消耗。
142.通过利用pmd线程在历史时间段内的cpu资源利用率，预测未来一段时间内pmd线程的负载情况。并且，在可预测的流量增大前，提前增加pmd的数量，提高业务处理能力，保证业务的稳定性。同时在预测到流量降低时，减少pmd的数量，避免计算资源的浪费。
143.在图1至图6所对应的实施例的基础上，为了更好的实施本技术实施例的上述方案，下面还提供用于实施上述方案的相关设备。
144.具体可以参阅图7，图7为本技术实施例提供的一种调度装置700的结构示意图，该调度装置700包括：获取单元701和处理单元702。所述处理单元702用于：在多个线程中确定
第一线程和第二线程，其中，所述多个线程均用于处理虚拟网卡队列中的数据包，所述第一线程的负载大于第一阈值，所述第二线程的负载小于第二阈值，所述第一阈值大于所述第二阈值；在所述第一线程所对应的多个虚拟网卡队列中确定第一队列，所述第一线程用于处理所述多个虚拟网卡队列中的数据包；将所述第一队列切换至第二线程，以使得所述第二线程处理所述第一队列中的数据包。
145.在一种可能的实现方式中，所述处理单元702还用于：将所述第一队列标记为调度模式，所述调度模式用于指示所述第一队列为待切换线程的队列；将处于调度模式的所述第一队列从所述第一线程切换至所述第二线程；将切换至所述第二线程的所述第一队列标记为轮询收包模式，所述轮询收包模式用于指示所述第二线程以轮询的方式处理所述第一队列中的数据包。
146.在一种可能的实现方式中，所述处理单元702还用于：在所述第一线程所对应的多个虚拟网卡队列中确定被标记为轮询收包模式的一个或多个虚拟网卡队列；在所述一个或多个虚拟网卡队列中确定所述第一队列。
147.在一种可能的实现方式中，所述处理单元702还用于：根据所述第一线程的负载和所述第二阈值，确定第一负载量，所述第一负载量为第一线程能够转移的最大负载量；根据所述第二线程的负载和所述第一阈值，确定第二负载量，所述第二负载量为第二线程能够接收的最大负载量；根据所述第一负载量和所述第二负载量确定所述第一队列，所述第一负载量和所述第二负载量均大于或等于所述第一队列对应的负载量。
148.在一种可能的实现方式中，所述处理单元702还用于：若所述第一线程连续轮询被标记为轮询收包模式的第二队列的次数大于第三阈值，且所述第一线程连续轮询所述第二队列的期间均没有接收到数据包，则将所述第二队列标记为中断收包模式；其中，所述多个虚拟网卡队列包括所述第二队列，所述中断收包模式用于指示所述第一线程在获取到所述第二队列的中断信号后，触发处理所述第二队列中的数据包。
149.在一种可能的实现方式中，所述处理单元702还用于：若所述第一线程获取到来自于被标记为中断收包模式的第三队列的中断信号，则将所述第三队列标记为轮询收包模式；其中，所述中断收包模式用于指示所述第一线程在获取到所述第三队列的中断信号后触发处理所述第三队列中的数据包，所述轮询收包模式用于指示所述第一线程以轮询的方式处理所述第三队列中的数据包。
150.在一种可能的实现方式中，所述获取单元701，用于获取所述多个线程在第一时间段内的负载；所述处理单元702还用于：根据所述多个线程在第一时间段内的负载预测所述多个线程在第二时间段的负载，所述第二时间段位于所述第一时间段之后；若所述多个线程在第二时间段的负载大于第四阈值，则创建新的线程，所述新的线程用于处理虚拟网卡队列中的数据包；若所述多个线程在第二时间段的负载小于第五阈值，则在所述多个线程中删除部分线程。
151.在一种可能的实现方式中，所述处理单元702还用于：在所述多个线程中确定待删除的线程和待保留的线程；将所述待删除的线程所对应的虚拟网卡队列切换到所述待保留的线程；删除所述待删除的线程。
152.在一种可能的实现方式中，所述第一线程的负载包括所述第一线程对应的处理器资源利用率。
153.本技术实施例提供的多线程转发的负载均衡方法具体可以由终端中的芯片来执行，该芯片包括：处理单元和通信单元，处理单元例如可以是处理器，通信单元例如可以是输入/输出接口、管脚或电路等。该处理单元可执行存储单元存储的计算机执行指令，以使服务器内的芯片执行上述图1至图6所示实施例描述的多线程转发的负载均衡方法。可选的，存储单元为芯片内的存储单元，如寄存器、缓存等，存储单元还可以是无线接入设备端内的位于芯片外部的存储单元，如只读存储器(read-only memory，rom)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，ram)等。
154.参照图8，本技术还提供了一种计算机可读存储介质，在一些实施例中，上述图3所公开的方法可以实施为以机器可读格式被编码在计算机可读存储介质上或者被编码在其它非瞬时性介质或者制品上的计算机程序指令。
155.图8示意性地示出根据这里展示的至少一些实施例而布置的示例计算机可读存储介质的概念性局部视图，示例计算机可读存储介质包括用于在计算设备上执行计算机进程的计算机程序。
156.在一个实施例中，计算机可读存储介质800是使用信号承载介质801来提供的。信号承载介质801可以包括一个或多个程序指令802，其当被一个或多个处理器运行时可以提供以上针对图2描述的功能或者部分功能。因此，例如，参考图3中所示的实施例，步骤301-303的一个或多个特征可以由与信号承载介质801相关联的一个或多个指令来承担。此外，图8中的程序指令802也描述示例指令。
157.在一些示例中，信号承载介质801可以包含计算机可读介质803,诸如但不限于，硬盘驱动器、紧密盘(cd)、数字视频光盘(dvd)、数字磁带、存储器、rom或ram等等。
158.在一些实施方式中，信号承载介质801可以包含计算机可记录介质804，诸如但不限于，存储器、读/写(r/w)cd、r/w dvd、等等。在一些实施方式中，信号承载介质801可以包含通信介质805,诸如但不限于，数字和/或模拟通信介质(例如，光纤电缆、波导、有线通信链路、无线通信链路、等等)。因此，例如，信号承载介质801可以由无线形式的通信介质805(例如，遵守ieee 802.9标准或者其它传输协议的无线通信介质)来传达。
159.一个或多个程序指令802可以是，例如，计算机可执行指令或者逻辑实施指令。在一些示例中，计算设备的计算设备可以被配置为，响应于通过计算机可读介质803、计算机可记录介质804、和/或通信介质805中的一个或多个传达到计算设备的程序指令802，提供各种操作、功能、或者动作。
160.应该理解，这里描述的布置仅仅是用于示例的目的。因而，本领域技术人员将理解，其它布置和其它元素(例如，机器、接口、功能、顺序、和功能组等等)能够被取而代之地使用，并且一些元素可以根据所期望的结果而一并省略。另外，所描述的元素中的许多是可以被实现为离散的或者分布式的组件的、或者以任何适当的组合和位置来结合其它组件实施的功能实体。
161.所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
162.在本技术所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件
可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
163.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
164.另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
165.所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种可以存储程序代码的介质。