本發(fā)明涉及數(shù)據(jù)處理領(lǐng)域，具體而言，涉及一種通信處理方法和裝置。

背景技術(shù)：

分布式系統(tǒng)的核心是分布式通信，下面對(duì)現(xiàn)有的分布式通信框架進(jìn)行介紹，在介紹分布式通信框架之前，首先對(duì)分布式通信協(xié)議進(jìn)行說(shuō)明。

現(xiàn)在的分布式通信協(xié)議大致有四種類型：第一種，基于TCP/IP的通信；第二種，基于對(duì)象的通信協(xié)議(RPC，CORBA，RMI)；第三種，基于Http+xml的通信協(xié)議(Web Service)；第四種，基于Http的通信協(xié)議(RESTful)。

在這些通信協(xié)議中，RPC可基于HTTP或TCP協(xié)議，基于RPC在現(xiàn)有技術(shù)中存在分布式通信框架，例如，ZeroRPC，該框架基于ZeroMQ和MessagePack的分布式通信框架。該通信框架具有如下特點(diǎn)：速度快，響應(yīng)時(shí)間短，并發(fā)高，跨語(yǔ)言，是分布式通信中十分優(yōu)秀的RPC框架。

發(fā)明人發(fā)現(xiàn)，在現(xiàn)有技術(shù)中，各種通信框架最小只支持進(jìn)程之間的通信。例如，在ZeroRPC框架中，雖然該框架是一個(gè)高性能、基于ZeroMQ在TCP上支持跨進(jìn)程間的通信框架，但不支持的跨線程間通信。如果不支持線程之間的通信會(huì)使通信的處理不夠靈活。

針對(duì)上述的問(wèn)題，目前尚未提出有效的解決方案。

技術(shù)實(shí)現(xiàn)要素：

本發(fā)明實(shí)施例提供了一種通信處理方法和裝置，以至少解決現(xiàn)有技術(shù)中的通信框架不支持線程之間的通信會(huì)使通信的處理不夠靈活的技術(shù)問(wèn)題。

根據(jù)本發(fā)明實(shí)施例的一個(gè)方面，提供了一種通信處理方法，包括：在節(jié)點(diǎn)中創(chuàng)建一個(gè)或多個(gè)通信線程，其中，所述通信線程用于與對(duì)端節(jié)點(diǎn)中的線程進(jìn)行通信，所述通信線程包括以下至少之一：服務(wù)端線程、客戶端線程；通過(guò)所述一個(gè)或多個(gè)通信線程中的至少之一在所述節(jié)點(diǎn)和所述對(duì)端節(jié)點(diǎn)之間進(jìn)行線程間通信。

進(jìn)一步地，在所述節(jié)點(diǎn)中創(chuàng)建所述一個(gè)或多個(gè)通信線程包括；在所述節(jié)點(diǎn)中通過(guò)設(shè)置的代理實(shí)例創(chuàng)建所述一個(gè)或多個(gè)通信線程；通過(guò)所述一個(gè)或多個(gè)通信線程中的至少之一在所述節(jié)點(diǎn)和所述對(duì)端節(jié)點(diǎn)之間進(jìn)行線程間通信：所述代理實(shí)例使用所述一個(gè)或多個(gè)通信線程中的至少之一在所述節(jié)點(diǎn)和所述對(duì)端節(jié)點(diǎn)之間進(jìn)行線程間通信。

進(jìn)一步地，所述代理實(shí)例使用所述一個(gè)或多個(gè)通信線程中的至少之一在所述節(jié)點(diǎn)和所述對(duì)端節(jié)點(diǎn)之間進(jìn)行線程間通信：所述代理實(shí)例將來(lái)自所述一個(gè)或多個(gè)通信線程中的至少之一的消息發(fā)送給所述對(duì)端節(jié)點(diǎn)；所述代理實(shí)例根據(jù)線程標(biāo)識(shí)符將來(lái)自所述對(duì)端節(jié)點(diǎn)的消息路由到所述節(jié)點(diǎn)中對(duì)應(yīng)的線程。

進(jìn)一步地，在所述代理實(shí)例創(chuàng)建所述一個(gè)或多個(gè)通信線程之前，所述方法還包括：在所述節(jié)點(diǎn)中根據(jù)所述節(jié)點(diǎn)的信息創(chuàng)建所述代理實(shí)例；所述代理實(shí)例根據(jù)所述對(duì)端節(jié)點(diǎn)的信息注冊(cè)所述對(duì)端節(jié)點(diǎn)。

進(jìn)一步地，所述節(jié)點(diǎn)的信息包括以下至少之一：所述節(jié)點(diǎn)的標(biāo)識(shí)信息、所述節(jié)點(diǎn)的IP地址、所述節(jié)點(diǎn)的端口；和/或，所述對(duì)端節(jié)點(diǎn)的信息包括以下至少之一：所述對(duì)端節(jié)點(diǎn)的標(biāo)識(shí)信息、所述對(duì)端節(jié)點(diǎn)的IP地址、所述對(duì)端節(jié)點(diǎn)的端口。

進(jìn)一步地，在通過(guò)所述一個(gè)或多個(gè)通信線程在所述節(jié)點(diǎn)和所述對(duì)端節(jié)點(diǎn)之間進(jìn)行通信之后，所述方法還包括：所述代理實(shí)例關(guān)閉已通信結(jié)束的通信線程；和/或，在所述一個(gè)或多個(gè)通信線程中的所有通信線程的通信均已結(jié)束之后，所述代理實(shí)例注銷所述對(duì)端節(jié)點(diǎn)。

進(jìn)一步地，在所述代理實(shí)例注銷所述對(duì)端節(jié)點(diǎn)之后，所述方法還包括：在所述節(jié)點(diǎn)關(guān)閉所述代理實(shí)例。

