CN102710772B - 一种基于云平台的海量数据通讯系统 - Google Patents

Abstract

本发明涉及一种基于云平台的海量数据通讯系统，所述系统包括：多台机器，对其进行联网以调配成云平台，所述云平台至少包括：主服务器，Map服务器，Reduce服务器；其中通过所述主服务器上的数据库管理界面，连接到数据库，读取原始数据列表，再将数据列表存储到Map服务器上；当所述Map服务器执行完任务，并计算出中间结果，需要将该中间结果发送给所述Reduce服务器；当所述Reduce服务器执行完任务，将最终结果发送给所述主服务器；所述主服务器接收最终结果，并用可视化的形式呈现给用户。

Description

一种基于云平台的海量数据通讯系统

技术领域

本发明涉及计算机领域的数据通讯技术，更具体地，涉及一种云平台环境下的海量数据的通讯系统。

背景技术

云计算是一种基于因特网的超级计算模式，在远程的数据中心，几万甚至几千万台电脑和服务器连接成一片。因此，云计算甚至可以让你体验每秒超过10亿万次的运算能力，如此强大的运算能力几乎无所不能。

随着云计算节点的增加，面对的就是海量数据间的通讯。基于TCP/IP的信息交换是稳定可靠的，但其对底层网络会带来很大的负载。同时，这种信息交换的过程需要软件的支持，某个节点可能同时需要与上百个节点交换信息，这意味着上层软件需要相应地配置大量的进程或者线程用于交互，这对CPU、内存提出了很高的要求。

为了提高节点之间信息交换的效率，往往需要重复使用这些TCP/IP连接和线程/进程资源，因为重新建立这种连接的开销很大。但是，如果重复使用这些TCP/IP连接和线程/进程资源，又会长期占据大量资源，可能拖累整个系统。

写入或者读取出来的数据需要内存存储。传统通讯方式会频繁地申请和释放内存，这对整个系统的性能和稳定性带来很大的负担。

传统的通讯方式是发起方A向接收方B发起请求，要求建立Socket，B接收到消息后给A一个确认反馈，A再发送数据给B，B读取数据，然后启动一个线程去执行数据，当数据执行完，再返回结果给A，A读取结果后关闭Socket。此传统的通讯方式在处理信息的过程中，系统不能释放通讯资源，因为还需要返回处理结果，但事实上处理信息的时候并不会发出或者返回信息，而这一过程可能会很耗时间，这种没有意义的耦合会导致整个系统的处理能力大大降低。

发明内容

针对现有技术中的上述问题，本发明所要解决的技术问题是能避免云平台中数据通讯的CPU及内存开销大和响应时间慢的弊端，以满足海量数据实时分析的需求，并提高用户体验和整个系统性能。

更具体地，本发明公开了一种基于云平台的海量数据通讯系统，所述系统包括：

多台服务器，对其进行联网以调配成云平台，所述云平台至少包括：主服务器，Map服务器，Reduce服务器；其中

通过所述主服务器上的数据库管理界面，连接到数据库，读取原始数据列表，再将数据列表存储到Map服务器上；

所述主服务器向所述Map服务器发起请求，首先获得所述主服务器与所述Map服务器之间的Socket通道；

当所述主服务器获得某一Socket通道，将数据写入所述Socket通道对应的写内存块，所述写内存块有消息机制通知写线程去写数据到所述Socket通道中；

当所述主服务器写出数据之后，所述Map服务器对应的Socket通道有数据送过来，有消息机制通知读线程去把Socket通道中的数据读取出来并存储到读内存块中；

当所述Map服务器执行完任务，并计算出中间结果，需要将该中间结果发送给所述Reduce服务器；

当所述Reduce服务器执行完任务，将最终结果发送给所述主服务器；

所述主服务器接收最终结果，并用可视化的形式呈现给用户。

本发明所公开的技术方案具有如下的益处，其能提高云计算中海量数据传输交换的稳定性，减少CPU、内存的开销，提高节点间的传输效率。本发明的云平台中的海量数据通讯方式，通过减少Socket通道的占用时间，Socket通道可重复使用，Socket通道的读写线程可以共享并得到优化配置，Socket通道不用时刻关闭，根据状态可以释放闲置的Socket通道，当Socket通道不够时，又可开启新的Socket通道；通过释放网络资源(包括Socket，CPU，内存等)达到减少负载的目的；通过异步通讯，解耦了信息传输与任务处理，达到完全并行工作的目的。可根据环境，设备不同，通过调优参数，灵活配置不同规模的云平台环境。

