CN102340489B - 一种服务器之间的数据传输方法和服务器 - Google Patents

Abstract

本申请实施例公开了一种服务器之间的数据传输方法和服务器。方法包括：应用进程根据各自对内存空间的需求创建各自的文件，将文件映射为共享内存，并将创建的文件句柄发送给数据分发进程；应用进程检测各自创建的共享内存是否有剩余空间存储各自待处理的数据，如果有，将各自待处理的数据拷贝到各自的共享内存中；数据分发进程检测是否有应用进程各自待处理的数据到达各自的共享内存，如果有，从应用进程各自的共享内存中获取应用进程各自待处理的数据；数据分发进程将获取的数据发送给远端服务器。根据本申请实施例，在保证应用进程正常工作的同时，节省了系统资源，提高了数据传输的效率和服务器的性能。

Description

一种服务器之间的数据传输方法和服务器

技术领域

本申请涉及通信和计算机技术领域，特别是涉及一种服务器之间的数据传输方法和服务器。

背景技术

在各种网络环境中，经常会涉及服务器之间的数据传输。例如，位于前端的服务器会将自身的数据发送给后端服务器，由后端服务器对数据进行处理；后端服务器在对数据进行处理后，还会将处理过的数据返回给前端服务器。

在现有技术中，一种实现服务器之间的数据传输方法是：在服务器A中，由操作系统将应用进程中的数据拷贝到内核中(第一次数据拷贝)，再通过进程之间的通信机制，如unix domain机制，将内核中的数据发送给数据分发进程；数据分发进程收到数据后，操作系统分配一个内存空间1，将数据拷贝到内存空间1中(第二次数据拷贝)；最后，数据分发进程利用发送(send)机制将内存空间1中的数据发送给服务器B，其中，当数据分发进程利用send机制发送数据时，操作系统分配一个新的内存空间2，并将内存空间1中的数据拷贝到内存空间2中(第三次数据拷贝)，使一个数据结构sk_buffer与内存空间2相映射，将数据结构sk_buffer发送给网卡进行驱动。显然，在上述的整个数据传输过程中，需要经历三次数据拷贝，比较耗费时间和CPU资源。

另一种实现服务器之间的数据传输方法是：在服务器A中，由数据分发进程预测所有应用进程中的数据需要占用的内存空间，并根据预测结果预先创建一个固定大小的共享内存，各个应用进程将自身数据拷贝到共享内存上(第一次数据拷贝)，当数据分发进程获知共享内存有数据到达时，从共享内存中获取到达的数据，利用send机制将获取的数据发送给服务器B(第二次数据拷贝)。显然，在上述的整个数据传输过程中，仍需要经历二次数据拷贝，尽管相对于第一个现有技术方案来说，一定程度地节省了时间和CPU资源。

但是，发明人在研究中发现，在上述第二种数据传输方法中，由数据分发进程和应用进程共享的共享内存是由数据分发进程根据预测结果而预先创建的一个大小不可以改变的空间，在实际应用中，如果创建的共享内存的空间小于所有应用进程的数据所需的空间，则无法满足应用进程的空间需求，导致应用进程无法正常工作；如果创建的共享内存的空间大于所有应用进程的数据所需的空间，又会浪费系统资源。

发明内容

为了解决上述技术问题，本申请实施例提供了一种服务器之间的数据传输方法和服务器，以在节省系统资源的情况下，同时保证应用进程正常工作。

本申请实施例公开了如下技术方案：

一种服务器之间的数据传输方法，包括：应用进程根据各自对内存空间的需求创建各自的文件，将创建的文件映射为一个共享内存，并将创建的文件句柄发送给服务器中的数据分发进程，所述文件句柄携带共享内存信息；应用进程根据各自创建的文件的文件句柄携带的共享内存信息检测各自创建的共享内存是否有剩余空间存储各自待处理的数据，如果有，将各自待处理的数据拷贝到各自的共享内存中；数据分发进程根据接收的文件句柄检测是否有应用进程各自待处理的数据到达各自的共享内存，如果有，从应用进程各自的共享内存中获取应用进程各自待处理的数据；数据分发进程将获取的数据发送给远端服务器。

