一种基于智能网卡的RPC负载均衡方法

本发明属于计算机应用技术领域，特别是涉及一种基于智能网卡的以cpu核为粒度的远程过程调用(remoteprocedurecall，rpc)负载均衡方法。

背景技术：

在已有的rpc通信框架中，如何解决rpc负载不均衡问题以尽可能地提高搭建了rpc框架的系统(如dubbo、grpc、thrift等)整体的尾时延(即一个时间段内所有rpc请求中时延较长的部分)等性能指标，rpc负载均衡决策是其中重要影响因素之一。较优的rpc负载调度决策能够使负载均衡器将rpc请求较均匀地派发到各执行单元上，从而避免rpc请求负载不均衡带来较高的尾时延等问题。rpc负载调度技术一般应用在具有高吞吐、低延时需求的数据中心场景下。

大规模的数据密集型应用，如搜索引擎、电子商务等，依赖于大型数据中心的存储及计算资源来满足服务水平目标(slo)。由于这些应用体积往往比较庞大，应用开发者基于提高并行运算能力、优化资源配置及方便开发调试部署等因素的考量，通常采用微服务架构而不是单体应用架构来开发及部署这些应用。使用微服务架构开发的应用被分割成若干功能模块独立部署，此外各模块之间存在着若干个层级且各层级之间一般使用rpc进行通信，各层级之间的模块的频繁通信会带来较大的扇入扇出(fan-in，fan-out)，即某个rpc请求可能会调用多个rpc请求，使得微服务各层级模块之间的rpc通信数量极大地增多从而带来很大的rpc通信开销及很高的尾时延(上百微秒)。例如，一次典型bing搜索涉及到数千个节点的通信，其中搜索结果的返回时间取决于尾时延最长的rpc请求。由于微服务架构下的rpc通信数量较大，且不同类型负载的rpc请求的服务时间差异较大(如键值存储系统里的get请求的服务时间远小于set请求)，因此在该场景下计算单元处理rpc请求时容易出现负载不均衡的问题。若出现负载不均衡，则会带来较高的尾时延、降低cpu利用率等问题。

一次rpc负载派发的典型场景为，rpc负载调度器部署在一台服务器，负载调度器在接收客户端的rpc请求后根据负载调度决策将rpc请求转发到服务器集群中处理该请求的服务器，最终由该服务器来服务此次rpc请求。由于现有的服务器大都是多核服务器，因此服务rpc请求的服务器需要依赖某些方法以某种策略将接收到的rpc请求送往不同cpu核上处理。对此，当前多核服务器所使用的技术是集成在普通网卡上的rss(receivesidescale，扩展接收端)和flowdirector(流量引导器)。

rss技术通过硬件模块计算数据报头部五元组(源ip、目的ip、协议号、源端口号和目的端口号)的哈希值，以哈希值的低有效位(lsb)来索引存于网卡内部的保存cpu核id的哈希表，随后将rpc请求发往索引到的cpu核。rss的优点是让普通网卡能够将接收到rpc请求相对均匀地派发到多个cpu核上。rss的缺点是不同五元组哈希值的lsb可能相同，使得不同的rpc请求被发往同一个cpu核处理，导致负载失衡。flowdirector技术让普通网卡能够根据预先设置的规则(如设置传输层端口号与具体cpu核绑定的规则)，将接收到的rpc请求派发到与规则相匹配的cpu核上，使得rpc请求能被派发至处理该请求的cpu核上。flowdirector的优点是能够实现rpc请求的亲和性，即接收该rpc请求的cpu核将服务该请求，避免该cpu核将数据迁移至实际服务该请求的cpu核。flowdirector的缺点是当某个时间段某rpc请求持续地到来时，它根据该请求所匹配的规则仅将该rpc请求派发到指定的cpu核上，从而造成rpc负载失衡，如设置8080端口与cpu0绑定的规则后，所有的8080端口的rpc请求仅被派发至与该规则匹配的cpu0。。

现有的数据中心rpc负载调度的经典场景最大的问题是负载调度器以服务器为粒度(即将rpc请求派发给服务器，而不是派发给服务器中的某个cpu)来派发rpc请求，即rpc负载调度器调度rpc请求时以服务器为调度目标，此时服务器无论以rss还是flowdirector技术来接收rpc请求都会带来负载失衡问题。因此可以说以服务器为调度粒度是造成现有多核服务器使用普通网卡来接收rpc请求出现负载失衡的根本原因。为此，需要考虑一种比服务器级别更细粒度的负载调度方法。

数据中心是支持当今世界各种互联网服务的基础设施，其发展面临着硬件和应用两方面的挑战。在硬件方面，随着摩尔定律的失效，通用处理器的性能提升逐渐放缓；在应用方面，大数据与机器学习对算力(即cpu的计算能力)的需求与日俱增。不同于容易并行的web服务，大数据与机器学习需要计算节点间更多的通信，这推动了数据中心网络性能的快速提高。然而，数据中心的网络基础设施主要使用通用处理器进行软件处理，其性能落后于快速增长的网络、定制化计算硬件的性能。这导致网络i/o处理能力成为数据中心的性能瓶颈，此外高速网络i/o处理消耗服务器大量的cpu周期，使得留给应用逻辑的cpu周期和内存资源变得紧张。智能网卡(smartnic)就是在这一背景下产生的新兴硬件技术，现有的智能网卡产品有mellanox的bluefield、cavium的liquidio、博通的stingray以及华为的in200。

