RPC-DDSF：一種基于RPC的分布式數(shù)據(jù)共享框架*

張 磊，張乾石，尚利宏

(1.中航工業(yè)集團公司 西安航空計算技術研究所,陜西 西安 710068；2.北京航空航天大學 計算機學院,北京 100191)

RPC-DDSF：一種基于RPC的分布式數(shù)據(jù)共享框架*

張 磊1，張乾石2，尚利宏2

(1.中航工業(yè)集團公司 西安航空計算技術研究所,陜西 西安 710068；2.北京航空航天大學 計算機學院,北京 100191)

設計了一種基于RPC的分布式數(shù)據(jù)共享框架RPC-DDSF。RPC-DDSF基于SUN公司的ONCRPC框架，采用模塊化的設計思想，按照功能分為網(wǎng)絡化數(shù)據(jù)池、數(shù)據(jù)對象工廠和自動化測試三大模塊。通過抽象數(shù)據(jù)共享應用的特點，在框架中引入配置文件，實現(xiàn)了對共享數(shù)據(jù)和數(shù)據(jù)共享規(guī)則的可配置性。分析ONCRPC框架中影響數(shù)據(jù)共享性能的因素，通過實驗獲得了不同參數(shù)下ONCRPC性能的不同表現(xiàn)，從而為框架使用者提供一定的指導意義。

分布式數(shù)據(jù)共享；ONCRPC；遠程過程調用；數(shù)據(jù)池

0 引 言

隨著計算機技術的發(fā)展，計算機的價格越來越低，使用計算機解決的問題也越來越復雜。一臺計算機有限的計算能力和存儲能力通常無法解決復雜問題。因此，多臺計算機組成的分布式系統(tǒng)成為解決復雜問題的常用手段。分布式系統(tǒng)中，各臺計算機非完全獨立，而是存在數(shù)據(jù)共享[1]。

不同計算機間實現(xiàn)數(shù)據(jù)共享有多種方式，包括基于socket自定義通信方式以及各種中間件技術[2]，如面向消息中間件[3]和遠程過程調用中間件等[4-5]。

本文給出了一種基于RPC的提供按名稱訪問且具有良好可配置性的分布式數(shù)據(jù)共享框，為分布式系統(tǒng)的開發(fā)提供了極大方便。最后，給出了該框架的典型應用模式及該框架的性能調優(yōu)。

1 RPC-DDSF的設計與實現(xiàn)

1.1 RPC-DDSF的模塊化結構

為了使系統(tǒng)具有良好的可重用性和可維護性，RPC-DDSF采用模塊化結構，如圖1所示，主要包括數(shù)據(jù)對象工廠模塊、網(wǎng)絡化數(shù)據(jù)池模塊、自動化測試模塊。

圖1 RPC-DDSF的模塊化結構

RPC-DDSF中三大模塊的功能：

（1）網(wǎng)絡化數(shù)據(jù)池模塊的主要功能。該模塊的主要作用是負責數(shù)據(jù)對象的存儲以及不同計算機之間數(shù)據(jù)對象的傳輸刷新。數(shù)據(jù)池中存放的數(shù)據(jù)對象需要符合一個基類數(shù)據(jù)對象的定義，并且提供按照數(shù)據(jù)對象的名稱訪問數(shù)據(jù)對象的功能，保證了數(shù)據(jù)對象訪問的時間效率。數(shù)據(jù)對象的訪問規(guī)則描述在一個配置文件中。RPC通信模塊解析這個配置腳本，維護數(shù)據(jù)對象的訪問規(guī)則。網(wǎng)絡化數(shù)據(jù)池模塊向外提供統(tǒng)一的按名稱訪問數(shù)據(jù)對象的接口函數(shù)，并且隱藏訪問實現(xiàn)的具體細節(jié)。用戶可以通過編輯修改訪問規(guī)則配置腳本文件來更改數(shù)據(jù)對象的訪問規(guī)則。