根據(jù)本發(fā)明實(shí)施例的另一個(gè)方面，還提供了一種通信處理裝置，位于節(jié)點(diǎn)中，包括：創(chuàng)建模塊，用于創(chuàng)建一個(gè)或多個(gè)通信線程，其中，所述通信線程用于與對(duì)端節(jié)點(diǎn)中的線程進(jìn)行通信，所述通信線程包括以下至少之一：服務(wù)端線程、客戶端線程；通信模塊，用于通過(guò)所述一個(gè)或多個(gè)通信線程中的至少之一在所述節(jié)點(diǎn)和所述對(duì)端節(jié)點(diǎn)之間進(jìn)行線程間通信。

進(jìn)一步地，所述創(chuàng)建模塊和所述通信模塊，位于代理實(shí)例中。

進(jìn)一步地，所述通信模塊包括：發(fā)送單元，用于將來(lái)自所述一個(gè)或多個(gè)通信線程中的至少之一的消息發(fā)送給所述對(duì)端節(jié)點(diǎn)；和/或，接收單元，用于根據(jù)線程標(biāo)識(shí)符將來(lái)自所述對(duì)端節(jié)點(diǎn)的消息路由到所述節(jié)點(diǎn)中對(duì)應(yīng)的線程。

進(jìn)一步地，所述創(chuàng)建模塊，用于根據(jù)所述節(jié)點(diǎn)的信息創(chuàng)建所述代理實(shí)例；所述裝置還包括：注冊(cè)模塊，位于所述代理實(shí)例中，用于根據(jù)所述對(duì)端節(jié)點(diǎn)的信息注冊(cè)所述對(duì)端節(jié)點(diǎn)。

進(jìn)一步地，所述節(jié)點(diǎn)的信息包括以下至少之一：所述節(jié)點(diǎn)的標(biāo)識(shí)信息、所述節(jié)點(diǎn)的IP地址、所述節(jié)點(diǎn)的端口；和/或，所述對(duì)端節(jié)點(diǎn)的信息包括以下至少之一：所述對(duì)端節(jié)點(diǎn)的標(biāo)識(shí)信息、所述對(duì)端節(jié)點(diǎn)的IP地址、所述對(duì)端節(jié)點(diǎn)的端口。

進(jìn)一步地，所述裝置還包括：線程關(guān)閉模塊，位于所述代理實(shí)例中，用于關(guān)閉已通信結(jié)束的線程；和/或，注銷模塊，位于所述代理實(shí)例中個(gè)，用于在所述一個(gè)或多個(gè)通信線程中的所有通信線程的通信均已結(jié)束之后，注銷所述對(duì)端節(jié)點(diǎn)。

進(jìn)一步地，所述裝置還包括：代理實(shí)例關(guān)閉模塊，用于在所述注銷模塊注銷所述對(duì)端節(jié)點(diǎn)之后，關(guān)閉所述代理實(shí)例。

在本發(fā)明實(shí)施例中，采用在節(jié)點(diǎn)中創(chuàng)建一個(gè)或多個(gè)通信線程，其中，所述通信線程用于與對(duì)端節(jié)點(diǎn)中的線程進(jìn)行通信，所述通信線程包括以下至少之一：服務(wù)端線程、客戶端線程；通過(guò)所述一個(gè)或多個(gè)通信線程中的至少之一在所述節(jié)點(diǎn)和所述對(duì)端節(jié)點(diǎn)之間進(jìn)行線程間通信。通過(guò)本發(fā)明實(shí)施例解決了現(xiàn)有技術(shù)中的通信框架不支持線程之間的通信會(huì)使通信的處理不夠靈活的技術(shù)問(wèn)題，使通信的處理更加靈活。

附圖說(shuō)明

此處所說(shuō)明的附圖用來(lái)提供對(duì)本發(fā)明的進(jìn)一步理解，構(gòu)成本申請(qǐng)的一部分，本發(fā)明的示意性實(shí)施例及其說(shuō)明用于解釋本發(fā)明，并不構(gòu)成對(duì)本發(fā)明的不當(dāng)限定。在附圖中：

圖1是根據(jù)本發(fā)明實(shí)施例的通信處理方法的流程圖；

圖2是根據(jù)本發(fā)明實(shí)施例的通信處理裝置的結(jié)構(gòu)框圖；

圖3是根據(jù)本發(fā)明實(shí)施例的通信處理裝置的結(jié)構(gòu)框圖；

圖4是根據(jù)本發(fā)明實(shí)施例的服務(wù)器端接收客戶請(qǐng)求處理流程圖；

圖5是根據(jù)本發(fā)明實(shí)施例的客戶端請(qǐng)求處理流程圖；

圖6是根據(jù)本發(fā)明可選實(shí)施例的整體架構(gòu)示意圖；

圖7是根據(jù)本發(fā)明實(shí)施例的各模塊通信數(shù)據(jù)流示意圖；以及，

圖8是根據(jù)本發(fā)明實(shí)施例的通信框架所采用的ZeroMQ傳輸模式示意圖。

具體實(shí)施方式

為了使本技術(shù)領(lǐng)域的人員更好地理解本發(fā)明方案，下面將結(jié)合本發(fā)明實(shí)施例中的附圖，對(duì)本發(fā)明實(shí)施例中的技術(shù)方案進(jìn)行清楚、完整地描述，顯然，所描述的實(shí)施例僅僅是本發(fā)明一部分的實(shí)施例，而不是全部的實(shí)施例。基于本發(fā)明中的實(shí)施例，本領(lǐng)域普通技術(shù)人員在沒(méi)有做出創(chuàng)造性勞動(dòng)前提下所獲得的所有其他實(shí)施例，都應(yīng)當(dāng)屬于本發(fā)明保護(hù)的范圍。