不同于传统的普通网卡，智能网卡集成了固定的网络处理硬件逻辑和可编程计算单元，同时具备高性能及灵活的可编程能力。这使得主机将部分任务卸载到智能网卡，实现“主机-智能网卡”之间进行协同计算成为可能。根据智能网卡的特性，在rpc场景中使用智能网卡带来了以下好处：(1)智能网卡具备的临近端口(neardata)能力允许在请求到达主机、消耗任何主机资源并遭受额外的延迟之前做出更优的负载均衡决策；(2)智能网卡的计算能力和存储能力能实现比较灵活的负载均衡决策；(3)智能网卡做rpc负载调度，使得主机cpu只需专注处理rpc请求，从而解放主机cpu的部分算力并减少主机cpu调度rpc请求带来的上下文切换开销。现有的智能网卡可以运行完整功能的通用操作系统，开发者可以基于运行于智能网卡之上的操作系统，利用智能网卡的软硬件资源做相应开发。

因此，现有的rpc负载调度方法由于其以服务器为粒度来派发rpc请求，导致服务器使用现有的普通网卡接收rpc请求时带来rpc请求负载的不均衡问题。根据公开可查的信息，目前新型的智能网卡只用于虚拟化、降低能耗等场合，还没有将智能网卡用于rpc负载均衡调度的技术方案的公开报导。

技术实现要素：

本发明要解决的技术问题是，调度rpc请求时由于以服务器级别的调度粒度过粗所导致的负载不均衡问题。现有负载调度粒度一般为服务器级别，使用普通网卡的rss或者flowdirector技术均无法做到cpu核负载均衡，最终导致rpc请求尾时延较高(一般负载均衡时为数百微秒，如果负载失衡则可能达到数千微秒，甚至更高)。

本发明的技术方案是：包括rpc派发过程和rpc反馈过程。所述rpc派发过程包括：位于智能网卡的n个派发模块并行地接收多客户端发送的rpc请求，并行地出队无锁空闲算力队列元素并据此将rpc请求派发至相应空闲的主机服务器cpu核；所述rpc反馈过程包括：位于主机服务器的rpc反馈发送模块构造反馈数据包发送至位于智能网卡的rpc反馈接收模块。本方案能够有效地避免多线程派发模块对全局的无锁空闲算力队列访问带来加锁开销，也避免了对反馈信息执行遍历操作以找到最空闲cpu核的高额开销，最终实现rpc请求在主机服务器端多cpu核上的负载均衡，降低rpc尾时延。

本发明包括以下步骤：

第一步，构建基于智能网卡的rpc负载均衡系统：

基于智能网卡的rpc负载均衡系统由一个智能网卡(智能网卡上面有q个核，运行通用商用操作系统(如centos)，q为正整数。各个模块占用不同的核来并行运行)、一台主机服务器、mm个客户端组成，mm为正整数。智能网卡插在主机服务器的pcie总线，其中智能网卡和主机服务器之间通过高性能dpdk(dataplanedevelopmentkit，数据平面开发套件(由intel公司开发))网络协议栈来通信。智能网卡上安装一个无锁空闲算力队列、n个rpc派发模块和m个rpc反馈接收模块，其中n个rpc派发模块和m个rpc反馈接收模块各占用智能网卡上不同的核。n为正整数，n个rpc派发模块与n个智能网卡的cpu核一一映射。m为正整数，m个rpc反馈接收模块与m个智能网卡的cpu核一一映射。其中n+m＝q。主机服务器包含p个cpu核，p为正整数。主机服务器上安装有一个服务进程，服务进程占用s个主机cpu核以及s个接收队列，s为正整数且s≤p，其中第s个主机cpu核与第s个接收队列相绑定，第s个接收队列用于接收智能网卡的rpc派发模块发送过来的rpc请求。服务进程包含s个服务线程，每个服务线程占用一个主机cpu核，每个服务线程包含一个rpc服务模块以及一个rpc反馈发送模块，1≤s≤s，将第s个服务线程中的rpc服务模块命名为第s个rpc服务模块，将第s个服务线程中的rpc反馈发送模块命名为第s个rpc反馈发送模块。mm个客户端与智能网卡通过以太网相连。智能网卡从网卡端口接收mm个客户端发送过来的rpc，将所有rpc请求均匀地发送到n个rpc派发模块各自的缓存，mm为正整数。n个rpc派发模块并行地从空闲算力队列出队元素，并行地根据元素值修改各自rpc请求的目的端口号，将rpc请求的目的端口号和rpc请求通过dpdk网络协议栈途经pcie总线送往主机服务器。主机服务器中有p个cpu核，使用flowdirector技术将rpc请求的目的端口号与接收队列绑定，并行地依据各rpc请求的目的端口号8001、8002、…、800s、…800s将rpc请求分别存贮至第1个接收队列、第2个接收队列、…、第s个接收队列、…、第s个接收队列。8001、8002、…、800s、…800s为目的端口号的编号。s个服务线程并行工作，工作流程相同，其中第s个rpc服务模块从第s个接收队列获取并处理rpc请求，将处理rpc请求的反馈信息串行地传递至本服务线程内部的第s个rpc反馈发送模块。第s个rpc反馈发送模块构造反馈数据包，地将反馈数据包通过dpdk网络栈途经pcie总线送往智能网卡。位于智能网卡的m个rpc反馈接收模块并行工作，工作流程相同，第m个rpc反馈接收模块接收反馈数据包，对反馈数据包进行解析，得到反馈信息，将反馈信息入队无锁空闲算力队列。1≤m≤m。