（2）數(shù)據(jù)對象工廠模塊的主要作用。該模塊在系統(tǒng)中扮演著數(shù)據(jù)對象生產者的角色。數(shù)據(jù)對象工廠生產的數(shù)據(jù)對象具有一定的限制，需要符合數(shù)據(jù)池中規(guī)定的基類數(shù)據(jù)對象的定義。數(shù)據(jù)對象工廠模塊同樣接受一個腳本文件，并根據(jù)腳本文件描述的數(shù)據(jù)對象的信息來構建數(shù)據(jù)對象。

（3）自動化測試模塊的主要作用。該模塊主要實現(xiàn)日志記錄和自動化日志分析功能。測試開發(fā)人員通過調用日志記錄模塊將應用運行過程中的一些關鍵信息記錄在日志文件。自動化日志分析模塊可以根據(jù)測試目的自動分析日志文件給出分析結果。

1.2 數(shù)據(jù)對象遠程訪問的要素及描述規(guī)則的設計

數(shù)據(jù)對象遠程訪問的要素主要有兩方面：數(shù)據(jù)對象存儲的位置和數(shù)據(jù)對象訪問方式。在一個分布式系統(tǒng)中，數(shù)據(jù)對象往往存儲在不同的計算機上。數(shù)據(jù)對象遠程訪問首先關心數(shù)據(jù)對象存儲的位置信息。另外，在不同的應用系統(tǒng)中，數(shù)據(jù)對象的訪問存在著不同的實時性要求。對于不需要實時獲得數(shù)據(jù)對象變化的應用場景，適合采用輪詢的模式獲取數(shù)據(jù)對象。而對于需要及時反映數(shù)據(jù)對象變化的應用場景，則適合采用推送的模式，將更新的數(shù)據(jù)對象推送到關心對應數(shù)據(jù)對象的計算機上。為了獲得更廣的應用場景，本文設計的分布式數(shù)據(jù)共享框架同時支持基于輪詢和基于推送的兩種數(shù)據(jù)訪問模式。

RPC采用C/S編程模式，通過在服務器端和客戶端生成的句柄進行交互，交互流程如圖2所示[6]。客戶端應用首先將調用請求發(fā)送給客戶端句柄，客戶端句柄通過網(wǎng)絡將函數(shù)調用的請求發(fā)到服務器端的句柄，服務器端句柄再將請求傳遞給服務器端的執(zhí)行程序，服務器端執(zhí)行對應函數(shù)后將結果返回給服務器端句柄，服務器端句柄再將結果返回給客戶端句柄，并由客戶端句柄將程序調用的結果傳遞給客戶端的執(zhí)行程序，從而完成一次RPC請求的處理。

圖2 遠程過程調用流程

對應數(shù)據(jù)對象遠程訪問的要素，本文設計了相應的描述規(guī)則。對于推送機制維護的數(shù)據(jù)對象，關心的主要是將哪個對象推送到什么位置。因此，推送機制的數(shù)據(jù)訪問方式采用一個二元組＜name，destination＞來描述。其中，name表示被推送數(shù)據(jù)對象的名字，destination表示數(shù)據(jù)對象將被推送到的目標計算機。對于輪詢機制維護的數(shù)據(jù)對象，關心的則是哪個對象按照怎樣的時間周期從哪個計算機上輪詢。因此，輪詢機制的數(shù)據(jù)訪問方式采用一個三元組＜name，timer，source＞來描述。其中，name表示該條輪詢機制維護的數(shù)據(jù)對象的名字，timer表示該條輪詢規(guī)則關聯(lián)的定時器，source表示應該從哪臺計算機上獲得數(shù)據(jù)對象。為了保證數(shù)據(jù)對象訪問的靈活性，將計算機中維護的數(shù)據(jù)對象的所有訪問方式按照上述的描述規(guī)則統(tǒng)一描述在一個腳本文件中（定義這個腳本文件為訪問規(guī)則配置文件）。當需要改變某個數(shù)據(jù)對象的訪問方式時，只需要修改訪問規(guī)則配置文件，而不用修改程序中的代碼，這極大地提高了系統(tǒng)的靈活性和可配置性。

在一個分布式系統(tǒng)中，通常每臺計算機都存在與其他計算機的數(shù)據(jù)交互。因此，每臺計算機都需要有一個訪問規(guī)則配置文件。為了使訪問規(guī)則配置文件描述的盡量清晰、簡潔，將訪問規(guī)則配置文件中描述的內容分成了四個部分。