附图说明

附图1是本发明所述的云平台海量数据通讯系统的结构框图。

具体实施方式

为解决本发明所述的技术问题，本发明提供的在云平台中的海量数据通讯系统，采用的技术方案如下：

1.云平台中有多台服务器，多台服务器需要通讯。本发明中所有提交通讯请求的为发起方，接收请求的为接收方。无论哪台服务器需要请求Socket连接，都称作发起方。无论哪台服务器收到Socket请求，都称作接收方。

所述发起方除了发起请求的线程，还有一个管理Socket通道的机制，与专门负责写数据的线程。

所述接收方也有一个管理Socket通道的机制，与专门负责读数据的线程，还有一个线程池来负责执行任务。

2.服务器A向服务器B发起请求。服务器A为发起方，服务器B为接收方。发起方请求与接收方连接所用的Socket通道。如果该通道没有开通，那就建立新的Socket通道连接。如果Socket通道有，但被占用，那查看是否可以开启新通道。如果用户设置可开启的通道数还未达到，就再开启新通道。如果已达到了通道上限，就等待，直到有通道闲置再使用。

Socket通道是单向的。用户如果设置最大通道数为3的话，那服务器A与服务器B直接的最多通道数为6.服务器A向服务器B发送是3条，服务器B向服务器A发送是3条。用户可根据自身的服务器设备配置的状况来设定最大通道数。若服务器配置高，可设大些；若服务器配置低，可设低些。

另外，一个发起方可能会有很多个Socket通道，例如通向服务器B的3条，通向服务器C的3条，如此类推。

3.一个Socket通道对应两个存储数据的内存块，一个存储写入的数据，我们称之为写内存块；一个存储读出的数据，我们称之为读内存块。写内存块和读内存块的大小可以配置，缺省是5MB。由于Socket通道是复用的，那么对应的读写内存块也是复用的，也就是说，整个通讯过程并不存在内存的申请或者释放操作，整个通讯过程中系统的内存稳定而且高效。

4.服务器A获得与服务器B通讯的某一Socket通道，需要写数据到Socket通道中。它不会直接将数据写入Socket通道中，而是将数据写入写内存块中。一旦写入内存块中的数据已满，或者整个写入工作完成，这时写入内存块有一个消息机制通知写数据的线程开始往Socket通道写数据。这样一来，一个发起方可能会有很多个通道，但写数据的线程可以比较少，可能就配置一到两个线程。该线程专门负责写数据到Socket通道中。例如有6个向外发送请求的Socket通道，只有一个写数据到Socket通道的线程，当有消息通知其中一个Socket通道需要写数据，该线程就过来写数据，直到把该Socket通道对应的写内存块中的数据写完之后，又停下来等待，直到又有消息来通知写数据。

开始写数据的时候，需要先带上一个标识，再写数据。该标识的作用是为提高安全性。当接受数据的时候，如果没有读到标识，说明该Socket通道的状态不正确，需要立即关闭该Socket通道。当Socket通道被关闭，发起方会监听到异常，会认为该通讯不成功。发起方会重新建立Socket通道。

当完成写数据的任务，该通道就可以被释放，以供别的任务使用。因此一个通道建立后，不会被关闭，而是可以复用的。如果一个通道被关闭了，认为它是有异常状况发生，需要重新建立连接。当写完数据，服务器A的任务就完成了，通道资源的占用时间就大大缩短了。

5.服务器B为接收方。接收方也有个Socket通道管理机制和专门负责读数据的线程。当Socket里有数据了，也会有消息机制通知读数据的线程来读取数据。该读数据的线程也是多个通道共享一个，整个系统也就配置成一到两个线程。

读数据的线程把Socket通道里的数据不断读出来，并写到对应的读内存块中。当读内存数据块收到数据之后，而该Socket通道并没有一个任务与之绑定时，就会产生一个新任务，该新任务绑定这个Socket通道，然后被放到任务线程池中去运行。

如果读内存块被堆满了数据未能得到及时处理，Socket通道就会被阻止送数据过来，直到读内存块有剩余空间。读内存块存储的数据会由任务来读取。如果数据是计算请求，计算请求任务就会直接进行计算；如果是别的请求，相应的任务会被创建并处理请求。从Socket通道读取数据到内存都是纯二进制流物理传输过程，没有商业逻辑。当移交给任务线程池的时候，才开始真正解释数据流。先读到的应该是发起方带上的标识位。如果不是标识位，那该数据流肯定错误，需要关闭该通道，因为送过来的流都有丢失数据。发送方监听到通道关闭了，会重新发送。标识位后面是任务的class，将该任务初始化后，再开始读取所需要的数据。