一种服务器，包括：共享内存创建模块，用于根据各个应用进程各自对内存空间的需求分别为各个应用进程创建各自的文件，将创建的文件映射为一个共享内存，并将创建的文件的文件句柄发送给剩余空间检测模块和数据到达检测模块，所述文件句柄携带共享内存信息；剩余空间检测模块，用于根据接收的文件句柄中携带的共享内存信息检测所述共享内存创建模块创建的共享内存是否有剩余空间存储各自待处理的数据，如果有，将应用进程各自待处理的数据拷贝到各自的共享内存中；数据到达检测模块，用于根据接收的文件句柄中携带的共享内存信息检测是否有应用进程各自待处理的数据到达各自的共享内存，如果有，从应用进程各自的共享内存中获取应用进程各自待处理的数据；数据传输模块，用于将所述数据到达检测模块获取的数据发送给远端服务器。

由上述实施例可以看出，由各个应用进程在启动时，根据各自对内存空间的实际需求创建各自的文件，并将创建的文件映射为一个共享内存。当应用进程检测到自身创建的共享内存有剩余空间存储数据时，即将数据拷贝到各自的共享内存中，而当数据分发进程检测到应用进程的数据到达共享内存后，从共享内存中获取应用进程的数据，最后将数据发送给远端服务器。因此，在数据传输过程中，共享内存是根据应用进程的使用需求设置，在保证应用进程正常工作的同时，节省了系统资源，提高了数据传输的效率和服务器的性能。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请一种服务器之间的数据传输的方法的一个实施例的流程图；

图2为本申请初始时循环队列的示意图；

图3为本申请取数据后循环队列的示意图；

图4为本申请插入数据后循环队列的示意图；

图5为本申请一种服务器之间的数据传输方法的一个实施例的流程图；

图6为本申请一种对循环队列的可读性和可写性进行判断的步骤的具体流程示意图；

图7为本申请一种服务器的一个实施例的结构示意图；

图8为本申请一种服务器的另一个实施例的结构示意图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图对本申请实施例进行详细描述。

买施例一

请参阅图1，其为本申请一种服务器之间的数据传输的方法的一个实施例的流程图，该方法包括以下步骤：

步骤101：应用进程根据各自对内存空间的需求创建各自的文件，将创建的文件映射为一个共享内存，并将创建的文件句柄发送给服务器中的数据分发进程，所述文件句柄携带共享内存信息；

例如，在现有技术中，是由数据分发进程预先创建一个固定大小的共享内存，然后再分配给不同的应用进程使用。在本申请中，各个应用进程根据各自对内存空间的需求自己创建各自的文件，如，各个应用进程在启动时根据各自对内存空间的需求创建各自的文件。当创建文件后，将创建的文件映射为一个共享内存，以便应用进程将自身待处理的数据存储在自己创建的共享内存中。如，以三个应用进程A、B和C为了进行说明，在应用进程A、B和C根据各自对内存空间的需求分别自己创建文件，应用进程A创建文件1，应用进程B创建文件2，应用进程C创建文件3，应用进程A再将文件1映射为共享内存1′，应用进程B再将文件2映射为共享内存2′，应用进程C再将文件3映射为共享内存3′。同时，三个应用进程还将创建的文件句柄发送给服务器中的数据分发进程，文件句柄中携带有共享内存信息。该共享内存信息可以是共享内容的地址和容量等信息。

步骤102：应用进程根据各自创建的文件的文件句柄携带的共享内存信息检测各自创建的共享内存是否有剩余空间存储各自待处理的数据，如果有，将各自待处理的数据拷贝到各自的共享内存中；

例如，当位于某一个服务器上的应用进程由于各种各样的使用需要，需要将自身待处理的数据发送给远端的服务器代为处理时，上述三个应用进程检测各自创建的共享内存是否有剩余空间存储各自的数据，如果有，将各自的数据拷贝到各自创建的共享内存中。

