本發(fā)明涉及數(shù)據(jù)通信技術(shù)領(lǐng)域，具體是一種利用消息隊列優(yōu)化服務(wù)器處理請求的方法。

背景技術(shù)：

“消息”是在兩臺計算機間傳送的數(shù)據(jù)單位。“消息隊列”是在消息的傳輸過程中保存消息的容器。消息隊列將消息從源傳遞到目標(biāo)時充當(dāng)中間人。隊列的主要目的是提供路由并保證消息的傳遞；如果發(fā)送消息時接收者不可用，消息隊列會保留消息，直到可以成功地傳遞它。傳統(tǒng)的用戶和服務(wù)器之間的通信不可避免通信過程的復(fù)雜性，而用戶往往希望關(guān)注的只是最后得到的通知，利用消息隊列可以很好的實現(xiàn)這一需求。

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

本發(fā)明提供了一種利用消息隊列優(yōu)化服務(wù)器處理請求的方法，解決了消息隊列中信息丟失和重復(fù)不能同時實現(xiàn)的問題，較好的實現(xiàn)了用戶和服務(wù)器之間的分離，提高了服務(wù)器處理請求的效率。

本發(fā)明是通過如下技術(shù)方案實現(xiàn)的：

一種利用消息隊列優(yōu)化服務(wù)器處理請求的方法，包括用戶和服務(wù)器，在用戶與服務(wù)器之間有消息隊列，所述消息隊列處理、合并用戶請求消息，將處理結(jié)果推送給服務(wù)器執(zhí)行，提高服務(wù)器處理用戶請求的效率。

優(yōu)選的是，所述消息隊列分為三種類型：可執(zhí)行消息隊列：存放的用戶請求直接推送給相應(yīng)的空閑服務(wù)器執(zhí)行；排隊等候消息隊列：存放的用戶請求按到達(dá)的先后順序在此隊列中排隊等候；備份消息隊列：存放復(fù)制過的用戶請求消息。

優(yōu)選的是，用戶請求到達(dá)消息隊列后的處理過程如下步驟：

步驟一：用戶請求到達(dá)消息隊列端后，消息隊列判斷此時服務(wù)器是否處于空閑狀態(tài)；若是，則請求消息被放入可執(zhí)行消息隊列中，依次推送給服務(wù)器執(zhí)行；步驟二：若服務(wù)器處于忙碌狀態(tài)，則用戶請求消息被放入排隊等候隊列，依次加入隊列末尾排隊等候；步驟三：當(dāng)有新的用戶請求到達(dá)后，消息隊列將判斷排隊等候消息隊列中是否有與該新到達(dá)的請求相同的消息：如果有，則依次遍歷排隊等候消息隊列，找到與新到達(dá)請求相同的消息所處的位置，將兩個請求消息進行合并，放入該位置；如果排隊等候隊列中沒有與該請求相同的消息，則新到達(dá)的請求將被放到排隊等候隊列的末尾，等待執(zhí)行；步驟四：當(dāng)服務(wù)器由忙碌狀態(tài)轉(zhuǎn)換到空閑狀態(tài)后，可執(zhí)行消息隊列將排隊等候隊列中存放的請求消息依次調(diào)入，并推送給服務(wù)器端執(zhí)行；步驟五：推送請求消息之前，將備份一份此請求放入備份消息隊列中。

優(yōu)選的是，所述消息隊列與所述服務(wù)器之間利用報文傳送進行通信。

優(yōu)選的是，所述報文傳送包括以下報文：request報文：用戶向消息隊列發(fā)送請求消息使用的報文；reply報文：服務(wù)器向用戶返回處理結(jié)果使用的報文；push報文：可執(zhí)行消息隊列向服務(wù)器推送可執(zhí)行的請求消息使用的報文；invalid報文：服務(wù)器返回?zé)o效的請求給消息隊列使用的報文；ack報文：服務(wù)器確認(rèn)消息隊列端發(fā)送的請求消息使用的報文。