第一部分描述本機與其他計算機建立RPC通信句柄的相關信息。一臺計算機通常與分布式系統(tǒng)中的多臺計算機之間存在數(shù)據(jù)共享，因此需要建立多個RPC通信句柄。每個RPC通信句柄的建立都需要提供IP地址、傳輸層協(xié)議、重傳時間和最大重傳時間四方面信息。下面介紹這四方面信息的意義。IP地址描述RPC句柄另一端連接的計算機的IP地址；由于ONCRPC的實現(xiàn)支持TCP和UDP兩種傳輸層協(xié)議，因此在配置文件中提供了對這兩種傳輸層協(xié)議的配置選項，以供開發(fā)者靈活使用；重傳時間和最大重傳時間是ONCRPC協(xié)議實現(xiàn)中兩個影響RPC傳輸效率的重要參數(shù)，同樣提供了可配置性的支持。重傳時間表示RPC請求發(fā)出后等待響應的時間。如果等待響應的時間超過了重傳時間，就會重新發(fā)送RPC請求。最大重傳時間限制了重傳的次數(shù)。如果總的請求等待時間超過了最大重傳時間，就認定此次RPC請求失敗，放棄本次請求。通過增加重傳時間和最大重傳時間的可配置性支持，使開發(fā)者可以根據(jù)自己應用的特點靈活設置這兩個參數(shù)，并且便于測試人員對系統(tǒng)進行性能測試。

第二部分描述了通過推送方式維護的數(shù)據(jù)對象的信息。根據(jù)推送模式的二元描述規(guī)則定義，在腳本文件中需要描述要推送的數(shù)據(jù)對象以及推送的目的地。通常，需要向一個目的地推送多個數(shù)據(jù)對象。為了減少描述信息的重復，在一個推送目的地信息之后，描述向這個目的地推送的所有數(shù)據(jù)對象的信息。

第三部分描述輪詢機制中的定時器信息。主要描述本機維護的輪詢規(guī)則中不同輪詢周期的定時器，包括定時器的個數(shù)和每個定時器的輪詢周期信息。

第四部分描述了通過輪詢方式維護的數(shù)據(jù)對象的信息。根據(jù)輪詢模式的三元描述規(guī)則定義，在腳本中需要描述數(shù)據(jù)對象的名字、輪詢對應的定時器和輪詢數(shù)據(jù)對象的存儲位置。其中，輪詢對應的定時器對應第三部分中描述的定時器。

1.3 數(shù)據(jù)池中數(shù)據(jù)對象訪問規(guī)則的實現(xiàn)方式

腳本解析模塊解析訪問規(guī)則配置腳本生成相應的數(shù)據(jù)對象的過程如圖3所示。

圖3 訪問規(guī)則配置腳本的解析

由于訪問規(guī)則配置文件存儲在外存中，讀寫速度較慢。如果每次需要查詢某個數(shù)據(jù)對象的訪問規(guī)則時都去讀取配置文件，將大大降低系統(tǒng)運行的效率。因此，在訪問規(guī)則實現(xiàn)上，采用一些特定的數(shù)據(jù)結構來存儲訪問規(guī)則配置文件中的配置信息。

這些特定的數(shù)據(jù)結構包括：

（1）存放RPC句柄的順序表。通過一個順序表存儲與本計算機存在數(shù)據(jù)交互關系的所有計算機的RPC句柄。訪問規(guī)則配置腳本中，通過順序表中的位置來確定跨計算機讀寫某個數(shù)據(jù)對象時，應該進行交互的RPC句柄。

（2）存放定時器的順序表。在一臺計算機上，不同數(shù)據(jù)對象的刷新頻率可能不同，因此通過一個順序表來存儲不同觸發(fā)周期的定時器。同樣，訪問規(guī)則配置腳本通過順序表中的位置來確定某個輪詢訪問規(guī)則應該關聯(lián)的定時器。

（3）存放輪詢規(guī)則的哈希表。當某個定時器一個時間周期結束時，需要更新關聯(lián)在這個定時器上所有的數(shù)據(jù)對象。因此，通過一個哈希表來存儲本計算機上所有的輪詢規(guī)則信息。該哈希表的key是本計算機上的一個定時器對象，value是與該定時器綁定的所有的數(shù)據(jù)對象，通過一個順序表來存儲。