优选地，所述应用进程根据各自创建的文件的文件句柄携带的共享内存信息检测各自创建的共享内存是否有剩余空间存储各自待处理的数据，如果有，将各自待处理的数据拷贝到各自的共享内存中包括：

应用进程将各自创建的文件的文件句柄作为参数传给接口函数，所述文件句柄携带有开始标识、终止标识和共享内存的容量，所述开始标识标记共享内存中第一个数据的前一位序号，所述终止标识标记共享内存中最后一个数据的序号，接口函数将接收的文件句柄指示的共享内存作为一个循环队列，并根据所述开始标识、终止标识和共享内存的容量判断所述循环队列是否可写，如果可写，向应用进程返回共享内存有剩余空间的结果；

应用进程在接收到所述结果后，将各自待处理的数据拷贝到各自的共享内存中，更新所述文件句柄中的开始标识或终止标识。

例如，每个应用进程在将各自待处理的数据拷贝到各自的共享内存之前，需要检测各自的共享内存是否有剩余空间存储各自待处理的数据。如，应用进程可以通过一个接口函数实现上述检测过程。在该接口函数中，需要接收每个应用进程传递的各自文件的文件句柄这个参数。其中，文件句柄中携带有开始标识、终止标识和共享内存容量，开始标识标记共享内存中第一个数据的前一位序号，终止标识标记共享内存中最后一个数据的序号。同时，接口函数会将一个共享内存作为一个循环队列。如，请参阅图2，其为本申请初始时循环队列的示意图，循环队列中存储有3个数据data1、data2和data3，其在共享内存中的序号依次为1、2和3。开始标识标记共享内存中第一个数据data1的前一位序号，即，开始标识为0，终止标识标记共享内存中最后一个数据data3的序号，即，终止标记为3。当从循环队列中取数据时，可设定先读取开始标识标记的值，再将开始标识标记的值加1；当从循环队列中插入数据时，可设定先读取终止标识标记的值，再将终止标记的值加1。图3为本申请取数据后循环队列的示意图，图4所示为本申请插入数据后循环队列的示意图。

当接口函数接收到文件句柄后，即可根据文件句柄中携带的开始标识、终止标识和共享内存的容量判断该循环队列是否可写，如果可写，向应用进程返回共享内存有剩余空间的结果。每个应用进程在接收到接口函数返回的可写的结果后，将各自待处理的数据拷贝到各自的共享内存中，同时，还要更新文件句柄中的开始标识或终止标识。

步骤103：数据分发进程根据接收的文件句柄检测是否有应用进程各自待处理的数据到达各自的共享内存，如果有，从应用进程各自的共享内存中获取应用进程各自待处理的数据；

优选地，所述数据分发进程根据接收的文件句柄检测是否有应用进程各自待处理的数据达到各自的共享内存，如果有，从应用进程各自的共享内存中获取所述应用进程各自待处理的数据包括：

数据分发进程将接收的文件句柄作为参数传给接口函数，所述文件句柄携带有开始标识、终止标识和共享内存的容量，所述开始标识标记共享内存中第一个数据的前一位序号，所述终止标识标记共享内存中最后一个数据的序号，接口函数将接收的文件句柄指示的共享内存作为一个循环队列，并根据所述开始标识、终止标识和共享内存的容量判断所述循环队列是否可读，如果可读，向应用进程返回有数据到达所述共享内存的结果；

数据分发进程在接收到所述结果后，从应用进程各自的共享内存中获取应用进程各自待处理的数据，并更新所述文件句柄中携带的终止标识或开始标识。

例如，数据分发进程在从某一个共享内存中获取某一个应用进程待处理的数据之前，需要检测该应用进程的数据是否到达该共享内存。如，前面提到，一个应用可以通过接口函数实现一种检测过程。同样，数据分发进程也可以通过一个接口函数实现上述检测过程。在该接口函数中，需要接收数据分发进程传递的某个文件的文件句柄。其中，文件句柄中携带有开始标识、终止标识和共享内存容量。开始标识标记共享内存中第一个数据的前一位序号，终止标识标记共享内存中最后一个数据的序号。同时，接口函数会将一个共享内存作为一个循环队列，前面已经详细地描述了循环队列，故此处不再赘述。当接口函数接收到文件句柄后，即可根据文件句柄中携带的开始标识、终止标识和共享内存的容量判断该循环队列是否可读，如果可读，向数据分发进程返回有数据到达共享内存的结果。当数据分发进程接收到接口函数返回的有数据到达共享内存的结果后，从应用进程各自的共享内存中获取应用进程各自待处理的数据，同时，并更新文件句柄中的终止标识或开始标识。