需要說(shuō)明的是，本發(fā)明的說(shuō)明書和權(quán)利要求書及上述附圖中的術(shù)語(yǔ)“第一”、“第二”等是用于區(qū)別類似的對(duì)象，而不必用于描述特定的順序或先后次序。應(yīng)該理解這樣使用的數(shù)據(jù)在適當(dāng)情況下可以互換，以便這里描述的本發(fā)明的實(shí)施例能夠以除了在這里圖示或描述的那些以外的順序?qū)嵤?。此外，術(shù)語(yǔ)“包括”和“具有”以及他們的任何變形，意圖在于覆蓋不排他的包含，例如，包含了一系列步驟或單元的過(guò)程、方法、系統(tǒng)、產(chǎn)品或設(shè)備不必限于清楚地列出的那些步驟或單元，而是可包括沒(méi)有清楚地列出的或?qū)τ谶@些過(guò)程、方法、產(chǎn)品或設(shè)備固有的其它步驟或單元。

根據(jù)本發(fā)明實(shí)施例，提供了一種通信處理方法的實(shí)施例，需要說(shuō)明的是，在附圖的流程圖示出的步驟可以在諸如一組計(jì)算機(jī)可執(zhí)行指令的計(jì)算機(jī)系統(tǒng)中執(zhí)行，并且，雖然在流程圖中示出了邏輯順序，但是在某些情況下，可以以不同于此處的順序執(zhí)行所示出或描述的步驟。

在本實(shí)施例中提供了一種通信處理方法，圖1是根據(jù)本發(fā)明實(shí)施例的通信處理方法的流程圖，如圖1所示，該流程包括如下步驟：

步驟S102，在節(jié)點(diǎn)中創(chuàng)建一個(gè)或多個(gè)通信線程，其中，通信線程用于與對(duì)端節(jié)點(diǎn)中的線程進(jìn)行通信。在使用客戶端和服務(wù)端通信模式的情況下，創(chuàng)建的通信線程可以包括以下至少之一：服務(wù)端線程、客戶端線程。通過(guò)所述步驟，可以在一個(gè)節(jié)點(diǎn)中根據(jù)需要來(lái)創(chuàng)建多個(gè)通信進(jìn)程，這樣可以做到一個(gè)節(jié)點(diǎn)既充當(dāng)服務(wù)端又充當(dāng)客戶端，從而可以使通信的處理更加靈活。這里的節(jié)點(diǎn)可以理解為一個(gè)物理實(shí)體的節(jié)點(diǎn)，也可以理解為是一個(gè)邏輯上的節(jié)點(diǎn)，任何可以生成多線程的邏輯或者物理實(shí)體都可以稱為節(jié)點(diǎn)。

步驟S104，通過(guò)創(chuàng)建的一個(gè)或多個(gè)通信線程中的至少之一在節(jié)點(diǎn)和對(duì)端節(jié)點(diǎn)之間進(jìn)行線程間通信。

對(duì)端節(jié)點(diǎn)也可以采用上述步驟S102中的線程通信的處理方式，這樣本節(jié)點(diǎn)和對(duì)端節(jié)點(diǎn)就可以進(jìn)行線程間的通信了。當(dāng)然，對(duì)端節(jié)點(diǎn)也可以使用其他的方式來(lái)實(shí)現(xiàn)與本節(jié)點(diǎn)的線程通信，在本實(shí)施例中并不限定對(duì)端節(jié)點(diǎn)所使用的線程的通信方式。

通過(guò)上述步驟可以在節(jié)點(diǎn)中創(chuàng)建進(jìn)行通信的線程，從而實(shí)現(xiàn)了線程間的通信。上述方法可以應(yīng)用到各種通信框架中，從而使各種通信框架能夠支持線程間的通信。當(dāng)然，上述的步驟也可以應(yīng)用到其他的通信處理中，應(yīng)用到通信框架中是一種比較優(yōu)的處理方式。

由于一個(gè)節(jié)點(diǎn)中可以創(chuàng)建多個(gè)通信線程，為了更好的管理這些通信線程，可以設(shè)置一個(gè)代理實(shí)例(Agent實(shí)例)，通過(guò)該代理實(shí)例來(lái)對(duì)通信線程進(jìn)行管理。當(dāng)然，也可以不使用該代理實(shí)例，只要?jiǎng)?chuàng)建了線程通信就可以解決現(xiàn)有技術(shù)中不能在線程間進(jìn)行通信的問(wèn)題。

下面結(jié)合一個(gè)可選的實(shí)施例對(duì)使用Agent實(shí)例的線程間的通信進(jìn)行說(shuō)明。

上文中的一個(gè)或多個(gè)通信線程可以是由代理實(shí)例觸發(fā)生成的。然后該代理實(shí)例使這些通信線程中的至少之一在節(jié)點(diǎn)和對(duì)端節(jié)點(diǎn)之間進(jìn)行線程間通信。通過(guò)代理實(shí)例可以使通信線程的通信和生成得到一個(gè)較好的管理，在架構(gòu)上更加利于使用。

在另一個(gè)可選的實(shí)施方式中，代理實(shí)例不僅僅可以生成線程，以及對(duì)線程的管理，還可以對(duì)線程之間的接收消息和/或發(fā)送消息進(jìn)行處理。如果使用了代理實(shí)例，那么可以由代理實(shí)例將來(lái)自這些通信線程中的至少之一的消息發(fā)送給對(duì)端節(jié)點(diǎn)，在接收消息的時(shí)候，也可以由代理實(shí)例根據(jù)線程標(biāo)識(shí)符將來(lái)自對(duì)端節(jié)點(diǎn)的消息路由到本節(jié)點(diǎn)中對(duì)應(yīng)的線程。通過(guò)各個(gè)代理實(shí)例來(lái)控制消息的發(fā)送，也使得消息的收發(fā)變的更加容易控制，并且，由于是通過(guò)代理實(shí)例來(lái)進(jìn)行的，在上層屏蔽了通信進(jìn)程之間的處理，從而也更加有利于進(jìn)行開發(fā)。