優(yōu)選的是，所述消息隊列將可執(zhí)行消息推送給服務(wù)器之前，將會做一份備份，放入備份消息隊列中；如果請求消息推送失敗，將重傳備份消息隊列中的該請求消息；服務(wù)器成功收到此請求消息后，備份隊列中的備份信息將被刪除；每發(fā)送一次備份消息，將會在此備份消息中添加一個序列號來防止因鏈路故障而導(dǎo)致服務(wù)器端接收到重復(fù)消息。

優(yōu)選的是，所述消息隊列和所述服務(wù)器溝通過程如下步驟：步驟一：取出可執(zhí)行消息隊列最前端的請求消息，將此請求消息備份一份放入備份消息隊列中，利用push報文將該請求消息發(fā)送到服務(wù)器；步驟二：服務(wù)器接收到此請求消息后，將判斷是否能夠處理此請求消息：如果能處理，則向消息隊列端返回一個ack報文，確認(rèn)自己正確收到并可以處理此消息；如果不能，則向消息隊列返回一個invalid報文，通知消息隊列端自己無法處理此請求消息；步驟三：如果消息隊列收到服務(wù)器發(fā)來的報文是ack報文，則將備份消息隊列中關(guān)于該已被確認(rèn)的請求消息的備份刪除；步驟四：如果消息隊列端收到服務(wù)器發(fā)來的報文是invalid報文，則將備份消息隊列中的該請求消息通過push報文發(fā)向其他的空閑服務(wù)器；步驟五：如果消息隊列端沒有收到服務(wù)器發(fā)回的任何響應(yīng)報文，則將會重傳備份消息隊列中的該請求消息的備份，并在此備份消息中加入一個起始序列號1，此后每一次重傳，序列號都會增加1，直至序列號加到5，便直接刪除備份消息隊列中的該請求消息的備份。

優(yōu)選的是，所述步驟五中，造成消息隊列收不到服務(wù)器發(fā)回的任何響應(yīng)報文的原因是鏈路故障造成的。

優(yōu)選的是，在鏈路故障恢復(fù)，而備份消息卻已經(jīng)發(fā)出的情況下，備份請求消息的序號便能夠解決服務(wù)器收到重復(fù)消息的問題；服務(wù)器接收到相同的請求消息時，發(fā)現(xiàn)里面帶有序列號或者序列號比自己之前已經(jīng)收到的備份請求消息中的序列號要大，則會直接丟棄新收到的重復(fù)消息，并向消息隊列端重發(fā)確認(rèn)消息。

本發(fā)明的有益效果是：

消息隊列的使用使得用戶只需關(guān)注最后的通知，而不需參與整個請求處理的過程；消息隊列的分類機制較好的適應(yīng)了服務(wù)器的狀態(tài)變化，請求消息的備份、相同請求消息的合并、消息重傳機制的實現(xiàn)，提高了服務(wù)器處理用戶請求的效率。

附圖說明

圖1為發(fā)明中的整體架構(gòu)示意圖；

圖2為消息隊列原理框圖；

圖3為數(shù)據(jù)流圖；

圖4為消息隊列工作過程。

具體實施方式

以下結(jié)合附圖1至附圖4所示，通過具體實施例對本發(fā)明作進一步的說明。

一、消息隊列接收用戶請求消息的機制：

可執(zhí)行消息隊列：存放的用戶請求直接推送給相應(yīng)的空閑服務(wù)器執(zhí)行；

排隊等候消息隊列：存放的用戶請求按到達(dá)的先后順序在此隊列中排隊等候；

備份消息隊列：存放復(fù)制過的用戶請求消息。

(1)用戶請求到達(dá)消息隊列端后，消息隊列判斷此時服務(wù)器是否處于空閑狀態(tài)；若是，則請求消息被放入可執(zhí)行消息隊列中，依次推送給服務(wù)器執(zhí)行。