步骤104：数据分发进程将获取的数据发送给远端服务器。

其中，所述一服务器中的数据分发进程可以利用现有的send发送机制将获取的数据发送给远端服务器，也可以利用文件发送(sendfile)发送机制将获取的数据发送给远端服务器。利用sendfile机制将获取的数据发送给远端服务器包括：数据分发进程调用一个数据结构，所述数据结构存储获取的数据，且与所述共享内存相映射；数据分发进程将所述数据结构发送给网卡进行驱动。

在Linux系统中包括有两种发送机制：send发送机制和sendfile发送机制。与现有技术中数据分发进程利用send发送机制将数据发送给远端服务器不同，本申请实施例中数据分发进程优选利用sendfile发送机制将数据发送给远端服务器。其中，数据结构直接与共享内存相映射，并由网卡驱动数据结构。

进一步的，上述数据传输方法还包括：当应用进程退出时，释放退出的应用进程创建的共享内存。

例如，本申请中的服务器可通过调用现有技术中的flush函数实现释放退出的应用进程创建的共享内存。在调用flush函数后，数据分发进程关闭退出的应用进程所创建的文件的文件句柄，所述flush函数重载退出的应用进程创建的文件。

当某一个应用进程A无论是正常还是异常退出时，在调用flush函数后，该flush函数重载了应用进程A创建的文件。此时，该应用进程A创建的文件从文件系统中解除，即，该应用进程A创建的文件对于数据分发进程来说是不可见的。数据分发进程在调用flush函数后，关闭应用进程A创建的文件的文件句柄，例如，当数据分发进程无法获取至此文件句柄，应用进程A创建的文件被删除，与该文件相映射的共享内存被释放。

需要说明的是，本申请实施例中的“一服务器”和“远端服务器”仅为互相之间由于各种各样的应用而进行数据传输的两个服务器，而对其具体指代哪个服务器并不进行限定。例如，如果“一服务器”为前端服务器，则“远端服务器”即为与前端服务器进行数据传输的后端服务器，反之亦然。

由上述实施例可以看出，由各个应用进程在启动时，根据各自对内存空间的实际需求创建各自的文件，并将创建的文件映射为一个共享内存。当应用进程检测到自身创建的共享内存有剩余空间存储数据时，即将数据拷贝到各自的共享内存中，而当数据分发进程检测到应用进程的数据到达共享内存后，从共享内存中获取应用进程的数据，最后将数据发送给远端服务器。因此，在数据传输过程中，共享内存是根据应用进程的使用需求设置，在保证应用进程正常工作的同时，节省了系统资源，提高了数据传输的效率和服务器的性能。

当应用进程退出时，由每个应用进程创建的共享内存也会随之被释放，节省了系统资源。

另外，当本申请实施例采用sendfile机制将数据发送给远端服务器，与现有的send机制发送数据相比，可以节省一次数据拷贝过程。进一步地节省了数据传输时间和CPU资源。

实施例二

下面以一个具体的应用场景为例详细说明服务器之间的数据传输方法。其中，在该应用场景中，为前端服务器与后端服务器之间的数据传输。另外，为了方便描述过程，假设前端服务器有多个应用进程进行数据传输，由于各应用进程均可采用本申请中的方案进行数据传输，因此在本实施例中仅以其中的一个应用进程A进行说明。请参阅图5，其为本申请一种服务器之间的数据传输方法的一个实施例的流程图，如图5所示，所述数据传输方法包括：

步骤501：前端服务器的应用进程A在启动时，根据自身对内存空间的需求创建一个文件1，并将创建的文件1映射为一个共享内存a；