（4）存放推送規(guī)則的哈希表。通過一個哈希表存儲本計算機上所有的推送規(guī)則信息。該哈希表的key是某個數(shù)據(jù)對象的名字，value是一個列表，存儲關心該數(shù)據(jù)對象的所有計算機的RPC句柄。當某個基于推送機制的數(shù)據(jù)對象發(fā)生變化時，需要通過該數(shù)據(jù)結構將新的數(shù)據(jù)對象推送到所有關心該數(shù)據(jù)對象的計算機上。

在分布式系統(tǒng)中的計算機啟動時，讀取訪問規(guī)則配置文件，將配置文件傳遞給腳本解析模塊進行解析，并將其中的訪問規(guī)則信息存儲在相應的數(shù)據(jù)結構中。數(shù)據(jù)對象的共享訪問就可以通過這些特定的數(shù)據(jù)結構來進行維護，而不必每次從外存中讀取配置文件。

2 典型應用模式

分布式系統(tǒng)中每臺計算機都有且只有一個物理上的數(shù)據(jù)池存儲數(shù)據(jù)對象。按照功能不同，數(shù)據(jù)池從邏輯上可分為存儲池和緩存池。存儲池負責存儲數(shù)據(jù)對象的正本，緩沖池存儲數(shù)據(jù)對象的副本。某一時刻，任意數(shù)據(jù)對象的正本只能存在于一臺計算機上，但是該數(shù)據(jù)對象可以有多個副本。每個需要用到該數(shù)據(jù)對象的計算機的數(shù)據(jù)池中都可以存儲該數(shù)據(jù)對象的一個副本。緩沖池中數(shù)據(jù)對象的副本必須按照存儲池中同名數(shù)據(jù)對象的正本進行刷新。本文設計的數(shù)據(jù)池既可設計C/S架構的應用也可設計P2P架構的應用，同時還可構建兩種架構混合的應用。

2.1 基于C/S架構的應用模式

基于C/S架構的應用，存儲池只存在于作為服務器端的計算機上。所有的數(shù)據(jù)對象正本都存儲在作為服務器端的計算機的數(shù)據(jù)池中，其他計算機作為客戶端?？蛻舳酥械臄?shù)據(jù)池在邏輯上都是緩存池。客戶端通過RPC協(xié)議從服務器端的數(shù)據(jù)池中獲得數(shù)據(jù)對象的正本，并緩存在本地數(shù)據(jù)池中?？蛻舳藢彌_池中某個數(shù)據(jù)對象的更改，都會更新到服務器端的存儲池中，再由服務器端更新其他計算機緩沖池中數(shù)據(jù)對象的副本，或由其他計算機通過輪詢機制從服務器端獲得最新的數(shù)據(jù)對象。C/S架構下推送訪問方式的原理見圖4，其優(yōu)點是客戶端訪問規(guī)則配置腳本編寫簡單，缺點是數(shù)據(jù)對象更新較慢。

圖4 C/S架構下推送機制的實現(xiàn)原理

2.2 基于P2P架構的應用模式

基于P2P架構的應用，每個計算機都可存儲并維護分布式系統(tǒng)中數(shù)據(jù)對象的正本，也可存儲本節(jié)點機應用層關心的數(shù)據(jù)對象副本。因此，數(shù)據(jù)池在邏輯上既包括存儲池也包括緩存池。當某個計算機更新數(shù)據(jù)對象時，可以直接根據(jù)訪問規(guī)則配置腳本中描述的規(guī)則，將最新數(shù)據(jù)對象推送到對應的計算機或者等待關心改變后數(shù)據(jù)對象值的計算機來輪詢。P2P架構下推送訪問方式的實現(xiàn)原理見圖5，其優(yōu)點是推送模式下數(shù)據(jù)對象更新快，缺點是訪問規(guī)則配置腳本編寫復雜。

圖5 P2P架構下推送機制的實現(xiàn)原理

2.3 混合架構的應用模式