基于智能网卡的rpc负载均衡系统需要依据主机服务器反馈的cpu核状态信息来做派发决策，其中每个cpu核状态信息即为反馈信息，每个cpu核每处理固定数目rpc请求即产生一个反馈信息，一个cpu核产生的多个反馈信息都存储在无锁空闲算力队列中。无锁空闲算力队列长度为l，l为正整数，每个反馈信息即为无锁空闲算力队列的一个元素。无锁空闲算力队列上的每个元素由结构体feedback_info描述，其中结构体feedback_info有两个域，port和credit(credit用来度量空闲算力)。域port存贮与主机服务器接收队列绑定的传输层端口号(从端口号就能对应到主机服务器cpu核)，为16比特的整型；域credit存贮与传输层端口号绑定的cpu核已处理的固定rpc请求的数目，也为16比特的整型，域credit可度量该cpu核具有的空闲算力，其中无锁空闲算力队列中第s个cpu核产生的所有元素的credit之和即为第s个cpu核所空闲的总算力。无锁空闲算力队列与m个rpc反馈接收模块和n个rpc派发模块相连，由m个rpc反馈接收模块作为生产者并行地添加元素，由n个rpc派发模块作为消费者并行地读取元素。使用无锁队列可以避免m个rpc反馈接收模块和n个rpc派发模块加锁串行访问队列带来开销。无锁空闲算力队列的一个元素表示一个主机服务器cpu核的空闲算力。每个主机服务器cpu核可产生多个元素，即cpu核与其产生的无锁空闲算力队列中的元素是一对多的关系。在同一个时间段内，若主机服务器第s个cpu核所处理的各rpc请求服务时间越短，在该时间段内第s个cpu核产生的反馈数据包越多，则无锁空闲算力队列中包含主机服务器第s个cpu核反馈信息的元素越多，代表第s个cpu核越空闲，第n个rpc派发模块下一次出队的元素由第s个cpu核产生的概率越大，使得第n个rpc派发模块下一次将rpc请求派发至第s个cpu核的概率也越大，所以第s个cpu核获得rpc请求概率越大，实现负载均衡的几率也越大。第n个rpc派发模块所出队的元素即代表哪个cpu核当前空闲的概率最大(如出队元素的port为800s，则第800s个端口对应的主机服务器的第s个cpu核空闲)，以避免n个rpc派发模块各自遍历反馈信息以找到最空闲值所带来的开销。

rpc派发模块基于dpdk网络协议栈开发，运行在智能网卡。n个rpc派发模块与无锁空闲算力队列相连，随机地接收mm个客户端发送的rpc请求，根据无锁空闲算力队列中出队的元素的域port来派发rpc请求到选中的cpu核，即若port域为800s，则派发rpc请求到第s个cpu核。其中从mm个客户端接收的mm个rpc请求随机地均分给n个rpc派发模块处理。其中第n个rpc派发模块出队的元素被缓存在第n个rpc派发模块私有的缓存变量cache_info中，变量cache_info的结构与结构体feedback_info的元素完全相同，每个rpc派发模块以cache_info的域port作为当前rpc请求应当送往的主机第s个cpu核的传输层端口号，以域credit作为第n个派发模块能往主机第s个cpu核派发的rpc请求的数量。1≤n≤n。

rpc反馈发送模块基于dpdk网络协议栈开发，部署在主机服务器。主机服务器有s个rpc反馈发送模块及s个rpc服务模块。其中第s个rpc反馈发送模块与第s个rpc服务模块相连，第s个rpc反馈发送模块从第s个rpc反馈发送模块的rpc服务模块获得第s个cpu核空闲算力信息，即第s个rpc服务模块已处理的数据包个数，构造包含结构体feedback_info信息的反馈数据包，并将反馈数据包随机地反馈至第m个rpc反馈接收模块。第s个rpc反馈发送模块构造及发送反馈数据包这个过程的时机受第s个rpc服务模块已处理rpc请求数量限制，rpc服务模块使用统计变量processed_count(16比特整型)来记录已处理数据包，每处理阈值processed_threshold个数据包后再构造并发送反馈数据包。为了提高空闲cpu核获得rpc请求处理的概率，即提高空闲cpu核产生的反馈信息在无锁空闲算力队列中的占比，每个rpc反馈发送模块将当前cpu核负载大小cur_load(16比特整型)与接收队列总长度乘以load_proport，load_proport是调整动态阈值processed_threshold的cpu核负载大小占接收队列总长度的比例相比，根据两者比较结果动态调整阈值processed_threshold以调整生成反馈数据包的频率。1≤s≤s。

rpc反馈接收模块基于dpdk网络栈开发，部署在智能网卡。m个rpc反馈接收模块与无锁空闲算力队列相连。m个rpc反馈接收模块并行地从主机服务器的rpc反馈发送模块接收反馈数据包，解析反馈数据包中的结构体feedback_info，将结构体feedback_info作为一个元素存储至无锁空闲算力队列。1≤m≤m。一般mm远大于n、m、s。

第二步，对基于智能网卡的rpc负载均衡系统进行初始化：

2.1主机服务器创建一个服务进程，其中服务进程包含s个rpc服务模块以及s个rpc反馈发送模块，进行以下初始化工作：每个rpc反馈发送模块设置初始化统计变量processed_count为零，设置当前cpu核接收队列的长度为ql，设置当前cpu核负载大小cur_load为0，设置线程私有的阈值processed_threshold为正整数，一般为经验值【ql/16】，设置调整动态阈值processed_threshold的cpu核负载大小占接收队列总长度的比例load_proport为0＜load_proport＜1，一般设置为经验值【20％】。设置变量cache_threshold等于processed_threshold。