在另一可選的實(shí)施方式中，代理實(shí)例還可以擁有更多的功能，例如，代理實(shí)例可以根據(jù)對(duì)端節(jié)點(diǎn)的信息在本節(jié)點(diǎn)中注冊(cè)對(duì)端節(jié)點(diǎn)，此時(shí)代理實(shí)例的創(chuàng)建也是可以根據(jù)節(jié)點(diǎn)的信息來(lái)產(chǎn)生的。節(jié)點(diǎn)的信息可以有很多類型，對(duì)端節(jié)點(diǎn)的信息也可以有很多類型，例如，節(jié)點(diǎn)的信息可以包括以下至少之一：節(jié)點(diǎn)的標(biāo)識(shí)信息、節(jié)點(diǎn)的IP地址、節(jié)點(diǎn)的端口；和/或，對(duì)端節(jié)點(diǎn)的信息可以包括以下至少之一：對(duì)端節(jié)點(diǎn)的標(biāo)識(shí)信息、對(duì)端節(jié)點(diǎn)的IP地址、對(duì)端節(jié)點(diǎn)的端口。

在解決了線程之間的通信之后，對(duì)于通信的線程的關(guān)閉可以基于通信框架來(lái)進(jìn)行，也可以由其他的方式來(lái)進(jìn)行控制。

在一個(gè)可選的實(shí)施例中，可以提供對(duì)線程的關(guān)閉，例如，也可以通過(guò)代理實(shí)例關(guān)閉已通信結(jié)束的線程；和/或，在一個(gè)或多個(gè)通信線程中的所有通信線程的通信均已結(jié)束之后，該代理實(shí)例還可以注銷對(duì)端節(jié)點(diǎn)。通過(guò)該方式，還提供了對(duì)通信結(jié)束的線程的處理。這樣該可選的實(shí)施方式在應(yīng)用到通信框架中之后，還可以很方便的控制線程的關(guān)閉。作為更優(yōu)的實(shí)施方式，節(jié)點(diǎn)還可以關(guān)閉代理實(shí)例。通過(guò)這種方式可以節(jié)約節(jié)點(diǎn)的資源，從而可以進(jìn)行其他的處理。

在本實(shí)施例中還提供了一種通信處理裝置，該通信處理裝置中的各個(gè)模塊對(duì)應(yīng)于上述實(shí)施例及可選實(shí)施方式中的步驟，已經(jīng)進(jìn)行過(guò)說(shuō)明的在以下實(shí)施例中就不再贅述。

圖2是根據(jù)本發(fā)明實(shí)施例的通信處理裝置的結(jié)構(gòu)框圖，該裝置位于節(jié)點(diǎn)中，如圖2所示，該裝置包括：

創(chuàng)建模塊22，用于創(chuàng)建一個(gè)或多個(gè)通信線程，其中，通信線程用于與對(duì)端節(jié)點(diǎn)中的線程進(jìn)行通信，通信線程包括以下至少之一：服務(wù)端線程、客戶端線程；

通信模塊24，用于通過(guò)一個(gè)或多個(gè)通信線程中的至少之一在節(jié)點(diǎn)和對(duì)端節(jié)點(diǎn)之間進(jìn)行線程間通信。

通過(guò)上述模塊可以在節(jié)點(diǎn)中創(chuàng)建進(jìn)行通信的線程，從而實(shí)現(xiàn)了線程間的通信。上述方法可以應(yīng)用到各種通信框架中，從而使各種通信框架能夠支持線程間的通信。當(dāng)然，上述的模塊也可以應(yīng)用到其他的通信處理中，應(yīng)用到通信框架中是一種比較優(yōu)的處理方式。

作為一個(gè)可選的實(shí)施方式，創(chuàng)建模塊22，位于代理實(shí)例中，用于創(chuàng)建一個(gè)或多個(gè)通信線程；通信模塊24位于代理實(shí)例中。

作為一個(gè)可選的實(shí)施方式，通信模塊24包括：

發(fā)送單元，用于將來(lái)自一個(gè)或多個(gè)通信線程中的至少之一的消息發(fā)送給對(duì)端節(jié)點(diǎn)；和/或，接收單元，用于根據(jù)線程標(biāo)識(shí)符將來(lái)自對(duì)端節(jié)點(diǎn)的消息路由到節(jié)點(diǎn)中對(duì)應(yīng)的線程。

作為一個(gè)可選的實(shí)施方式，創(chuàng)建模塊22，用于根據(jù)節(jié)點(diǎn)的信息創(chuàng)建代理實(shí)例；圖3是根據(jù)本發(fā)明實(shí)施例的通信處理裝置的可選結(jié)構(gòu)框圖，如圖3所示，該裝置還可以包括：注冊(cè)模塊32，位于代理實(shí)例中，用于根據(jù)對(duì)端節(jié)點(diǎn)的信息注冊(cè)對(duì)端節(jié)點(diǎn)。

作為一個(gè)可選的實(shí)施方式，圖3是根據(jù)本發(fā)明實(shí)施例的通信處理裝置的可選結(jié)構(gòu)框圖，如圖3所示，該裝置還包括：線程關(guān)閉模塊34，位于代理實(shí)例中，用于關(guān)閉已通信結(jié)束的線程；和/或，注銷模塊36，位于代理實(shí)例中，用于在一個(gè)或多個(gè)通信線程中的所有通信線程的通信均已結(jié)束之后，注銷對(duì)端節(jié)點(diǎn)。

作為一個(gè)可選的實(shí)施方式，圖3是根據(jù)本發(fā)明實(shí)施例的通信處理裝置的可選結(jié)構(gòu)框圖，如圖3所示，該裝置還可以包括：代理實(shí)例關(guān)閉模塊38，用于在注銷模塊36注銷對(duì)端節(jié)點(diǎn)之后，關(guān)閉代理實(shí)例。

