本發(fā)明涉及云計算技術(shù)領(lǐng)域，特別是涉及一種用戶態(tài)RPC協(xié)議多線程優(yōu)化方法和系統(tǒng)。
背景技術(shù)：
隨著云計算時代的來臨，人們對于高性能、低成本的數(shù)據(jù)中心的需求越來越迫切，作為數(shù)據(jù)中心最重要的基礎(chǔ)設(shè)施，存儲系統(tǒng)的高性能、高可靠以及低成本等需求也越來越受到關(guān)注。
RPC協(xié)議(遠程調(diào)用協(xié)議Remote Procedure Call)是一種在分布式存儲系統(tǒng)廣泛應用的通信協(xié)議，它可以通過網(wǎng)絡(luò)從遠程計算機程序上請求服務，并且能夠屏蔽底層網(wǎng)絡(luò)的復雜性，還可以對外提供友好的接口。RPC采用客戶機/服務器模式，請求程序就是一個客戶機，而服務提供程序就是一個服務器。首先調(diào)用進程發(fā)送一個有進程參數(shù)的調(diào)用信息到服務進程，然后等待應答信息。在服務器端，進程保持睡眠狀態(tài)直到調(diào)用信息的到達為止。當一個調(diào)用信息到達，服務器獲得進程參數(shù)，計算結(jié)果，發(fā)送答復消息，然后等待下一個調(diào)用信息，最后客戶端調(diào)用過程接收答復信息，獲得進程結(jié)果，然后調(diào)用執(zhí)行繼續(xù)進行。RPC根據(jù)所運行的層次不同分為用戶態(tài)RPC和內(nèi)核態(tài)RPC，用戶態(tài)程序開發(fā)比內(nèi)核態(tài)簡單，被廣泛應用于分布式程序開發(fā)中。但是用戶態(tài)RPC數(shù)據(jù)傳輸效率低，影響了分布式系統(tǒng)的整體性能。
因此，如何提高用戶態(tài)RPC的數(shù)據(jù)傳輸效率，以提高分布式系統(tǒng)的整體性能，是本領(lǐng)域技術(shù)人員目前需要解決的技術(shù)問題。
技術(shù)實現(xiàn)要素：
本發(fā)明的目的是提供一種用戶態(tài)RPC協(xié)議多線程優(yōu)化方法和系統(tǒng)，可以提高用戶態(tài)RPC的數(shù)據(jù)傳輸效率，以提高分布式系統(tǒng)的整體性能。
為解決上述技術(shù)問題，本發(fā)明提供了如下技術(shù)方案：
一種用戶態(tài)RPC協(xié)議多線程優(yōu)化方法，包括：
在RPC服務層通過監(jiān)聽端口監(jiān)聽客戶端是否發(fā)出服務請求；
當所述監(jiān)聽端口監(jiān)聽到服務請求時，調(diào)用一個請求處理端口接管該服務請求；
通過預設(shè)的線程池對所述請求處理端口接管的服務請求進行并行處理。
優(yōu)選地，所述在RPC服務層通過監(jiān)聽端口監(jiān)聽客戶端是否發(fā)出服務請求，包括：
在所述RPC服務層的服務器端重構(gòu)句柄創(chuàng)建函數(shù)；
調(diào)用svc_vc_create創(chuàng)建用于監(jiān)聽客戶端的服務請求的所述監(jiān)聽端口；
調(diào)用svc_fd_create創(chuàng)建請求處理端口；
通過所述監(jiān)聽端口實時監(jiān)聽所述客戶端是否發(fā)出服務請求。
優(yōu)選地，所述當所述監(jiān)聽端口監(jiān)聽到服務請求時，調(diào)用一個請求處理端口接管該服務請求，包括：
啟動服務函數(shù)，查詢所述RPC服務層的所有端口是否有端口接收到信息；
若是，則判斷接收到信息的端口是否為所述監(jiān)聽端口；
若是，則創(chuàng)建一個新請求處理端口接管該服務請求；
若否，則判定該接收到信息的端口為請求處理端口，并根據(jù)預設(shè)的處理請求函數(shù)解碼該端口獲取的服務請求，對該服務請求進行處理。
一種用戶態(tài)RPC協(xié)議多線程優(yōu)化系統(tǒng)，包括：
監(jiān)聽端口，用于在RPC服務層監(jiān)聽客戶端是否發(fā)出服務請求；
請求處理端口，用于當所述監(jiān)聽端口監(jiān)聽到服務請求時，接管該服務請求；
線程池模塊，用于與外界服務器連接，對所述請求處理端口接管的服務請求進行并行處理。
優(yōu)選地，還包括：
端口創(chuàng)建模塊，用于在所述RPC服務層的服務器端重構(gòu)句柄創(chuàng)建函數(shù)，調(diào)用svc_vc_create創(chuàng)建用于監(jiān)聽客戶端的服務請求的所述監(jiān)聽端口，調(diào)用svc_fd_create創(chuàng)建請求處理端口。
優(yōu)選地，還包括：
查詢模塊，用于啟動服務函數(shù)，查詢所述RPC服務層的所有端口是否有端口接收到信息；
判斷模塊，用于在所述查詢模塊查詢到有端口接收到信息時，判斷接收到信息的端口是否為所述監(jiān)聽端口；
第一執(zhí)行模塊，用于在所述判斷模塊判定接收到信息的端口為所述監(jiān)聽端口時，創(chuàng)建一個新請求處理端口接管該服務請求；
第二執(zhí)行模塊，用于在所述判斷模塊判定接收到信息的端口不是所述監(jiān)聽端口時，判定該接收到信息的端口為請求處理端口，并根據(jù)預設(shè)的處理請求函數(shù)解碼該端口獲取的服務請求，對該服務請求進行處理。
與現(xiàn)有技術(shù)相比，上述技術(shù)方案具有以下優(yōu)點：
本發(fā)明所提供的一種用戶態(tài)RPC協(xié)議多線程優(yōu)化方法，包括：在RPC服務層通過監(jiān)聽端口監(jiān)聽客戶端是否發(fā)出服務請求；當監(jiān)聽端口監(jiān)聽到服務請求時，調(diào)用一個請求處理端口接管該服務請求；通過預設(shè)的線程池對請求處理端口接管的服務請求進行并行處理。在本技術(shù)方案中，加入線程池并行處理服務請求，監(jiān)聽端口在監(jiān)聽到客戶端的服務請求后，通過請求處理端口將服務請求放入到線程池，通過線程池調(diào)度線程處理服務請求，監(jiān)聽端口繼續(xù)監(jiān)聽新的請求，而不會終止監(jiān)聽，這樣多個服務請求就可以并行處理，提高了服務器端處理事件的并發(fā)度，大大提高了用戶態(tài)RPC的數(shù)據(jù)傳輸效率，繼而提高分布式系統(tǒng)的整體性能。
附圖說明
為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對實施例或現(xiàn)有技術(shù)描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖是本發(fā)明的一些實施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲得其他的附圖。
圖1為本發(fā)明一種具體實施方式所提供的用戶態(tài)RPC協(xié)議多線程優(yōu)化方法流程圖。
具體實施方式
本發(fā)明的核心是提供一種用戶態(tài)RPC協(xié)議多線程優(yōu)化方法和系統(tǒng)，可以提高用戶態(tài)RPC的數(shù)據(jù)傳輸效率，以提高分布式系統(tǒng)的整體性能。
為了使本發(fā)明的上述目的、特征和優(yōu)點能夠更為明顯易懂，下面結(jié)合附圖對本發(fā)明的具體實施方式做詳細的說明。
在以下描述中闡述了具體細節(jié)以便于充分理解本發(fā)明。但是本發(fā)明能夠以多種不同于在此描述的其它方式來實施，本領(lǐng)域技術(shù)人員可以在不違背本發(fā)明內(nèi)涵的情況下做類似推廣。因此本發(fā)明不受下面公開的具體實施的限制。
請參考圖1，圖1為本發(fā)明一種具體實施方式所提供的用戶態(tài)RPC協(xié)議多線程優(yōu)化方法流程圖。
本發(fā)明的一種具體實施方式提供了一種用戶態(tài)RPC協(xié)議多線程優(yōu)化方法，包括：
S11：在RPC服務層通過監(jiān)聽端口監(jiān)聽客戶端是否發(fā)出服務請求。
在RPC服務層通過監(jiān)聽端口監(jiān)聽客戶端是否發(fā)出服務請求，包括：在RPC服務層的服務器端重構(gòu)句柄創(chuàng)建函數(shù)；調(diào)用svc_vc_create創(chuàng)建用于監(jiān)聽客戶端的服務請求的監(jiān)聽端口；調(diào)用svc_fd_create創(chuàng)建請求處理端口；通過監(jiān)聽端口實時監(jiān)聽客戶端是否發(fā)出服務請求。
S12：當監(jiān)聽端口監(jiān)聽到服務請求時，調(diào)用一個請求處理端口接管該服務請求。
當監(jiān)聽端口監(jiān)聽到服務請求時，調(diào)用一個請求處理端口接管該服務請求，包括：啟動服務函數(shù)，查詢RPC服務層的所有端口是否有端口接收到信息；若是，則判斷接收到信息的端口是否為監(jiān)聽端口；若是，則創(chuàng)建一個新請求處理端口接管該服務請求；若否，則判定該接收到信息的端口為請求處理端口，并根據(jù)預設(shè)的處理請求函數(shù)解碼該端口獲取的服務請求，對該服務請求進行處理。
S13：通過預設(shè)的線程池對請求處理端口接管的服務請求進行并行處理。
在本實施方式中，當監(jiān)聽端口監(jiān)聽到客戶端的服務請求時，該監(jiān)聽端口的監(jiān)聽線程不會終止監(jiān)聽，而是通過請求處理端口去處理該服務請求，并將這個服務請求加入到請求處理線程池，通過線程池調(diào)度相應的線程完成服務請求的處理，監(jiān)聽端口繼續(xù)監(jiān)聽來自客戶端的其他服務請求，接收到服務請求后同樣放入線程池中，如此反復進行，這樣多個服務請求就可以并行處理，提高了服務器端處理事件的并發(fā)度。
其中，本實施方式的技術(shù)方案主要是對TI-RPC進行多線程優(yōu)化。具體地，加入線程池來進行并行處理服務請求；重構(gòu)服務器端句柄創(chuàng)建函數(shù)，增加端口創(chuàng)建時的端口類型判斷；重構(gòu)服務啟動函數(shù)，監(jiān)聽到來自客戶端的請求后，監(jiān)聽端口將服務請求放入到線程池，而監(jiān)聽端口繼續(xù)監(jiān)聽新的服務請求。其中，重構(gòu)句柄創(chuàng)建函數(shù)，調(diào)用svc_vc_create創(chuàng)建監(jiān)聽端口，調(diào)用svc_fd_create創(chuàng)建請求處理端口，創(chuàng)建的監(jiān)聽端口只負責監(jiān)聽不去處理請求信息，而請求處理端口執(zhí)行處理服務請求的服務。啟動服務函數(shù)svc_run，使用poll方法查詢所有的端口是否接收到消息，再調(diào)用宏定義函數(shù)指針SVC_RECV，當poll選擇出來的端口是監(jiān)聽端口時，會創(chuàng)建一個新端口接管監(jiān)聽端口的服務請求，設(shè)定該新端口的SVC_RECV，在線程池中創(chuàng)建一個新的線程去處理這個服務請求，然后返回繼續(xù)查詢各端口是否接收到新信息。若查詢到的端口是請求處理端口，則SVC_RECV就是真正處理服務請求的函數(shù)，它會解碼獲取的服務請求，并對服務請求進行處理，完成請求服務，最后將結(jié)果返回客戶端。
相應地，本發(fā)明一種實施方式還提供了一種用戶態(tài)RPC協(xié)議多線程優(yōu)化系統(tǒng)，包括：監(jiān)聽端口，用于在RPC服務層監(jiān)聽客戶端是否發(fā)出服務請求；請求處理端口，用于當監(jiān)聽端口監(jiān)聽到服務請求時，接管該服務請求；線程池模塊，用于與外界服務器連接，對請求處理端口接管的服務請求進行并行處理。
進一步地，還包括：端口創(chuàng)建模塊，用于在RPC服務層的服務器端重構(gòu)句柄創(chuàng)建函數(shù)，調(diào)用svc_vc_create創(chuàng)建用于監(jiān)聽客戶端的服務請求的監(jiān)聽端口，調(diào)用svc_fd_create創(chuàng)建請求處理端口。
查詢模塊，用于啟動服務函數(shù)，查詢RPC服務層的所有端口是否有端口接收到信息；判斷模塊，用于在查詢模塊查詢到有端口接收到信息時，判斷接收到信息的端口是否為監(jiān)聽端口；第一執(zhí)行模塊，用于在判斷模塊判定接收到信息的端口為監(jiān)聽端口時，創(chuàng)建一個新請求處理端口接管該服務請求；第二執(zhí)行模塊，用于在判斷模塊判定接收到信息的端口不是監(jiān)聽端口時，判定該接收到信息的端口為請求處理端口，并根據(jù)預設(shè)的處理請求函數(shù)解碼該端口獲取的服務請求，對該服務請求進行處理。
在本實施方式中，用戶態(tài)RPC協(xié)議多線程優(yōu)化系統(tǒng)通過對RPC協(xié)議進行多線程優(yōu)化，提高了服務處理的并發(fā)能力，同時可以提高分布式系統(tǒng)的數(shù)據(jù)交換效率，提升系統(tǒng)的吞吐量，從而提高分布式系統(tǒng)的整體性能。
綜上所述，本發(fā)明所提供的用戶態(tài)RPC協(xié)議多線程優(yōu)化方法和系統(tǒng)，可以提高用戶態(tài)RPC的數(shù)據(jù)傳輸效率，以提高分布式系統(tǒng)的整體性能。
以上對本發(fā)明所提供的一種用戶態(tài)RPC協(xié)議多線程優(yōu)化方法和系統(tǒng)進行了詳細介紹。本文中應用了具體個例對本發(fā)明的原理及實施方式進行了闡述，以上實施例的說明只是用于幫助理解本發(fā)明的方法及其核心思想。應當指出，對于本技術(shù)領(lǐng)域的普通技術(shù)人員來說，在不脫離本發(fā)明原理的前提下，還可以對本發(fā)明進行若干改進和修飾，這些改進和修飾也落入本發(fā)明權(quán)利要求的保護范圍內(nèi)。