2.2智能网卡使用内部dram创建无锁空闲算力队列，其中无锁空闲算力队列可包含总元素数量为l，l＝(s×1个cpu核对应接收队列长度/processed_threshold)×2；l表示在初始状态下，在阈值processed_threshold未被改变时，两倍的主机服务器所有cpu核所能产生的元素之和；无锁空闲算力队列中每个元素的值，即结构体feedback_info中的域port初始化为与主机cpu核绑定的传输层端口号，其中每个端口号所对应的元素数量(第800s端口号对应cpu核可产生多个元素)为(1个cpu核对应接收队列长度/阈值processed_threshold)。结构体feedback_info中的域credit均初始化为阈值processed_threshold。初始化cache_info的域port及域credit均为0。

2.3智能网卡创建n个rpc派发模块分别运行在智能网卡上的n个cpu核，每个rpc派发模块在首次接收rpc请求时从无锁空闲算力队列中出队一个元素来获取派发信息再执行派发操作。智能网卡创建m个rpc反馈接收模块分别运行在智能网卡上的m个cpu核。

第三步，n个rpc派发模块对prc请求进行派发，具体步骤为：

3.1n个rpc派发模块从智能网卡的物理端口并行地接收mm个客户端发送的rpc请求，n个rpc派发模块并行地对rpc请求的网络数据包头进行拆包，获得rpc请求的目的端口号地址。n个rpc派发模块的工作流程相同。第n个rpc派发模块对rpc请求进行派发的流程是：

3.2第n个rpc派发模块判断第n个rpc派发模块私有变量cache_info的域credit是否为零。若私有变量cache_info的域credit为零，则第n个派发模块从无锁空闲算力队列出队一个元素，并将该元素缓存到cache_info，转步骤3.3；

若第n个rpc派发模块私有变量cache_info的域credit不为零，则直接执行步骤3.3；

3.3根据rpc请求的目的端口号地址将变量cache_info的域port赋值到rpc请求的目的端口号，将cache_info的域credit减1，其中域port(假设为800s)所绑定的cpu核为最空闲cpu核；

3.4第n个rpc派发模块将目的端口号修改成了800s的rpc请求派发至主机服务器的服务进程的第s个接收队列，其中rpc请求的目的端口号800s与第s个接收队列由flowdirector技术绑定。

第四步，s个rpc服务模块并行从n个rpc派发模块接收rpc请求并由s个rpc反馈发送模块各自构造并发送反馈数据包：

4.1主机服务器的s个rpc服务模块并行地从各rpc服务模块的相应接收队列接收rpc请求，并处理rpc请求，将统计变量processed_count加1，随后将processed_count传送至与rpc服务模块对应的rpc反馈发送模块；s个rpc服务模块的工作流程相同，s个rpc反馈发送模块的工作流程也相同。下面以第s个rpc服务模块和第s个rpc反馈发送模块处理rpc请求、构造并发送反馈数据包的流程是：

4.2第s个rpc反馈发送模块从第s个rpc服务模块接收统计变量processed_count；

4.3第s个rpc反馈发送模块获取接收队列上缓存的rpc请求数目，得到当前cpu核的负载大小cur_load，若cur_load>ql×load_proport，令processed_threshold＝cache_threshold，转4.4；若cur_load≤ql×load_proport，令processed_threshold＝processed_threshold/2，转4.4；其中阈值processed_threshold除以2是为了增大生成元素的频率，以提高当前空闲核所产生元素占无锁空闲算力队列中总元素的比例。

4.4若统计变量processed_count≥阈值processed_threshold，说明当前第s个rpc服务模块对应cpu核已空闲了大于等于阈值processed_threshold大小的算力，第s个rpc反馈发送模块构造一个包含结构体feedback_info的反馈数据包，其中域port赋值为与当前主机cpu核绑定的传输层端口号，域credit赋值为阈值processed_threshold的大小，即当前cpu核已空闲算力数目，并随机地选择第m个rpc反馈接收模块来接收反馈数据包，并发送反馈数据包。令processed_count＝processed_count-processed_threshold，将阈值processed_threshold传送回第s个rpc服务模块，转第五步；

若统计变量processed_count<阈值processed_threshold，则第s个rpc反馈发送模块将统计变量processed_count加1，并将processed_count传送回rpc服务模块。随后跳转至步骤4.1继续执行。

第五步，m个rpc反馈接收模块并行且随机地接收并解析rpc反馈发送模块发送的反馈数据包，将解析结果并行地存入无锁空闲算力队列。m个rpc反馈接收模块的工作流程相同。下面以第m个rpc反馈接收模块为例进行说明：

5.1第m个rpc反馈接收模块接收从rpc反馈发送模块发送来的反馈数据包；

5.2第m个rpc反馈接收模块将接收到的反馈数据包的网络包头进行拆包，获得保存在反馈数据包的结构体feedback_info，其中域port为800s对应第s个主机cpu核；

5.3第m个rpc反馈接收模块将获取到的表示第s个主机cpu核空闲算力的feedback_info存入无锁空闲算力队列。

采用本发明可以达到以下技术效果：

(1)本发明部署于智能网卡的无锁空闲算力队列能支持部署于智能网卡的多个rpc派发模块并发访问，从而避免使用有锁数据结构保存主机服务器cpu核状态信息所带来的锁竞争的开销；