注冊(cè)模塊32、線程關(guān)閉模塊34、注銷模塊36、代理實(shí)例關(guān)閉模塊38這些模塊可以作為一種可選的模塊設(shè)置在代理實(shí)例中。

上述實(shí)施例以及可選的實(shí)施方式可以應(yīng)用到多種通信框架中，下面結(jié)合一種通常使用的比較多的通信框架進(jìn)行說(shuō)明。

在本實(shí)施例中，說(shuō)明了將上述實(shí)施例及可選實(shí)施方式實(shí)施到ZeroMQ的通信框架中。

在本實(shí)施例中的通信框架，可以支持不同設(shè)備跨進(jìn)程、跨線程的通信，而不相互干擾。而且，本實(shí)施例中的底層通信對(duì)用戶完全透明，使用方便，通信模塊間具有較低的耦合度，可支持熱擴(kuò)展。

本實(shí)施例中的技術(shù)方案充分利用ZeroMQ輕量高效的特點(diǎn)及提供的多種消息傳輸模型和功能強(qiáng)大的通信模式來(lái)隱藏底層的通信細(xì)節(jié)，支持具有低耦合的，可動(dòng)態(tài)加入的跨線程的通信。本實(shí)施例中的技術(shù)方案可以利用ZeroMQ中TCP傳輸模型構(gòu)造請(qǐng)求-應(yīng)答模式(DEALER-ROUTER)，實(shí)現(xiàn)不同節(jié)點(diǎn)間多線程的網(wǎng)絡(luò)通信。

并且，在本實(shí)施例中還可以通過(guò)注冊(cè)(register)操作創(chuàng)建DEALER端套接字來(lái)注冊(cè)其他節(jié)點(diǎn)，通過(guò)去注冊(cè)(unregister)操作來(lái)關(guān)閉DEALER套接字注銷節(jié)點(diǎn)，動(dòng)態(tài)實(shí)現(xiàn)與其他節(jié)點(diǎn)進(jìn)程間的通信。

在發(fā)送消息方面，節(jié)點(diǎn)進(jìn)程內(nèi)部通過(guò)ZeroMQ中INPROC通信模型構(gòu)造推送-路由(PUSH-ROUTER)模式，在收集(Collector)模塊中創(chuàng)建ROUTER服務(wù)器端套接字，節(jié)點(diǎn)間各線程使用PUSH套接字將消息發(fā)送給節(jié)點(diǎn)中的Collector模塊，Collector模塊接收到消息后，通過(guò)DEALTER客戶端套接字發(fā)送給注冊(cè)的各個(gè)節(jié)點(diǎn)。在接收消息方面，通過(guò)ZeroMQ中INPROC通信模型構(gòu)造發(fā)布-訂閱模式(PUB-SUB)，在PUB端分別建立請(qǐng)求-分配器(request-dispatcher)、響應(yīng)-分配器(response-dispatcher)套接字。當(dāng)ROUTER服務(wù)器端的接收(Acceptor)模塊接收到其他節(jié)點(diǎn)發(fā)送的消息后，根據(jù)消息的類型(request類型或reply類型)分別由對(duì)應(yīng)的request-dispatcher或response-dispatcher套接字發(fā)布消息。每個(gè)線程(客戶端client線程或服務(wù)端server線程)創(chuàng)建相應(yīng)的SUB端套接字，需要訂閱與自己相關(guān)主題，就可以接收其他節(jié)點(diǎn)線程發(fā)送過(guò)來(lái)的消息。線程可以通過(guò)訂閱或取消訂閱而動(dòng)態(tài)地加入到接收消息通信中，并通過(guò)在DEALER端套接字發(fā)送消息。

圖4是根據(jù)本發(fā)明實(shí)施例的服務(wù)器端接收客戶請(qǐng)求處理流程圖，如圖4所示，該流程包括如下步驟：

步驟S401、根據(jù)本節(jié)點(diǎn)所在的ID(節(jié)點(diǎn)標(biāo)識(shí)符)，節(jié)點(diǎn)IP地址，節(jié)點(diǎn)通信端口，創(chuàng)建一個(gè)通信Agent進(jìn)程。

步驟S402，啟動(dòng)Agent實(shí)例。

步驟S403，Agent實(shí)例注冊(cè)需要與其他節(jié)點(diǎn)通信的節(jié)點(diǎn)，包括其他節(jié)點(diǎn)的節(jié)點(diǎn)ID，節(jié)點(diǎn)IP地址，節(jié)點(diǎn)端口。

步驟S404，Agent實(shí)例根據(jù)標(biāo)識(shí)符(如BUCKET_ID)產(chǎn)生一個(gè)線程級(jí)別的server線程。

步驟S405，步驟S406，server線程接收并處理消息，然后發(fā)送消息。

步驟S407，判斷業(yè)務(wù)邏輯是否完成，其中，如果判斷出業(yè)務(wù)邏輯已完成，則執(zhí)行步驟S408。

步驟S408，關(guān)閉server線程。

步驟S409，Agent實(shí)例注銷其他節(jié)點(diǎn)。

步驟S410，關(guān)閉Agent實(shí)例。

圖5是根據(jù)本發(fā)明實(shí)施例的客戶端請(qǐng)求處理流程圖，如圖5所示，該流程包括如下步驟：

步驟S501，根據(jù)本節(jié)點(diǎn)所在的ID(節(jié)點(diǎn)標(biāo)識(shí)符)，節(jié)點(diǎn)IP地址，節(jié)點(diǎn)通信端口，創(chuàng)建一個(gè)通信Agent進(jìn)程。

步驟S502，啟動(dòng)Agent實(shí)例。