(2)若服務(wù)器處于忙碌狀態(tài)，則用戶請求消息被放入排隊等候隊列，依次加入隊列末尾排隊等候。

(3)當(dāng)有新的用戶請求到達(dá)后，消息隊列端將判斷排隊等候消息隊列中是否有與該新到達(dá)的請求相同的消息：

如果有，則依次遍歷排隊等候消息隊列，找到與新到達(dá)請求相同的消息所處的位置，將兩個請求消息進行合并，放入該位置；

如果排隊等候隊列中沒有與該請求相同的消息，則新到達(dá)的請求將被放到排隊等候隊列的末尾，等待執(zhí)行。

(4)當(dāng)服務(wù)器由忙碌狀態(tài)轉(zhuǎn)換到空閑狀態(tài)后，可執(zhí)行消息隊列將排隊等候隊列中存放的請求消息依次調(diào)入，并推送給服務(wù)器端執(zhí)行。

(5)推送請求消息之前，將備份一份此請求放入備份消息隊列中。

二、消息隊列端實現(xiàn)可靠投遞與避免消息重復(fù)機制：

消息隊列將可執(zhí)行消息推送給服務(wù)器之前，將會做一份備份，放入備份消息隊列中。如果請求消息推送失敗，可以重傳備份消息隊列中的該請求消息；服務(wù)器成功收到此請求消息后，備份隊列中的備份信息將被刪除。每發(fā)送一次備份消息，將會在此備份消息中添加一個序列號來防止因鏈路故障而導(dǎo)致服務(wù)器端接收到重復(fù)消息。

三、消息隊列端和服務(wù)器之間利用報文傳送進行通信機制：

request報文：用戶向消息隊列發(fā)送請求消息使用的報文；

reply報文：服務(wù)器向用戶返回處理結(jié)果使用的報文；

push報文：可執(zhí)行消息隊列向服務(wù)器推送可執(zhí)行的請求消息使用的報文；

invalid報文：服務(wù)器返回?zé)o效的請求給消息隊列使用的報文；

ack報文：服務(wù)器確認(rèn)消息隊列端發(fā)送的請求消息使用的報文。

(1)取出可執(zhí)行消息隊列最前端的請求消息，將此請求消息備份一份放入備份消息隊列中。利用push報文將該請求消息發(fā)送到服務(wù)器；

(2)服務(wù)器接收到此請求消息后，將判斷是否能夠處理此請求消息：

如果能處理，則向消息隊列端返回一個ack報文，確認(rèn)自己正確收到并可以處理此消息；

如果不能，則向消息隊列返回一個invalid報文，通知消息隊列端自己無法處理此請求消息。

(3)如果消息隊列收到服務(wù)器發(fā)來的報文是ack，則將備份消息隊列中關(guān)于該已被確認(rèn)的請求消息的備份刪除；

(4)如果消息隊列端收到服務(wù)器發(fā)來的報文是invalid，則將備份消息隊列中的該請求消息通過push報文發(fā)向另外的空閑服務(wù)器；

(5)如果消息隊列端沒有收到服務(wù)器發(fā)回的任何響應(yīng)報文，則將會重傳備份消息隊列中的該請求消息的備份，并在此備份消息中加入一個起始序列號1，此后每一次重傳，序列號都會增加1，直至序列號加到5，便直接刪除備份消息隊列中的該請求消息的備份；

(6)造成消息隊列端收不到服務(wù)器發(fā)回的任何響應(yīng)報文的原因可能是鏈路故障造成的。在鏈路故障恢復(fù)，而備份消息卻已經(jīng)發(fā)出的情況下，備份請求消息的序號便可以解決服務(wù)器收到重復(fù)消息的問題。服務(wù)器接收到相同的請求消息時，發(fā)現(xiàn)里面帶有序列號或者序列號比自己之前已經(jīng)收到的備份請求消息中的序列號要大，則會直接丟棄新收到的重復(fù)消息，并向消息隊列端重發(fā)確認(rèn)消息。