混合應用模式是C/S架構應用模式和P2P架構應用模式的結合。在整個分布式系統(tǒng)中，一部分計算機維護著C/S架構，一部分計算機維護著P2P架構?；旌霞軜嬒峦扑驮L問方式的實現(xiàn)原理見圖6。系統(tǒng)設計中，主要根據(jù)應用特點決定分布式系統(tǒng)中計算機采用的架構形式。

圖6 混合架構下推送機制的實現(xiàn)原理

3 性能調優(yōu)

一個分布式數(shù)據(jù)共享框架，使用者關心的性能參數(shù)主要包括實時性、重傳占比和有效吞吐量。本文設計的分布式數(shù)據(jù)共享框架基于ONCRPC，數(shù)據(jù)對象傳輸由ONCRPC完成。因此，上述三方面性能由ONCRPC決定。

實時性可通過從RPC請求發(fā)出到獲得RPC響應的最長時間來刻畫。ONCRPC中，RPC請求一段時間內沒有收到回復會重新發(fā)送請求。重傳占比表示系統(tǒng)運行一段時間中作為重傳的RPC請求占總的RPC請求的比例。重傳占比反映了網(wǎng)絡傳輸?shù)男?。重傳占比越大，表示越多的RPC請求是無效請求，網(wǎng)絡資源利用率也越低；反之則越高。有效吞吐量表示單位時間內完成RPC請求的數(shù)量，表明計算機在特定測試環(huán)境下處理RPC請求的能力。

在ONCRPC中，上述三方面性能的好壞主要由重傳時間這個參數(shù)決定。重傳時間表示一次RPC請求發(fā)出后多長時間內沒有收到回復會重新發(fā)出請求。

3.1 測試環(huán)境設置

在現(xiàn)有測試環(huán)境中，通過在一臺計算機上生成30個線程來模擬30個RPC客戶端，用另一臺單獨的計算機作為RPC的服務器端。兩臺計算機的軟硬件配置如表1所示。設置RPC請求的頻率為1.25 ms一次來保證足夠的RPC請求。

3.2 實時性測試

不同重傳時間下，系統(tǒng)實時性的表現(xiàn)見圖7?？梢姡S著重傳時間的增大，最差情況下RPC請求的處理時間逐漸增大，即系統(tǒng)實時性逐漸變差。因此，當系統(tǒng)對實時性要求較為嚴格時，應該設置一個較小的RPC重傳時間，以獲得較好的實時性。

表1 計算機的軟硬件配置

圖7 不同重傳時間下的實時性分析結果

進一步分析，當重傳時間設置為5 ms時，客戶端RPC請求處理的最差時間是48 ms，說明最差情況下的RPC請求重傳9次才完成了RPC請求處理；當重傳時間設置為100 ms時，客戶端RPC請求處理的最差時間是204 ms，說明最差情況下RPC請求重傳2次就完成了RPC請求處理。通過對比發(fā)現(xiàn)：設置重傳時間為5 ms，雖然獲得了較好的實時性，但是出現(xiàn)了大量重傳；設置重傳時間為100 ms，雖然實時性較差，但是最差情況下的重傳次數(shù)較少。

通過計算可以求得，設置不同重傳時間時，最差情況下RPC請求重傳的次數(shù)如表2所示。通過表2可以看出，隨著重傳時間的增大，最差情況下的重傳次數(shù)逐漸減小。當重傳時間增大到一定值時，最大重傳次數(shù)趨于穩(wěn)定。因此，當應用關注于網(wǎng)絡資源利用率時，應該選擇一個較大的重傳時間。

表2 不同重傳時間下最大重傳次數(shù)

3.3 重傳占比測試

在重傳占比性能測試過程中，首先對不同重傳時間設置下重傳次數(shù)的分布進行測量。若某次RPC處理的時間小于重傳時間，說明該次請求沒有進行重傳；如果該次請求的時間大于重傳時間但是小于兩倍的重傳時間，說明該次RPC請求重傳了一次。依次類推，可以獲得測試結果中關于重傳次數(shù)的信息。不同重傳時間下重傳次數(shù)所占比見表3。

表3 不同重傳時間下最大重傳次數(shù)