步驟S503，Agent實(shí)例注冊(cè)需要與其他節(jié)點(diǎn)通信的節(jié)點(diǎn)，包括其他節(jié)點(diǎn)的節(jié)點(diǎn)ID，節(jié)點(diǎn)IP地址，節(jié)點(diǎn)端口。

步驟S504，Agent實(shí)例根據(jù)標(biāo)識(shí)符(如BUCKET_ID)產(chǎn)生一個(gè)線程級(jí)別的client線程。

步驟S505，步驟S506，client線程發(fā)送和接收消息。

步驟S507，判斷業(yè)務(wù)邏輯是否完成，其中，在判斷出業(yè)務(wù)邏輯已完成的情況下，則執(zhí)行步驟S508，在判斷出未業(yè)務(wù)邏輯未完成的情況下，返回執(zhí)行步驟S505。

步驟S508，關(guān)閉client線程。

步驟S509，Agent實(shí)例注銷其他節(jié)點(diǎn)。

步驟S510，關(guān)閉Agent實(shí)例。

在本實(shí)施例中，每個(gè)節(jié)點(diǎn)可以通過(guò)節(jié)點(diǎn)三元組(節(jié)點(diǎn)標(biāo)識(shí)ID、節(jié)點(diǎn)IP、節(jié)點(diǎn)端口號(hào)PORT)來(lái)標(biāo)識(shí)，創(chuàng)建好Agent實(shí)例后，如果要與其他節(jié)點(diǎn)通信，需要Agent通過(guò)其他節(jié)點(diǎn)三元組信息來(lái)注冊(cè)。為將消息路由到某個(gè)具體的線程，需要在進(jìn)程中對(duì)消息進(jìn)行轉(zhuǎn)發(fā)，其中線程級(jí)別的標(biāo)識(shí)符BUCKET_ID用來(lái)將消息路由到對(duì)應(yīng)的線程。這樣在一個(gè)Agent實(shí)例中可以產(chǎn)生任意的server線程和client線程。如果業(yè)務(wù)邏輯完成，可以關(guān)閉某個(gè)client線程或server線程。如果不需要與某個(gè)節(jié)點(diǎn)通信，可以執(zhí)行unregister操作注銷此節(jié)點(diǎn)。如果不再需要通信，可以關(guān)閉Agent實(shí)例。

圖6是根據(jù)本發(fā)明可選實(shí)施例的整體架構(gòu)示意圖，如圖6所示，本通信框架隱藏了節(jié)點(diǎn)間通信的技術(shù)細(xì)節(jié)，用戶感覺(jué)好像與對(duì)等節(jié)點(diǎn)在通信。實(shí)際上，數(shù)據(jù)通過(guò)代理實(shí)例(即，Agent實(shí)例)進(jìn)行收集和轉(zhuǎn)發(fā)，利用ZeroMQ底層通信庫(kù)的傳輸模型和通信模式，傳輸?shù)较鄬?duì)應(yīng)的對(duì)端節(jié)點(diǎn)(即，節(jié)點(diǎn)1或節(jié)點(diǎn)2)。

下面對(duì)ZeroMQ消息庫(kù)進(jìn)行說(shuō)明。

ZeroMQ是一個(gè)可嵌入的并發(fā)網(wǎng)絡(luò)通信庫(kù)，它提供不同種類的socket(套接字)，這些套接字能通過(guò)不同的傳輸模式如INPROC(進(jìn)程內(nèi)通信)、IPC(進(jìn)程間通信)、TCP、multicast(多播)來(lái)原子性地傳遞消息。開發(fā)者可以使用各種模式實(shí)現(xiàn)N：N的套接字連接，這些模式包括扇出、發(fā)布-訂閱、任務(wù)分配和請(qǐng)求-應(yīng)答。ZeroMQ的傳輸速度足夠快，因此可充當(dāng)集群產(chǎn)品的通信組件。它的異步I/O模型提供了可擴(kuò)展的多核應(yīng)用程序，用異步消息來(lái)處理任務(wù)。

ZeroMQ具有高性能、簡(jiǎn)單、可伸縮性等優(yōu)點(diǎn)。它沒(méi)有額外的協(xié)議如AMQP的開銷，充分利用一些高效的傳輸方式如可靠性多播，利用智能消息批量機(jī)制，有效利用TCP/IP連接，最大程序地減少協(xié)議開銷和系統(tǒng)調(diào)用。ZeroMQ利用了ZeroMQ簡(jiǎn)單的API，發(fā)送消息只需發(fā)起一個(gè)異步調(diào)用，它自動(dòng)將消息隊(duì)列到一個(gè)單獨(dú)的線程中，完成所有剩下的工作。本身不支持消息的序列化，在編碼消息上，給開發(fā)者極大的靈活性，消息本身將被視為二進(jìn)制塊數(shù)據(jù)。

ZeroMQ提供基本的四種傳輸模型：1)INPROC：進(jìn)程內(nèi)的通信模型；2)IPC：進(jìn)程間的通信模型；3)MULTICAST：多播模型，可能封裝在UDP中；4)TCP：傳統(tǒng)的TCP套接字模式。

ZeroMQ把通訊的需求看成四類。其中一類是一對(duì)一結(jié)對(duì)通訊，用來(lái)支持傳統(tǒng)的TCP socket模型，但并不推薦使用。常用的通訊模式只有三類。

1)請(qǐng)求回應(yīng)(REQ-REP)模式。由請(qǐng)求端發(fā)起請(qǐng)求，并等待回應(yīng)端回應(yīng)請(qǐng)求。從請(qǐng)求端來(lái)看，一定是一對(duì)對(duì)收發(fā)配對(duì)的；反之，在回應(yīng)端一定是發(fā)收對(duì)。請(qǐng)求端和回應(yīng)端都可以是1:N的模型。通常把1認(rèn)為是server，N認(rèn)為是Client。ZeroMQ可以很好的支持路由功能(實(shí)現(xiàn)路由功能的組件叫作Device)，把1:N擴(kuò)展為N:M(只需要加入若干路由節(jié)點(diǎn))。從這個(gè)模型看，更底層的端點(diǎn)地址是對(duì)上層隱藏的。每個(gè)請(qǐng)求都隱含有回應(yīng)地址，而應(yīng)用則不關(guān)心它。