(2)本发明第三步，部署于智能网卡的rpc派发模块依据从无锁空闲算力队列出队的结构体feedback_info所保存的域port来将rpc请求派发至指定cpu核。这是基于无锁空闲算力队列里的一个元素代表着某cpu核的空闲算力，以及越空闲cpu核生成的反馈信息越多两条原则。当无锁空闲算力队列里保存某cpu核对应反馈信息的元素越多，派发模块从队列中获取到空闲cpu核反馈信息的概率越大，派发模块往空闲cpu核派发请求的概率越大。因此本发明第三步通过rpc派发模块下一次出队的、且最大概率是空闲cpu核所产生的元素，并根据该元素的域port将rpc请求派发至该空闲cpu核实现了以cpu核为粒度的rpc请求负载均衡。当rpc请求服务时间均值为20微秒时，在客户端生成900krps(kilorequestpersecond，每秒千请求数)负载的情况下，使用本发明可以将普通方法的尾时延最多降低88％；

(3)本发明第四步，部署于主机服务器端的s个rpc反馈发送模块基于阈值processed_threshold来做反馈决策，而不是为每个rpc请求单独生成反馈信息，避免了rpc反馈发送模块反馈频率过快生成过多的反馈信息到无锁空闲算力队列，导致对无锁空闲算力队列产生过多入队和出队操作带来的开销，减少了n个rpc派发模块出队无锁空闲算力队列与m个rpc反馈接收模块入队无锁空闲算力队列频次过高所带来的开销；

(4)本发明第四步，部署于主机服务器的rpc反馈发送模块通过根据当前cpu核负载大小来设置动态阈值processed_threshold来改变rpc反馈发送模块的反馈频次，此举考虑cpu核负载较低时有着更快反馈需求的因素，避免使用固定反馈频率应用到cpu核负载任意负载大小的情况带来的空闲cpu核未能及时获得rpc请求的问题，从而使得rpc派发模块的rpc负载调度更加及时，实现了更优的负载均衡。

附图说明

图1为本发明第一步构建的基于智能网卡的rpc负载均衡系统逻辑结构图；

图2为本发明总体流程图。

图3为本发明的测试实验结果图。图3(a)是客户端生成的rpc的服务时间遵循指数分布(平均服务时间20μs)的测试结果图。图3(b)是客户端生成的rpc服务时间遵循双峰分布(平均服务时间20μs，其中50％的rpc请求为10μs，50％的rpc请求为30μs)的测试结果图。图3(c)是客户端生成的rpc服务时间遵循双峰分布(平均服务时间20μs，其中90％的rpc请求为10μs，10％的rpc请求为110μs)的测试结果图。

具体实施方式

下面结合说明书附图和具体的实施例对本发明作进一步描述，但并不因此而限制本发明的保护范围。

本发明总体流程如图2所示，包括以下步骤：

第一步，构建基于智能网卡的rpc负载均衡系统：

基于智能网卡的rpc负载均衡系统如图1所示，由一个智能网卡(智能网卡上面有q个核，运行centos，q为正整数。各个模块占用不同的核来并行运行)、一台主机服务器、mm个客户端组成，mm为正整数。智能网卡插在主机服务器的pcie总线，其中智能网卡和主机服务器之间通过高性能dpdk网络协议栈来通信。智能网卡上安装一个无锁空闲算力队列、n个rpc派发模块和m个rpc反馈接收模块，其中n个rpc派发模块和m个rpc反馈接收模块各占用智能网卡上不同的核。n为正整数，n个rpc派发模块与n个智能网卡的cpu核一一映射。m为正整数，m个rpc反馈接收模块与m个智能网卡的cpu核一一映射。其中n+m＝q。主机服务器包含p个cpu核，p为正整数。主机服务器上安装有一个服务进程，服务进程占用s个主机cpu核以及s个接收队列，s为正整数且s≤p，其中第s个主机cpu核与第s个接收队列相绑定，第s个接收队列用于接收智能网卡的rpc派发模块发送过来的rpc请求。服务进程包含s个服务线程，每个服务线程占用一个主机cpu核，每个服务线程包含一个rpc服务模块以及一个rpc反馈发送模块，1≤s≤s，将第s个服务线程中的rpc服务模块命名为第s个rpc服务模块，将第s个服务线程中的rpc反馈发送模块命名为第s个rpc反馈发送模块。mm个客户端与智能网卡通过以太网相连。智能网卡从网卡端口接收mm个客户端发送过来的rpc，将所有rpc请求均匀地发送到n个rpc派发模块各自的缓存，mm为正整数。n个rpc派发模块并行地从空闲算力队列出队元素，并行地根据元素值修改各自rpc请求的目的端口号，将rpc请求的目的端口号和rpc请求通过dpdk网络协议栈途经pcie总线送往主机服务器。主机服务器中有p个cpu核，使用flowdirector技术将rpc请求的目的端口号与接收队列绑定，并行地依据各rpc请求的目的端口号8001、8002、…、800s、…800s将rpc请求分别存贮至第1个接收队列、第2个接收队列、…、第s个接收队列、…、第s个接收队列。8001、8002、…、800s、…800s为目的端口号的编号。s个服务线程并行工作，工作流程相同，其中第s个rpc服务模块从第s个接收队列获取并处理rpc请求，将处理rpc请求的反馈信息串行地传递至本服务线程内部的第s个rpc反馈发送模块。第s个rpc反馈发送模块构造反馈数据包，地将反馈数据包通过dpdk网络栈途经pcie总线送往智能网卡。位于智能网卡的m个rpc反馈接收模块并行工作，工作流程相同，第m个rpc反馈接收模块接收反馈数据包，对反馈数据包进行解析，得到反馈信息，将反馈信息入队无锁空闲算力队列。1≤m≤m。