實施例：

如圖1所示，用戶與服務(wù)器之間增加了消息隊列端，效果是用戶和服務(wù)器不直接相連，消息隊里起到中間人的作用。

如圖2所示，消息隊列端中包含的三個部分：

可執(zhí)行消息隊列：存放的用戶請求直接推送給相應(yīng)的空閑服務(wù)器執(zhí)行；

排隊等候消息隊列：存放的用戶請求按到達(dá)的先后順序在此隊列中排隊等候；

備份消息隊列：存放復(fù)制過的用戶請求消息。

如圖3和圖4所示，消息隊列實現(xiàn)服務(wù)器性能優(yōu)化工作流程如下：

(1)用戶通過request報文向消息隊列發(fā)送請求消息。

(2)用戶請求到達(dá)消息隊列端后，消息隊列判斷此時服務(wù)器是否處于空閑狀態(tài)；若是，則請求消息被放入可執(zhí)行消息隊列中，等待推送給服務(wù)器執(zhí)行。

(3)若服務(wù)器處于忙碌狀態(tài)，則用戶請求消息被放入排隊等候隊列，依次加入隊列末尾排隊等候。

(4)當(dāng)有新的用戶請求到達(dá)后，消息隊列端將判斷排隊等候消息隊列中是否有與該新到達(dá)的請求相同的消息；

如果有，則依次遍歷排隊等候消息隊列，找到與新到達(dá)請求相同的消息所處的位置，將兩個請求消息進行合并，放入該位置；

如果排隊等候隊列中沒有與該請求相同的消息，則新到達(dá)的請求將被放到排隊等候隊列的末尾，等待執(zhí)行。

(5)當(dāng)服務(wù)器由忙碌狀態(tài)轉(zhuǎn)換到空閑狀態(tài)后，可執(zhí)行消息隊列將排隊等候隊列中存放的請求消息依次調(diào)入，等待推送給服務(wù)器端執(zhí)行。

(6)取出可執(zhí)行消息隊列最前端的請求消息，將此請求消息備份一份放入備份消息隊列中。利用push報文將該請求消息發(fā)送到服務(wù)器。

(7)服務(wù)器接收到此請求消息后，將判斷是否能夠處理此請求消息：

如果能處理，則向消息隊列端返回一個ack報文，確認(rèn)自己正確收到并可以處理此消息；

如果不能，則向消息隊列返回一個invalid報文，通知消息隊列端自己無法處理此請求消息。

(8)如果消息隊列收到服務(wù)器發(fā)來的報文是ack，則將備份消息隊列中關(guān)于該已被確認(rèn)的請求消息的備份刪除。

(9)如果消息隊列端收到服務(wù)器發(fā)來的報文是invalid，則將備份消息隊列中的該請求消息通過push報文發(fā)向另外的空閑服務(wù)器。

(10)如果消息隊列端沒有收到服務(wù)器發(fā)回的任何響應(yīng)報文，則將會重傳備份消息隊列中的該請求消息的備份，并在此備份消息中加入一個起始序列號1，此后每一次重傳，序列號都會增加1，直至序列號加到5，便直接刪除備份消息隊列中的該請求消息的備份；

造成消息隊列端收不到服務(wù)器發(fā)回的任何響應(yīng)報文的原因可能是鏈路故障造成的。在鏈路故障恢復(fù)，而備份消息卻已經(jīng)發(fā)出的情況下，備份請求消息的序號便可以解決服務(wù)器收到重復(fù)消息的問題。服務(wù)器接收到相同的請求消息時，發(fā)現(xiàn)里面帶有序列號或者序列號比自己之前已經(jīng)收到的備份請求消息中的序列號要大，則會直接丟棄新收到的重復(fù)消息，并向消息隊列端重發(fā)確認(rèn)消息。

(11)服務(wù)器將處理好的請求消息直接通過reply報文返還給用戶。