2)發(fā)布訂閱(PUB-SUB)模式。這個(gè)模式里，發(fā)布端是單向只發(fā)送數(shù)據(jù)的，且不關(guān)心是否把全部的信息都發(fā)送給訂閱端。如果發(fā)布端開始發(fā)布信息的時(shí)候，訂閱端尚未連接上來(lái)，這些信息直接丟棄。不過(guò)一旦訂閱端連接上來(lái)，中間會(huì)保證沒(méi)有信息丟失。同樣，訂閱端則只負(fù)責(zé)接收，而不能反饋。如果發(fā)布端和訂閱端需要交互(比如要確認(rèn)訂閱者是否已經(jīng)連接上)，則使用額外的socket采用請(qǐng)求回應(yīng)模型滿足這個(gè)需求。

3)管道(PUSH-PULL)模式。這個(gè)模式里，管道是單向的，從PUSH端單向的向PULL端推送數(shù)據(jù)流。任何分布式，并行的需求，都可以用這三種模型組合起來(lái)解決，如生成我們本技術(shù)發(fā)明所需要使用的DEALER-ROUTER，PUSH-ROUTER模式。DEALER-ROUTER，PUSH-ROUTER模式能實(shí)現(xiàn)無(wú)阻塞的REQ-REP模式功能。

本實(shí)施例中使用的消息可以標(biāo)識(shí)所要發(fā)送的節(jié)點(diǎn)和節(jié)點(diǎn)內(nèi)的某個(gè)線程以及消息類型(reply或request)。圖7是根據(jù)本發(fā)明可選實(shí)施例的整體架構(gòu)示意圖，如圖7所示共分5個(gè)模塊：

接收(Acceptor)模塊用來(lái)負(fù)責(zé)接收其他節(jié)點(diǎn)發(fā)送的消息，當(dāng)接收到一條消息后，Acceptor模塊根據(jù)消息類型是請(qǐng)求消息(request)還是回應(yīng)消息(reply)，將消息分給相應(yīng)的請(qǐng)求-分配器(request-dispatcher)或響應(yīng)-分配器(response-dispatcher)模塊。Request-dispatcher模塊用來(lái)處理將客戶端的請(qǐng)求消息發(fā)送給對(duì)應(yīng)的服務(wù)器(server)線程，這用到了消息中的bucket來(lái)標(biāo)識(shí)對(duì)應(yīng)的server線程。Response-dispatcher模塊用來(lái)處理將服務(wù)器端的響應(yīng)消息發(fā)送給對(duì)應(yīng)的客戶端(client)線程，其中也是通過(guò)消息中的bucket來(lái)標(biāo)識(shí)對(duì)應(yīng)的client線程的。收集(Collectors)模塊維護(hù)了與本節(jié)點(diǎn)所注冊(cè)的其他節(jié)點(diǎn)socket集合。server線程或client線程需要發(fā)送的消息由Collector模塊收集，由socket集合中對(duì)應(yīng)的socket發(fā)送給對(duì)端節(jié)點(diǎn)。在本技術(shù)發(fā)明通信框架中，控制(Controller)模塊用來(lái)動(dòng)態(tài)控制通信節(jié)點(diǎn)的加入和移除。

圖8是根據(jù)本發(fā)明實(shí)施例的通信框架所采用的ZeroMQ傳輸模式示意圖，圖8中顯示了消息從節(jié)點(diǎn)2(node2)發(fā)送到節(jié)點(diǎn)1(node1)，消息可以是由node2的服務(wù)器(server)線程發(fā)送到node1的客戶端(client)線程，也可以是node2的client線程發(fā)送到node1的server線程。通信線程與采集(Collector)模塊之間采用INPROC通信模型構(gòu)造推送-路由(PUSH-ROUTER)模式套接字，collector ROUTER端套接字異步無(wú)阻塞地接收線程發(fā)送的數(shù)據(jù)。兩節(jié)點(diǎn)間采用TCP傳輸模型構(gòu)造請(qǐng)求-應(yīng)答模式(DEALER-ROUTER)，在請(qǐng)求(DEALER)端發(fā)送模塊(senders)集合維護(hù)了此節(jié)點(diǎn)到其他通信節(jié)點(diǎn)的TCP socket集。根據(jù)消息中對(duì)應(yīng)的node ID，找到相應(yīng)的socket，將消息發(fā)送給對(duì)應(yīng)的節(jié)點(diǎn)應(yīng)答(ROUTER)端套接字。Node1在接收(acceptor)模塊接收消息后，根據(jù)消息的類型，由對(duì)應(yīng)的請(qǐng)求-分配器(request-dispatcher)和響應(yīng)-分配器(response-dispatcher)模塊進(jìn)行處理。Request-dispatcher模塊處理client線程請(qǐng)求，與server線程采用INPROC通信模型構(gòu)造發(fā)布-訂閱模式(PUB-SUB)，server線程通過(guò)訂閱與本線程相關(guān)的主題(對(duì)應(yīng)消息結(jié)構(gòu)中的bucket)，接收對(duì)應(yīng)主題的消息。Response-dispatcher模塊處理server線程的回應(yīng)，與client線程采用INPROC通信模型構(gòu)造發(fā)布-訂閱模式(PUB-SUB)，client線程通過(guò)訂閱與本線程相關(guān)的主題(對(duì)應(yīng)消息結(jié)構(gòu)中的bucket)，接收對(duì)應(yīng)主題的消息。這樣就完成了一次不同線程間的消息通信。節(jié)點(diǎn)進(jìn)程與控制器(controller)模塊之間采用INPROC通信模型構(gòu)造管道(PUSH-PULL)模式，controller模塊創(chuàng)建PULL套接字，接收node進(jìn)程發(fā)送的注冊(cè)(register)或去注冊(cè)(unregister)節(jié)點(diǎn)的請(qǐng)求。當(dāng)接收到register請(qǐng)求時(shí)，controller模塊會(huì)創(chuàng)建相對(duì)應(yīng)節(jié)點(diǎn)的DEALER端套接字，連接到對(duì)應(yīng)的節(jié)點(diǎn)，然后將socket加入到senders集合中；當(dāng)接收到unregister請(qǐng)求時(shí)，controller模塊會(huì)注銷對(duì)應(yīng)的DEALER端套接字，并將socket從senders集合中移除。