该任务读取数据完毕之后，将不再绑定该Socket通道。这时该Socket通道重新进入等待状态，等待接收并读取新的数据。

当任务读完所有需要的数据，并执行完任务，会产生结果。如果需要返回结果给服务器A。这时，服务器B作为新的信息发起方，请求通道，占用通道，发送结果，并释放通道。服务器A作为新的信息接收方，监听通道，读取数据到内存，再移交新的任务给线程池去运行。

下面结合附图1和本发明的优选实施方式对本发明进行进一步详细说明。

其中，需要说明的是，本申请所涉及的专业术语在本申请中表述如下的含义：

写线程：专门负责写数据的线程。

读线程：专门负责读数据的线程。

写内存：给写数据所分配的内存块。

读内存：给读数据所分配的内存块。

1.如图1所示，将三台服务器联网，同时安装商业智能平台软件。一台主服务器，一台Map服务器，一台Reduce服务器。

2.通过主服务器上的数据库管理界面，连接到数据库，读取原始数据列表，再将数据列表存储到Map服务器上。

设定每台服务器最大允许建立的通道数为2。因此每台有4个出口Socket通道和4个入口Socket通道。

每台服务器为其4个出口Socket通道分配了一个写数据的内存块，内存块大小为5M。还有一个线程专门负责写数据，收到通知就写数据，没有就等待。

每台服务器为其4个入口Socket通道分配了一个读数据的内存块，内存块的大小为5M。还有一个线程负责读数据，收到通知就读数据，没有就等待。还有一个线程池，设定最大线程个数为10，即最多同时处理10个任务。

3.主服务器接收到客户指令，例如查询每月销售额的汇总。主服务器将商业模型转化成具体的数学计算模型，开始向Map服务器请求并通讯。

1)主服务器向Map服务器发起请求，需先获得主服务器与Map服务器之间的Socket通道。主服务器请求Socket通道，如果该通道没有开通，那就先创建Socket通道连接。如果Socket通道有，但被占用，那查看是否可以开启新通道。如果当前只有一个通道开启，就再开启新通道。如果通道数已满2个，就等待，直到有通道闲置再使用。

2)当主服务器获得某一Socket通道，将数据写入该Socket通道对应的写内存块，写内存块有消息机制通知写线程去写数据到Socket通道中。在写数据前，先写入一个字节的标识0x95。再写入到达Map服务器所需初始化的任务的class名。最后再跟上任务所需要的数据。如果数据很快被写完，就把通道释放开，以便其他请求使用。如果数据量很多，就一直往Socket通道里写，但接收方的数据堆满了，该Socket通道就不能继续写，一直等待到能写再继续。只有待所有数据写完，才能把通道释放开。

3)当主服务器写出数据之后，Map服务器对应的Socket通道有数据送过来，有消息机制通知读线程去把Socket通道中的数据读取出来并存储到读内存块中。Map服务器读内存块就开始会被堆入数据，一旦有数据被堆入内存，就开始处理数据了。先读取标识位，查看第一个字节是不是标识0x95。再读取最前面的字符串来生成任务的class，生成一新任务，并初始化该任务，该新任务绑定这个Socket通道，放到线程池中去。该任务自然就会读取后面需要的数据，该任务自身知道多少字节的数据需要读。该任务读完数据之后，立即释放被绑定的Socket通道。

4.当Map服务器执行完任务，并计算出中间结果，需要将该中间结果发送给Reduce服务器。Map服务器作为新的信息发起方，请求通道，占用通道，发送结果给Map服务器，并释放通道。Reduce服务器作为新的信息接收方。读取数据，将任务放入线程池，执行任务。此通讯过程同第3步的工作。

5.当Reduce服务器执行完任务，计算出月销售额的最终结果，需要将该最终结果发送给主服务器。此通讯过程同第3步的工作。

6.主服务器接收月销售额的结果，并用可视化的形式呈现给用户。

通过对本申请的技术方案特别是具体实施方式的描述，可知，本申请在以下4个方面针对传统的数据通讯方式的特点，进行了对其算法相应了的改良设计：

1.可复用的TCP/IP连接：

系统的TCP/IP连接是可复用的，不像传统方式一样，一个信息传递需要建立一个连接，而信息交换的接收与发出逻辑对应的软件进程/线程是可复用的。这一方法降低了整个系统的TCP/IP负载，以及线程/进程开销。

2.多路的信息传输：