步骤502：在应用进程A将自身的数据拷贝到共享内存a之前，应用进程将文件1的文件句柄作为参数传给epoll接口函数，由epoll接口函数判断共享内存a是否可写；

其中，epoll是Linux内核为处理大批量句柄而作了改进的接口函数，它能显著减少程序在大量并发连接中只有少量活跃的情况下的系统CPU利用率。epoll接口函数具有判断循环队列是否可写和是否可读的两种工作方式。

其中，文件句柄中携带有开始标识、终止标识和共享内存的容量，开始标识标记共享内存中第一数据的第一位序号，终止标识标记共享内存中最后一个数据的序号。

epoll接口函数将共享内存a作为一个循环队列，按照判断循环队列是否可写的方式，根据获得的开始标识、终止标识和共享内存的容量，判断循环队列是否可写，即可获知共享内存a是否可写。，并且，epoll接口函数根据获得的开始标识、终止标识和共享内存的容量，判断循环队列是否可读，即可获知共享内存a是否可读。

下面将一同说明epoll接口函数根据获得的开始标识、终止标识和共享内存的容量判断循环队列是否可读是否可写的具体步骤。

请参阅图6，其为本申请中对循环队列的可读性和可写性进行判断的步骤的优选流程示意图，其中，在初始状态下，终止标识标记的序号大于开始标识标记的序号，该过程包括：

步骤601：获取文件1的文件句柄中的开始标识、终止标识和共享内存容量；

步骤602：判断开始标识标记的序号数是否大于终止标识标记的序号数，如果是，进入步骤603，如果否，进入步骤604；

步骤603：当开始标识标记的序号数大于终止标识标记的序号数时，判断开始标识标记的序号数与终止标识标记的序号数之差是否大于1，如果是，进入步骤605，如果否，进入步骤606；

步骤604：当开始标识标记的序号数小于或等于终止标识标记的序号数时，判断终止标识标记的序号数与开始标识标记的序号数之差是否大于1，如果是，进入步骤607，如果否，进入步骤608；

步骤605：判定循环队列可写，进入步骤610；

步骤606：判断终止标识标记的序号数加上共享内存的容量再减去1后的值是否大于开始标识标记的序号数，如果是，进入步骤614，如果否，进入步骤613；

步骤607：判定循环队列可读，进入步骤609；

步骤608：当判定循环队列可读时，判断开始标识标记的序号数加上共享内存的容量再减去1后是否大于终止标识标记的序号数，如果是，进入步骤611，如果否，进入步骤614；

步骤609：当判定循环队列可读时，判断开始标识标记的序号数加上共享内存的容量再减去1后是否大于终止标识标记的序号数，如果是，进入步骤612，如果否，进入步骤613；

步骤610：判断终止标识标记的序号数加上共享内存的容量再减去1后的值是否大于开始标识标记的序号数，如果是，进入步骤611，如果否，进入步骤612；

步骤611：判定循环队列既可读又可读，进入步骤615；

步骤612：判定循环队列只可写不可读，进入步骤615；

步骤613，判定循环队列不可读不可写，进入步骤615；

步骤614，判定循环队列只可读不可写，进入步骤615；

步骤615，返回判定结果，即分别对应返回步骤611～614中的判定结果，结束流程。

需要说明的是，上述步骤606和步骤610，以及步骤608和步骤609的判定内容均分别相同，为清楚表述可读性和可写性进行判断的步骤才将其分开描述，本申请实施例中也可将其合并。

通过执行上述过程，epoll接口函数向应用进程返回循环队列是否可写的判定结果，或者，向数据分发进程返回循环队列是否可读的判定结果。应用进程根据循环队列是否可写执行对应的数据写入操作。数据分发进程根据循环队列是否可读执行对应的数据获取操作。

步骤503：当应用进程A从epoll接口函数返回的结果获知共享内存a可写后，将数据拷贝到共享内存a中；

步骤504：前端服务器的数据分发进程将文件1的文件句柄作为参数传给epoll接口函数，由epoll接口函数判断共享内存a是否可读；