本實(shí)施例中的通信框架支持不同節(jié)點(diǎn)間跨線程的通信，而不會(huì)相互干擾，同時(shí)，與進(jìn)程的事務(wù)邏輯具有較低的耦合度，同時(shí)支持動(dòng)態(tài)的添加和刪除節(jié)點(diǎn)通信。

通過(guò)上述實(shí)施例避免了目前分布式通信框架復(fù)雜、龐大、臃腫的缺點(diǎn)。利用ZeroMQ通信庫(kù)輕量高效的特點(diǎn)，在此基礎(chǔ)構(gòu)建分布式通信框架，這帶來(lái)了以下優(yōu)點(diǎn)中的至少之一：

(1)提供輕量級(jí)的、高效快速可靠的分布式通信。充分利用ZeroMQ中的多傳輸模型和獨(dú)特的通信模式，降低了復(fù)雜性。

(2)底層通信對(duì)用戶完全透明，使用方便。我們?cè)赯eroMQ的基礎(chǔ)上，提供簡(jiǎn)潔的API，使用方便切簡(jiǎn)單。

(3)支持不同機(jī)器跨進(jìn)程，跨線程的通信，而不相互干擾。

(4)通信模塊間具有較低的耦合度，可支持熱擴(kuò)展。

在本發(fā)明的上述實(shí)施例中，對(duì)各個(gè)實(shí)施例的描述都各有側(cè)重，某個(gè)實(shí)施例中沒(méi)有詳述的部分，可以參見其他實(shí)施例的相關(guān)描述。

在本申請(qǐng)所提供的幾個(gè)實(shí)施例中，應(yīng)該理解到，所揭露的技術(shù)內(nèi)容，可通過(guò)其它的方式實(shí)現(xiàn)。其中，以上所描述的裝置實(shí)施例僅僅是示意性的，例如所述單元的劃分，可以為一種邏輯功能劃分，實(shí)際實(shí)現(xiàn)時(shí)可以有另外的劃分方式，例如多個(gè)單元或組件可以結(jié)合或者可以集成到另一個(gè)系統(tǒng)，或一些特征可以忽略，或不執(zhí)行。另一點(diǎn)，所顯示或討論的相互之間的耦合或直接耦合或通信連接可以是通過(guò)一些接口，單元或模塊的間接耦合或通信連接，或其它的形式。

所述作為分離部件說(shuō)明的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是物理單元，即可以位于一個(gè)地方，或者也可以分布到多個(gè)單元上?？梢愿鶕?jù)實(shí)際的需要選擇其中的部分或者全部單元來(lái)實(shí)現(xiàn)本實(shí)施例方案的目的。

另外，在本發(fā)明各個(gè)實(shí)施例中的各功能單元可以集成在一個(gè)處理單元中，也可以是各個(gè)單元單獨(dú)物理存在，也可以兩個(gè)或兩個(gè)以上單元集成在一個(gè)單元中。上述集成的單元既可以采用硬件的形式實(shí)現(xiàn)，也可以采用軟件功能單元的形式實(shí)現(xiàn)。

所述集成的單元如果以軟件功能單元的形式實(shí)現(xiàn)并作為獨(dú)立的產(chǎn)品銷售或使用時(shí)，可以存儲(chǔ)在一個(gè)計(jì)算機(jī)可讀取存儲(chǔ)介質(zhì)中?；谶@樣的理解，本發(fā)明的技術(shù)方案本質(zhì)上或者說(shuō)對(duì)現(xiàn)有技術(shù)做出貢獻(xiàn)的部分或者該技術(shù)方案的全部或部分可以以軟件產(chǎn)品的形式體現(xiàn)出來(lái)，該計(jì)算機(jī)軟件產(chǎn)品存儲(chǔ)在一個(gè)存儲(chǔ)介質(zhì)中，包括若干指令用以使得一臺(tái)計(jì)算機(jī)設(shè)備(可為個(gè)人計(jì)算機(jī)、服務(wù)器或者網(wǎng)絡(luò)設(shè)備等)執(zhí)行本發(fā)明各個(gè)實(shí)施例所述方法的全部或部分步驟。而前述的存儲(chǔ)介質(zhì)包括：U盤、只讀存儲(chǔ)器(ROM，Read-Only Memory)、隨機(jī)存取存儲(chǔ)器(RAM，Random Access Memory)、移動(dòng)硬盤、磁碟或者光盤等各種可以存儲(chǔ)程序代碼的介質(zhì)。

以上所述僅是本發(fā)明的優(yōu)選實(shí)施方式，應(yīng)當(dāng)指出，對(duì)于本技術(shù)領(lǐng)域的普通技術(shù)人員來(lái)說(shuō)，在不脫離本發(fā)明原理的前提下，還可以做出若干改進(jìn)和潤(rùn)飾，這些改進(jìn)和潤(rùn)飾也應(yīng)視為本發(fā)明的保護(hù)范圍。