基于智能网卡的rpc负载均衡系统需要依据主机服务器反馈的cpu核状态信息来做派发决策，其中每个cpu核状态信息即为反馈信息，每个cpu核每处理固定数目rpc请求即产生一个反馈信息，一个cpu核产生的多个反馈信息都存储在无锁空闲算力队列中。无锁空闲算力队列长度为l，l为正整数，每个反馈信息即为无锁空闲算力队列的一个元素。无锁空闲算力队列上的每个元素由结构体feedback_info描述，其中结构体feedback_info有两个域，port和credit。域port存贮与主机服务器接收队列绑定的传输层端口号，为16比特的整型；域credit存贮与传输层端口号绑定的cpu核已处理的固定rpc请求的数目，也为16比特的整型，域credit可度量该cpu核具有的空闲算力，其中无锁空闲算力队列中第s个cpu核产生的所有元素的credit之和即为第s个cpu核所空闲的总算力。无锁空闲算力队列与m个rpc反馈接收模块和n个rpc派发模块相连，由m个rpc反馈接收模块作为生产者并行地添加元素，由n个rpc派发模块作为消费者并行地读取元素。使用无锁队列可以避免m个rpc反馈接收模块和n个rpc派发模块加锁串行访问队列带来开销。无锁空闲算力队列的一个元素表示一个主机服务器cpu核的空闲算力。每个主机服务器cpu核可产生多个元素，即cpu核与其产生的无锁空闲算力队列中的元素是一对多的关系。在同一个时间段内，若主机服务器第s个cpu核所处理的各rpc请求服务时间越短，在该时间段内第s个cpu核产生的反馈数据包越多，则无锁空闲算力队列中包含主机服务器第s个cpu核反馈信息的元素越多，代表第s个cpu核越空闲，第n个rpc派发模块下一次出队的元素由第s个cpu核产生的概率越大，使得第n个rpc派发模块下一次将rpc请求派发至第s个cpu核的概率也越大，所以第s个cpu核获得rpc请求概率越大，实现负载均衡的几率也越大。第n个rpc派发模块所出队的元素即代表哪个cpu核当前空闲的概率最大，以避免n个rpc派发模块各自遍历反馈信息以找到最空闲值所带来的开销。

rpc派发模块基于dpdk网络协议栈开发，运行在智能网卡。n个rpc派发模块与无锁空闲算力队列相连，随机地接收mm个客户端发送的rpc请求，根据无锁空闲算力队列中出队的元素的域port来派发rpc请求到选中的cpu核，即若port域为800s，则派发rpc请求到第s个cpu核。其中从mm个客户端接收的mm个rpc请求随机地均分给n个rpc派发模块处理。其中第n个rpc派发模块出队的元素被缓存在第n个rpc派发模块私有的缓存变量cache_info中，变量cache_info的结构与结构体feedback_info的元素完全相同，每个rpc派发模块以cache_info的域port作为当前rpc请求应当送往的主机第s个cpu核的传输层端口号，以域credit作为第n个派发模块能往主机第s个cpu核派发的rpc请求的数量。1≤n≤n。

rpc反馈发送模块基于dpdk网络协议栈开发，部署在主机服务器。主机服务器有s个rpc反馈发送模块及s个rpc服务模块。其中第s个rpc反馈发送模块与第s个rpc服务模块相连，第s个rpc反馈发送模块从第s个rpc反馈发送模块的rpc服务模块获得第s个cpu核空闲算力信息，即第s个rpc服务模块已处理的数据包个数，构造包含结构体feedback_info信息的反馈数据包，并将反馈数据包随机地反馈至第m个rpc反馈接收模块。第s个rpc反馈发送模块构造及发送反馈数据包这个过程的时机受第s个rpc服务模块已处理rpc请求数量限制，rpc服务模块使用统计变量processed_count(16比特整型)来记录已处理数据包，每处理阈值processed_threshold个数据包后再构造并发送反馈数据包。为了提高空闲cpu核获得rpc请求处理的概率，即提高空闲cpu核产生的反馈信息在无锁空闲算力队列中的占比，每个rpc反馈发送模块将当前cpu核负载大小cur_load(16比特整型)与接收队列总长度乘以load_proport，load_proport是调整动态阈值processed_threshold的cpu核负载大小占接收队列总长度的比例相比，根据两者比较结果动态调整阈值processed_threshold以调整生成反馈数据包的频率。1≤s≤s。

rpc反馈接收模块基于dpdk网络栈开发，部署在智能网卡。m个rpc反馈接收模块与无锁空闲算力队列相连。m个rpc反馈接收模块并行地从主机服务器的rpc反馈发送模块接收反馈数据包，解析反馈数据包中的结构体feedback_info，将结构体feedback_info作为一个元素存储至无锁空闲算力队列。1≤m≤m。

第二步，对基于智能网卡的rpc负载均衡系统进行初始化：2.1主机服务器创建一个服务进程，其中服务进程包含s个rpc服务模块以及s个rpc反馈发送模块，进行以下初始化工作：每个rpc反馈发送模块设置初始化统计变量processed_count为零，设置当前cpu核接收队列的长度为ql，设置当前cpu核负载大小cur_load为0，设置线程私有的阈值processed_threshold为正整数，一般为经验值【ql/16】，设置调整动态阈值processed_threshold的cpu核负载大小占接收队列总长度的比例load_proport为0＜load_proport＜1，一般设置为经验值【20％】。设置变量cache_threshold等于processed_threshold。