其中，epoll接口函数判断共享内存a是否可读已经包括在附图6所示流程中，故此处不再赘述。的判断结果。

步骤505：当数据分发进程从epoll接口函数返回的结果获知共享内存a可读后，从共享内存a中获取应用进程A的数据；

步骤506：数据分发进程利用sendfile机制将获取的数据发送给后端服务器。

在实施例一中，已经对数据分发进程利用sendfile机制发送数据的过程已经进行了详细地描述，故此处不再赘述。

当应用进程退出时，由每个应用进程创建的共享内存也会随之被释放，节省了系统资源。

由上述实施例可以看出，由各个应用进程开始运行时，根据各自对内存空间的实际需求创建各自的文件，并将创建的文件映射为一个共享内存。当应用进程检测到自身创建的共享内存有剩余空间存储数据时，即将数据拷贝到各自的共享内存中，而当数据分发进程检测到应用进程的数据到达共享内存后，从共享内存中获取应用进程的数据，最后通过senfile机制将数据发送给远端服务器。在数据传输过程中，由于共享内存是根据应用进程的使用需求设置的，因此在保证应用进程正常工作的同时，节省了系统资源，提高了数据传输的效率和服务器的性能。

另外，本申请实施例采用sendfile机制将数据发送给远端服务器，与现有的send机制发送数据相比，可以节省一次数据拷贝过程。进一步节省了数据传输的时间和CPU资源。

如下表所示，将本申请的数据传输方法所产生的传输性能与本申请背景技术中的第二个数据传输方法所产生的传输性能进行对比发现，本申请的传输性能优于本申请背景技术中的第二个数据传输方法的性能。并且，可看出，对于大的数据，本申请能够显著提高每秒查询率(Queries-per-second，QPS)。QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为服务器的机器的性能经常用每秒查询率来衡量。

数据大小(字节)	现有技术的QPS	本申请的QPS
			1024	3300	3800
16000	1500	3400
			64000	600	1300
100000	400	900

实施例三

与上述一种服务器之间的数据传输方法相对应，本申请实施例还提供了一种服务器。请参阅图7，其为本申请一种服务器的一个实施例的结构示意图，该服务器包括：共享内存创建模块701、剩余空间检测模块702、数据到达检测模块703和数据传输模块704。下面结合该装置的工作原理进一步介绍其内部结构以及连接关系。

共享内存创建模块701，用于根据各个应用进程各自对内存空间的需求分别为各个应用进程创建各自的文件，将创建的文件映射为一个共享内存，并将创建的文件的文件句柄发送给剩余空间检测模块和数据到达检测模块，所述文件句柄携带共享内存信息；

剩余空间检测模块702，用于根据接收的文件句柄中携带的共享内存信息检测所述共享内存创建模块创建的共享内存是否有剩余空间存储各自待处理的数据，如果有，将应用进程各自待处理的数据拷贝到各自的共享内存中；

数据到达检测模块703，用于根据接收的文件句柄中携带的共享内存信息检测是否有应用进程各自待处理的数据到达各自的共享内存，如果有，从应用进程各自的共享内存中获取应用进程各自待处理的数据；

数据传输模块704，用于将所述数据到达检测模块获取的数据发送给远端服务器。

其中，剩余空间检测模块702包括：第一接口模块7021和数据拷贝模块7022，

第一接口模块7021，用于接收所述共享内存创建模块发送的文件句柄，将接收的文件句柄指示的共享内存作为一个循环队列，并根据所述开始标识、终止标识和共享内存的容量判断所述循环队列是否可写，如果可写，向数据拷贝模块返回共享内存有剩余空间的结果，所述文件句柄携带有开始标识、终止标识和共享内存的容量，所述开始标识标记共享内存中第一个数据的第一位序号，所述终止标识标记共享内存中最后一个数据的序号；

数据拷贝模块7022，用于在接收到所述结果后，将应用进程各自待处理的数据拷贝到各自的共享内存中，并更新接收的文件句柄中携带的开始标识或终止标识。