根據(jù)重傳占比的概念及上述測得的不同重傳時間下重傳次數(shù)的分布，可獲得不同重傳時間間隔下總的重傳占比分布，見圖8。從圖8可見，隨著重傳時間的增大，總的重傳占比逐漸減小并趨于穩(wěn)定。因此，要高效利用網(wǎng)絡資源，需選擇較大的重傳時間。

圖8 不同重傳時間下的重傳占比分析結果

3.4 吞吐量測試

吞吐量反映了單位時間內RPC請求被處理的次數(shù)。當前測試環(huán)境下，設置不同重傳時間獲得的吞吐量分布如圖9所示。

圖9 不同重傳時間下的吞吐量分析結果

測試結果表明：當重傳時間的取值在50 ms到100 ms之間時，影響吞吐量的主要因素是重傳時間。因為重傳時間越大，當某次RPC請求未得到響應時，需要等待的時間越長。但是，當重傳時間取值在20 ms到50 ms之間時，結合重傳占比的分布可以發(fā)現(xiàn)，吞吐量的取值則主要由系統(tǒng)重傳占比的情況決定。因為重傳占比越大，意味著越多的RPC請求是無效請求。當重傳時間小于20 ms時，吞吐量的取值重新變成由重傳時間來決定，且吞吐量逐漸趨于穩(wěn)定。

4 結 語

分布式數(shù)據(jù)共享是當前解決復雜問題采用分布式系統(tǒng)的一個通用問題。本文提出的基于RPC的分布式數(shù)據(jù)共享框架具有良好的可配置性，能夠很好地適應需求不確定的應用場景。最后，本文提供了RPC-DDSF性能調優(yōu)的方法及一種測試環(huán)境中的結果，結果對框架的使用者具有一定的指導意義。

[1] Khan R Z,Ali M F.An Efficient Diffusion Load Balancing Algorithm in Distributed System[J].International Journal of Information Technology & Computer Science,2014,6(08):65-71.

[2] Qilin L,Mintian Z.The State of the Art in Middleware[J]. International Forum on Information Technology and Applications-Volume,2010(01):83-85.

[3] Tran P,Greenfield P,Gorton I.Behavior and Performance of Message-oriented Middleware Systems[C]. IEEE:International Conference on Distributed Computing Systems Workshops,2002,7(02):645-650.

[4] Wang X,Zhao H,Zhu J.GRPC:A Communication Cooperation Mechanism in Distributed Systems[J]. Operating Systems Review,1993,27(03):75-86.

[5] Chen H,Shi L,Sun J,Li K,et al.A Fast RPC System for Virtual Machines[J].Parallel and Distributed Systems,2013,24(07):1267-1276.

[6] Srivastava S,Srivastava P.K.Performance Analysis of Sun RPC[C].Bangalore:National Conference on Parallel Computing Technologies,2013:1-8.

張 磊（1984—），男，學士，工程師，主要研究方向為總線技術、實時系統(tǒng)；

張乾石（1991—），男，碩士，主要研究方向為嵌入式系統(tǒng)；

尚利宏（1971—），男，博士，副教授，主要研究方向為嵌入式系統(tǒng)、容錯系統(tǒng)。

RPC-DDSF: A Distributed Data Sharing Framework based on RPC

ZHANG Lei1, ZHANG Qian-shi2, SHANG Li-hong2
(AVIC Computing Technique Research Institute, Xi'an Shanxi 710068, China; School of Computer Science and Engineering, Beihang University, Beijing 100191, China)

A distributed data sharing framework named RPC-DDSF, which based on ONCRPC, is designed. RPC-DDSF adopts modular concept and can be divided into network data pool model, data object factory model and automatic test model according to function. By abstracting data sharing application features and introducing profi les, the framework is confi gurable both in shared data and data sharing rules. The factors that affect the performance of data sharing in ONCRPC framework are analyzed, and the different performance of ONCRPC under different parameters are obtained through experiments, which provides a guide for the users of the framework.

Distributed data sharing;ONCRPC;Remote procedure call;Data pool

TN393.0

: A

：1002-0802(2016)-06-0745-06

10.3969/j.issn.1002-0802.2016.06.018

2016-02-08;

：2016-05-03 Received date:2016-02-08;Revised date:2016-05-03