2.2智能网卡使用内部dram创建无锁空闲算力队列，其中无锁空闲算力队列可包含总元素数量为l，l＝(s×1个cpu核对应接收队列长度/processed_threshold)×2；l表示在初始状态下，在阈值processed_threshold未被改变时，两倍的主机服务器所有cpu核所能产生的元素之和；无锁空闲算力队列中每个元素的值，即结构体feedback_info中的域port初始化为与主机cpu核绑定的传输层端口号，其中每个端口号所对应的元素数量(第800s端口号对应cpu核可产生多个元素)为(1个cpu核对应接收队列长度/阈值processed_threshold)。结构体feedback_info中的域credit均初始化为阈值processed_threshold。初始化cache_info的域port及域credit均为0。

2.3智能网卡创建n个rpc派发模块分别运行在智能网卡上的n个cpu核，每个rpc派发模块在首次接收rpc请求时从无锁空闲算力队列中出队一个元素来获取派发信息再执行派发操作。智能网卡创建m个rpc反馈接收模块分别运行在智能网卡上的m个cpu核。

第三步，n个rpc派发模块对prc请求进行派发，具体步骤为：

3.1n个rpc派发模块从智能网卡的物理端口并行地接收mm个客户端发送的rpc请求，n个rpc派发模块并行地对rpc请求的网络数据包头进行拆包，获得rpc请求的目的端口号地址。n个rpc派发模块的工作流程相同。第n个rpc派发模块对rpc请求进行派发的流程是：

3.2第n个rpc派发模块判断第n个rpc派发模块私有变量cache_info的域credit是否为零。若私有变量cache_info的域credit为零，则第n个派发模块从无锁空闲算力队列出队一个元素，并将该元素缓存到cache_info，转步骤3.3；

若第n个rpc派发模块私有变量cache_info的域credit不为零，则直接执行步骤3.3；

3.3根据rpc请求的目的端口号地址将变量cache_info的域port赋值到rpc请求的目的端口号，将cache_info的域credit减1，其中域port(假设为800s)所绑定的cpu核为最空闲cpu核；

3.4第n个rpc派发模块将目的端口号修改成了800s的rpc请求派发至主机服务器的服务进程的第s个接收队列，其中rpc请求的目的端口号800s与第s个接收队列由flowdirector技术绑定。

第四步，s个rpc服务模块并行从n个rpc派发模块接收rpc请求并由s个rpc反馈发送模块各自构造并发送反馈数据包：

4.1主机服务器的s个rpc服务模块并行地从各rpc服务模块的相应接收队列接收rpc请求，并处理rpc请求，将统计变量processed_count加1，随后将processed_count传送至与rpc服务模块对应的rpc反馈发送模块；s个rpc服务模块的工作流程相同，s个rpc反馈发送模块的工作流程也相同。下面以第s个rpc服务模块和第s个rpc反馈发送模块处理rpc请求、构造并发送反馈数据包的流程是：

4.2第s个rpc反馈发送模块从第s个rpc服务模块接收统计变量processed_count；

4.3第s个rpc反馈发送模块获取接收队列上缓存的rpc请求数目，得到当前cpu核的负载大小cur_load，若cur_load>ql×load_proport，令processed_threshold＝cache_threshold，转4.4；若cur_load≤ql×load_proport，令processed_threshold＝processed_threshold/2，转4.4；

4.4若统计变量processed_count≥阈值processed_threshold，说明当前第s个rpc服务模块对应cpu核已空闲了大于等于阈值processed_threshold大小的算力，第s个rpc反馈发送模块构造一个包含结构体feedback_info的反馈数据包，其中域port赋值为与当前主机cpu核绑定的传输层端口号，域credit赋值为阈值processed_threshold的大小，即当前cpu核已空闲算力数目，并随机地选择第m个rpc反馈接收模块来接收反馈数据包，并发送反馈数据包。令processed_count＝processed_count-processed_threshold，将阈值processed_threshold传送回第s个rpc服务模块，转第五步；

若统计变量processed_count<阈值processed_threshold，则第s个rpc反馈发送模块将统计变量processed_count加1，并将processed_count传送回rpc服务模块。随后跳转至步骤4.1继续执行。

第五步，m个rpc反馈接收模块并行且随机地接收并解析rpc反馈发送模块发送的反馈数据包，将解析结果并行地存入无锁空闲算力队列。m个rpc反馈接收模块的工作流程相同。下面以第m个rpc反馈接收模块为例进行说明：

5.1第m个rpc反馈接收模块接收从rpc反馈发送模块发送来的反馈数据包；

5.2第m个rpc反馈接收模块将接收到的反馈数据包的网络包头进行拆包，获得保存在反馈数据包的结构体feedback_info，其中域port为800s对应第s个主机cpu核；

5.3第m个rpc反馈接收模块将获取到的表示第s个主机cpu核空闲算力的feedback_info存入无锁空闲算力队列。

本发明效果通过以下真实环境中的实验进行说明：

为了验证本发明的效果，本发明效果测试在真实环境中进行，该环境使用多台客户端模拟云环境中面向多用户高吞吐量的场景。其中所使用到的设备型号及数量为：客户端包含4台主机，每台主机的cpu型号为8核intelcorei7-4790；智能网卡为1台，所采用型号为mellanox公司的bluefield-mbf1l516a-cscat，其中所使用cpu核型号为16核armv8a72cores(64-bit)；主机服务器为1台，所使用cpu型号为16核intelxeonplatinum8160。