数据到达检测模块703包括：第二接口模块7031和数据获取模块7032，第二接口模块7032，用于接收所述共享内存创建模块发送的文件句柄，将接收的文件句柄指示的共享内存作为一个循环队列，并根据所述开始标识、终止标识和共享内存的容量判断所述循环队列是否可读，如果可读，向数据获取模块返回有数据到达所述共享内存的结果，所述文件句柄携带有开始标识、终止标识和共享内存的容量，所述开始标识标记共享内存中第一数据的第一位序号，所述终止标识标记共享内存中最后一个数据的序号；

数据获取模块7032，用于在接收到所述结果后，从应用进程各自的共享内存中获取应用进程各自待处理的数据，并更新所述文件句柄中携带的开始标识或终止标识。

数据传输模块704包括：数据结构创建模块7041和数据发送模块7042，创建模块7041，用于创建一个数据结构，所述数据结构存储获取的数据的，且与所述共享内存相映射；

发送模块7042，用于将所述数据结构发送给网卡进行驱动。

优选的，请参阅图8，其为本申请一种服务器的另一个实施例的结构示意图，所述服务器除了包括共享内存创建模块701、剩余空间检测模块702、数据到达检测模块703和数据传输模块704之外，还包括释放模块705，用于当应用进程退出时，释放退出的应用进程创建的共享内存。

由上述实施例可以看出，由各个应用进程在启动时，根据各自对内存空间的实际需求创建各自的文件，并将创建的文件映射为一个共享内存。当应用进程检测到自身创建的共享内存有剩余空间存储数据时，即将数据拷贝到各自的共享内存中，而当数据分发进程检测到应用进程的数据到达共享内存后，从共享内存中获取应用进程的数据，最后将数据发送给远端服务器。因此，在数据传输过程中，共享内存是根据应用进程的使用需求设置，保证了节省系统资源的情况下，同时保证应用进程正常工作。

当应用进程退出时，由每个应用进程创建的共享内存也会随之被释放，节省了系统资源。

需要说明的是，本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random AccessMemory，RAM)等。

以上对本申请所提供的一种服务器之间的数据传输方法和服务器进行了详细介绍，本文中应用了具体实施例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种服务器之间的数据传输方法，其特征在于，包括：

应用进程根据各自对内存空间的需求创建各自的文件，将创建的文件映射为一个共享内存，并将创建的文件句柄发送给服务器中的数据分发进程，所述文件句柄携带共享内存信息；

应用进程根据各自创建的文件的文件句柄携带的共享内存信息检测各自创建的共享内存是否有剩余空间存储各自待处理的数据，如果有，将各自待处理的数据拷贝到各自的共享内存中；

数据分发进程根据接收的文件句柄检测是否有应用进程各自待处理的数据到达各自的共享内存，如果有，从应用进程各自的共享内存中获取应用进程各自待处理的数据；

数据分发进程将获取的数据发送给远端服务器。

2.根据权利要求1所述的服务器之间的数据传输方法，其特征在于，所述应用进程根据各自创建的文件的文件句柄携带的共享内存信息检测各自创建的共享内存是否有剩余空间存储各自待处理的数据，如果有，将各自待处理的数据拷贝到各自的共享内存包括：

应用进程将各自创建的文件的文件句柄作为参数传给接口函数，所述文件句柄携带有开始标识、终止标识和共享内存的容量，所述开始标识标记共享内存中第一个数据的前一位序号，所述终止标识标记共享内存中最后一个数据的序号，接口函数将接收的文件句柄指示的共享内存作为一个循环队列，并根据所述开始标识、终止标识和共享内存的容量判断所述循环队列是否可写，如果可写，向应用进程返回共享内存有剩余空间的结果；

应用进程在接收到所述结果后，将各自待处理的数据拷贝到各自的共享内存中，更新所述文件句柄中的开始标识或终止标识。

3.根据权利要求1所述的服务器之间的数据传输方法，其特征在于，所述数据分发进程根据接收的文件句柄检测是否有应用进程各自待处理的数据到达各自的共享内存，如果有，从应用进程各自的共享内存中获取应用进程各自待处理的数据包括：