系统的信息传输是多路的。这类似于高速公路的多车道。如果一个TCP/IP连接不够，可以增加TCP/IP连接。而如果闲置，可以收回多余的连接以释放网络、CPU、内存资源。

3.异步的信息传输：

系统的信息传输是异步的。发出信息的请求方不会占据着TCP/IP连接，而是在发出信息之后立即释放资源。以异步的消息通知机制等待返回处理结果，这一异步机制让系统在等待返回处理结果时不会白白耗费资源，在接收方处理信息时也不会占据TCP/IP连接和相应的线程/进程资源。系统以异步信息交换的方式，成功地消除了信息处理与信息传输之间的耦合。提升了信息交换能力，但有效地降低了信息交换所需要的网络资源、CPU、或者内存资源。

4.稳定的内存使用：

由于整个通讯过程中Socket通道是复用的，而Socket通道对应的读内存块和写存块也是复用的，很少有内存的申请和释放操作。这提升了整个系统的性能和稳定性。

5.健壮的信息传输：

系统的TCP/IP连接是可自修复的。网络可能会有各种问题导致连接出错，为了避免数据流里可能丢失了数据，给每个数据流的头部加了标识位，在任何找不到标识位的情况下，连接都会自动关闭。系统会自动重新建立连接。

虽然附图和前述说明给出了本发明的实施例。但可以理解的是，本领域技术人员将理解可以将这种组件中的一个或多个组件很好地组合成单个功能组件。在替换方案中，特定的组件可以分成多个功能组件，或反之。同时，本发明的范围并不受这些特定实例的限制。多种变化都是可能的，例如结构等上的差异，而无论其是否在说明书中被清晰地给出。本发明的范围至少与所附权利要求给出的范围一样宽。

Claims (6)

1.一种基于云平台的海量数据通讯系统，所述系统包括：

多台服务器，对其进行联网以调配成云平台，所述云平台至少包括：主服务器，Map服务器，Reduce服务器；其中

通过所述主服务器上的数据库管理界面，连接到数据库，读取原始数据列表，再将数据列表存储到Map服务器上；

所述主服务器向所述Map服务器发起请求，首先获得所述主服务器与所述Map服务器之间的Socket通道；

当所述主服务器获得某一Socket通道，将数据写入所述Socket通道对应的写内存块，所述写内存块有消息机制通知写线程去写数据到所述Socket通道中；

在写数据前，先写入一个字节的标识0x95，再写入到达Map服务器所需初始化的任务的class名；

当完成写数据的任务，所述Socket通道被释放，以供别的任务使用；

当所述主服务器写出数据之后，所述Map服务器对应的Socket通道有数据送过来，有消息机制通知读线程去把Socket通道中的数据读取出来并存储到读内存块中；

先读取标识位，查看第一个字节是不是标识0x95，再读取最前面的字符串来生成任务的class，将该任务初始化后，再开始读取所需要的数据；

读取数据完毕之后，将不再绑定所述Socket通道，所述Socket通道重新进入等待状态，等待接收并读取新的数据；

当所述Map服务器执行完任务，并计算出中间结果，需要将该中间结果发送给所述Reduce服务器；

当所述Reduce服务器执行完任务，将最终结果发送给所述主服务器；

所述主服务器接收最终结果，并用可视化的形式呈现给用户。

2.根据权利要求1的基于云平台的海量数据通讯系统，其中所述的服务器共有三台，分别被配置成一台主服务器，一台Map服务器，一台Reduce服务器。

3.根据权利要求1或2的基于云平台的海量数据通讯系统，其中设定每台服务器最大允许建立的通道数为2，因此每台服务器具有4个出口Socket通道和4个入口Socket通道。

4.根据权利要求3的基于云平台的海量数据通讯系统，其中每台服务器为其4个出口Socket通道分配一个写数据的内存块，该内存块大小为5M；此外，还具有一个线程专门负责写数据，收到通知就写数据，没有就等待。

5.根据权利要求3的基于云平台的海量数据通讯系统，其中所述主服务器请求Socket通道，如果该通道没有开通，那就先创建Socket通道连接；如果Socket通道有，但被占用，则查看是否可以开启新通道；如果当前只有一个通道开启，就再开启新通道；如果通道数已满2个，就等待，直到有通道闲置再使用。

6.根据权利要求3的基于云平台的海量数据通讯系统，其中所述Map服务器作为新的信息发起方，请求通道，占用通道，发送结果给Reduce服务器，并释放通道；而Reduce服务器作为新的信息接收方，读取数据，将任务放入线程池，执行任务。