在本测试实验中各参数设置如下：客户端为4台(mm＝4)，智能网卡q(q＝16)个cpu核，n(n＝14)个rpc派发模块，m(m＝2)个rpc反馈接收模块。主机服务器包含p(p＝16)个cpu核。主机服务器安装1个服务进程，1个服务进程包含s(s＝16)个cpu核，s(s＝16)个接收队列，s(s＝16)个服务线程，s(s＝16)个rpc服务模块，s(s＝16)个rpc反馈发送模块。主机cpu核对应每个接收队列的长度为ql(ql＝1024)。阈值processed_threshold设置为经验值64(ql/16)。无锁空闲算力队列长度为l(l＝2×s×ql/processed_threshold＝512)，初始化其中256个元素，其中256个元素的域port值依次为1至16，域credit值均为64。load_proport设置为20％。

本测试实验设置每台客户端发送100krps的rpc请求，并设置3轮测试对比实验，其中设置rpc请求服务时间选择遵循三类有代表性的分布，即指数分布、倾斜性较小(双峰之间的高度差较小)的双峰分布以及倾斜性较大(双峰之间的高度差较大)的双峰分布(负载服务时间所遵循分布表示每个rpc请求所应被服务时间，即被处理时间，所遵循的分布。常用上述分布来模拟不同应用的rpc请求负载，如使用倾斜性较大的双峰分布来模拟键值存储系统的get请求和set请求)。设置三类分布的平均服务时间均为20μs。在本测试实验中，对比实验对象为背景技术所介绍的rss技术。测试实验结果如图3所示，其中本发明对应曲线为“with-balancer”，rss技术对应曲线为“with-rss”。

如图3的三个子图，每个子图的横坐标为4个客户端一起每秒生成的rpc请求数目的总大小(如横坐标为200krps时，每个客户端发送50krps的rpc请求)，单位为krps(每秒千请求数)，纵坐标为在4个客户端每秒生成某rpc请求数目且持续足够长时间时，所有rpc请求时延排序后的第99％个长尾时延(如4个客户端每秒生成100个rpc请求，经过10秒后一共生成1000个rpc请求。待所有rpc请求被处理完，将得到的所有rpc请求的尾时延按升序排序后，第999个尾时延数值即是99％尾时延)。图3(a)的客户端rpc请求遵循平均时间为20μs的指数分布。图3(b)的客户端rpc请求遵循平均时间为20μs，且设置较低的双峰倾斜度，为bimodal(50％-10,50％-30)，即两个峰占比各为50％，本实验中10μs的请求与30μs的请求占比各为50％。图3(c)的客户端rpc请求遵循平均时间为20μs，且设置较高的双峰倾斜度，为bimodal(90％-10,10％-110)，即两个峰占比分别为90％和10％，本实验中10μs的请求和110μs的请求占比分别为90％和10％。

根据图3可知，当rpc请求数目较低时(小于600krps)，使用rss技术做rpc请求派发时的性能稍好，这有两个原因：(1)rss技术使用网卡的硬件模块而非软件模块实现，因此在派发rpc请求时开销较小；(2)本发明基于智能网卡的rpc负载均衡方法基于智能网卡的负载调度器对无锁队列的访问会带来一定开销，此外对于无锁队列中元素的管理，如申请及释放空间，也会带来一定开销。

而在rpc请求数目较高时(大于600krps)，本发明的性能较好，这是因为rss技术是基于网络数据包头五元组哈希值的lsb来派发rpc请求到不同主机cpu核，因此存在多个rpc请求的哈希值lsb相同的情况，使得多个rpc请求派发至同一个主机cpu核，从而导致主机cpu核负载出现不均衡情况。当出现负载不均衡时，即出现cpu核空闲时，会使得主机cpu核所能处理的总负载量无法提升，导致尾时延迅速升高。而此时本发明实现的负载均衡功能所带来的负载均衡收益远大于上述无锁队列的管理、元素存储空间管理等开销，从而表现出远比rss技术更好的性能。

通过观察图3的三个子图可知，在图3(a)中，当rpc请求数目为900krps时，基于智能网卡的负载调度器比rss技术的尾时延要低87％(rss技术的尾时延12465μs减去基于智能网卡的负载调度器的尾时延1497μs，再将差值除以12465μs，即(12465-1497)/12465×100％＝87％)。在图3(b)中，当rpc请求数目为900krps时，基于智能网卡的负载调度器比rss技术的尾时延要低88％(rss技术的尾时延9883μs减去基于智能网卡的负载调度器的尾时延1164μs，再将差值除以9883μs，即(9883-1164)/9883×100％＝88％)。在图3(c)中，当rpc请求数目为900krps时，基于智能网卡的负载调度器比rss技术的尾时延要低65％(rss技术的尾时延15982μs减去基于智能网卡的负载调度器的尾时延5504μs，再将差值除以15982μs，即(15982-5504)/15982×100％＝88％)。

综上可知，本发明方法与rss技术在派发rpc请求到主机cpu核上做对比时，在rpc请求数目较高(大于600krps)的情况下，本发明方法能使主机服务器的rpc服务模块在处理rpc请求时获得最高降低88％的尾时延。通过在实际物理环境下进行本测试实验，更进一步佐证本发明的可行性及实用价值。