数据分发进程将接收的文件句柄作为参数传给接口函数，所述文件句柄携带有开始标识、终止标识和共享内存的容量，所述开始标识标记共享内存中第一个数据的前一位序号，所述终止标识标记共享内存中最后一个数据的序号，接口函数将接收的文件句柄指示的共享内存作为一个循环队列，并根据所述开始标识、终止标识和共享内存的容量判断所述循环队列是否可读，如果可读，向应用进程返回有数据到达所述共享内存的结果；

数据分发进程在接收到所述结果后，从应用进程各自的共享内存中获取应用进程各自待处理的数据，并更新所述文件句柄中携带的终止标识或开始标识。

4.根据权利要求1所述的服务器之间的数据传输方法，其特征在于，所述数据分发进程将获取的数据发送给远端服务器包括：

数据分发进程调用一个数据结构，所述数据结构存储获取的数据，且与所述共享内存相映射；

数据分发进程将所述数据结构发送给网卡进行驱动。

5.根据权利要求1-4任意一项所述的服务器之间的数据传输方法，其特征在于，还包括：

当应用进程退出时，释放退出的应用进程创建的共享内存。

6.一种服务器，其特征在于，包括：

共享内存创建模块，用于根据各个应用进程各自对内存空间的需求分别为各个应用进程创建各自的文件，将创建的文件映射为一个共享内存，并将创建的文件的文件句柄发送给剩余空间检测模块和数据到达检测模块，所述文件句柄携带共享内存信息；

剩余空间检测模块，用于根据接收的文件句柄中携带的共享内存信息检测所述共享内存创建模块创建的共享内存是否有剩余空间存储各自待处理的数据，如果有，将应用进程各自待处理的数据拷贝到各自的共享内存中；

数据到达检测模块，用于根据接收的文件句柄中携带的共享内存信息检测是否有应用进程各自待处理的数据到达各自的共享内存，如果有，从应用进程各自的共享内存中获取应用进程各自待处理的数据；

数据传输模块，用于将所述数据到达检测模块获取的数据发送给远端服务器。

7.根据权利要求6所述的服务器，其特征在于，所述剩余空间检测模块包括：

第一接口模块，用于接收所述共享内存创建模块发送的文件句柄，将接收的文件句柄指示的共享内存作为一个循环队列，并根据开始标识、终止标识和共享内存的容量判断所述循环队列是否可写，如果可写，向数据拷贝模块返回共享内存有剩余空间的结果，所述文件句柄携带有开始标识、终止标识和共享内存的容量，所述开始标识标记共享内存中第一个数据的第一位序号，所述终止标识标记共享内存中最后一个数据的序号；

数据拷贝模块，用于在接收到所述结果后，将应用进程各自待处理的数据拷贝到各自的共享内存中，并更新接收的文件句柄中携带的开始标识或终止标识。

8.根据权利要求6所述的服务器，其特征在于，所述数据到达检测模块包括：

第二接口模块，用于接收所述共享内存创建模块发送的文件句柄，将接收的文件句柄指示的共享内存作为一个循环队列，并根据开始标识、终止标识和共享内存的容量判断所述循环队列是否可读，如果可读，向数据获取模块返回有数据到达所述共享内存的结果，所述文件句柄携带有开始标识、终止标识和共享内存的容量，所述开始标识标记共享内存中第一数据的第一位序号，所述终止标识标记共享内存中最后一个数据的序号；

数据获取模块，用于在接收到所述结果后，从应用进程各自的共享内存中获取应用进程各自待处理的数据，并更新所述文件句柄中携带的开始标识或终止标识。

9.根据权利要求6所述的服务器，其特征在于，所述数据传输模块包括：

数据结构创建模块，用于创建一个数据结构，所述数据结构存储获取的数据，且与所述共享内存相映射；

数据发送模块，用于将所述数据结构发送给网卡进行驱动。

10.根据权利要求6-9任意一项所述的服务器，其特征在于，还包括：

释放模块，用于当应用进程退出时，释放退出的应用进程创建的共享内存。