專利名稱：服務(wù)器排隊系統(tǒng)和方法
背景技術(shù)：
排隊系統(tǒng)允許若干不同的用戶(和/或進程)發(fā)送數(shù)據(jù)和/或處理請求，這些數(shù)據(jù)和請求將被存儲在隊列中以供接收子系統(tǒng)稍后使用。例如，項目服務(wù)器子系統(tǒng)可以向排隊系統(tǒng)發(fā)送一條或多條消息。排隊系統(tǒng)存儲該信息，直到接收子系統(tǒng)能夠檢索并處理所存儲的信息。然而，機器故障和子系統(tǒng)與排隊系統(tǒng)之間和之中的通信中斷可能會引起處理中的差錯和/或使得不能夠處理所存儲的信息。

發(fā)明內(nèi)容
本發(fā)明針對用于可靠消息傳送的服務(wù)器排隊方法和系統(tǒng)。排隊系統(tǒng)可以在例如其中一個子系統(tǒng)想要異步地執(zhí)行一個或多個已排序操作的情況中使用。消息被成組地發(fā)送給隊列，一組中可以含有一條或多條消息。在特定組中的消息以預(yù)定的順序處理。消息組可以被標(biāo)記為相關(guān)的，使得特定相關(guān)中的所有組可以按預(yù)定的順序處理。消息可以被存儲在SQL數(shù)據(jù)庫表中，直到對該消息的處理完成。消息系統(tǒng)的接收方可以跨多個機器和/或跨任何給定機器的可用資源而縮放。系統(tǒng)可以處理發(fā)送方的“災(zāi)難”情形(即，發(fā)送機器在發(fā)送組過程中崩潰)和接收方的“災(zāi)難”情形(即，電源故障引起至少一個接收機器上的重新引導(dǎo))。
在本發(fā)明的一方面中，一種排隊系統(tǒng)接收從發(fā)送者子系統(tǒng)發(fā)送的消息組，其中，每一消息組包含至少一條消息。所接收的消息組使用排隊系統(tǒng)以預(yù)定的順序存儲。排隊系統(tǒng)接收每一消息組的相關(guān)標(biāo)識符；所接收的相關(guān)標(biāo)識符使用排隊系統(tǒng)存儲。所存儲的消息組和相關(guān)標(biāo)識符根據(jù)預(yù)定的順序發(fā)送。


圖1示出了根據(jù)本發(fā)明的示例性實施例可以使用的計算設(shè)備。
圖2示出了根據(jù)本發(fā)明的各方面用于可靠消息傳送的排隊系統(tǒng)的框圖。
圖3示出了根據(jù)本發(fā)明的各方面，示出用于獲取下一可用組的進程的操作流程圖。
圖4示出了根據(jù)本發(fā)明的各方面，示出用于使用接收者和工作者線程的進程的操作流程圖。
圖5示出了根據(jù)本發(fā)明的各方面，示出用于使用消息處理工作者線程的進程的操作流程圖。
具體實施例方式
本發(fā)明針對一種用于可靠消息傳送的服務(wù)器排隊方法和系統(tǒng)。排隊服務(wù)器可以例如在其中一個子系統(tǒng)想要異步地執(zhí)行一個或多個已排序操作的情況下使用。消息被成組地發(fā)送給隊列，一組中可以含有一條或多條消息。在特定組中的消息以預(yù)定的順序處理。消息組可以被標(biāo)記為相關(guān)的，使得特定相關(guān)中的所有組可以按預(yù)定的順序處理。消息可以被存儲在SQL數(shù)據(jù)庫表中，直到對該消息的處理完成。消息系統(tǒng)的接收方可以跨多個機器和/或跨任何給定機器的可用資源而縮放。系統(tǒng)可以處理發(fā)送方的“災(zāi)難”情形(即，發(fā)送機器在發(fā)送組過程中崩潰)和接收方的“災(zāi)難”情形(即，電源故障引起至少一個接收機器上的重新引導(dǎo))。
說明性操作環(huán)境參考圖1，用于實現(xiàn)本發(fā)明的一個示例性系統(tǒng)包括諸如計算設(shè)備100的計算設(shè)備。計算設(shè)備100可以被配置為客戶機、服務(wù)器、移動設(shè)備或與基于網(wǎng)絡(luò)的協(xié)作系統(tǒng)中的數(shù)據(jù)交互的任何其它計算設(shè)備。在最基本配置中，計算設(shè)備100一般包括至少一個處理單元102和系統(tǒng)存儲器104。取決于計算設(shè)備的確切配置和類型，系統(tǒng)存儲器104可以是易失性的(諸如RAM)，非易失性的(諸如ROM、閃存等)或者兩者的某種組合。系統(tǒng)存儲器104一般包括操作系統(tǒng)105、一個或多個應(yīng)用程序106，且可以包括程序數(shù)據(jù)107。將在下文詳細描述的服務(wù)器排隊系統(tǒng)108一般在應(yīng)用程序106內(nèi)實現(xiàn)。
計算設(shè)備100可以具有額外的特征或功能。例如，計算設(shè)備100也可以包括諸如磁盤、光盤或磁帶等附加數(shù)據(jù)存儲設(shè)備(可移動和/或不可移動)。這樣的附加存儲在圖1中由可移動存儲109和不可移動存儲110示出。計算機存儲介質(zhì)可以包括以用于諸如計算機可讀指令、數(shù)據(jù)結(jié)構(gòu)、程序模塊或其它數(shù)據(jù)等信息的存儲的任何方法或技術(shù)實現(xiàn)的易失性和非易失性、可移動和不可移動介質(zhì)。系統(tǒng)存儲器104、可移動存儲109和不可移動存儲110都是計算機存儲介質(zhì)的示例。計算機存儲介質(zhì)包括，但不限于，RAM、ROM、EEPROM、閃存或其它存儲器技術(shù)、CD-ROM、數(shù)字多功能盤(DVD)或其它光盤存儲、磁帶盒、磁帶、磁盤存儲或其它磁性存儲設(shè)備、或能用于存儲所需信息且可以由計算設(shè)備100訪問的任何其它介質(zhì)。任何這樣的計算機存儲介質(zhì)可以是設(shè)備100的一部分。計算設(shè)備100也可以含有諸如鍵盤、鼠標(biāo)、筆、語音輸入設(shè)備、觸摸輸入設(shè)備等輸入設(shè)備。也可以包括諸如顯示器、揚聲器、打印機等輸出設(shè)備。
計算設(shè)備100也含有允許該設(shè)備諸如通過網(wǎng)絡(luò)與其它計算機設(shè)備118通信的通信連接116。網(wǎng)絡(luò)包括局域網(wǎng)和廣域網(wǎng)，以及其它大規(guī)模網(wǎng)絡(luò)，包括但不限于內(nèi)聯(lián)網(wǎng)和外聯(lián)網(wǎng)。通信連接116是通信介質(zhì)的一個示例。通信介質(zhì)通常具體化為諸如載波或其它傳輸機制等已調(diào)制數(shù)據(jù)信號中的計算機可讀指令、數(shù)據(jù)結(jié)構(gòu)、程序模塊或其它數(shù)據(jù)，且包含任何信息傳遞介質(zhì)。術(shù)語“已調(diào)制數(shù)據(jù)信號”指的是這樣一種信號，其一個或多個特征以在信號中編碼信息的方式被設(shè)定或更改。作為示例，而非限制，通信介質(zhì)包括有線介質(zhì)，諸如有線網(wǎng)絡(luò)或直接線連接，以及無線介質(zhì)，諸如聲學(xué)、RF、紅外線和其它無線介質(zhì)。在此處使用的術(shù)語計算機可讀介質(zhì)包括存儲介質(zhì)和通信介質(zhì)兩者。
排隊系統(tǒng)服務(wù)器圖2示出了根據(jù)本發(fā)明的各方面用于可靠消息傳送的排隊系統(tǒng)的框圖。示例性系統(tǒng)包括排隊服務(wù)器200、發(fā)送子系統(tǒng)客戶機250、252、254以及接收子系統(tǒng)客戶機260、262、264。(根據(jù)本發(fā)明的其它系統(tǒng)可以包括一個或多個發(fā)送子系統(tǒng)客戶機和/或一個或多個接收子系統(tǒng)客戶機)。服務(wù)器210包含一條或多條存儲的消息，這些消息被組織為消息組210。消息組210被存儲在消息隊列230(諸如SQL表)中，每一消息組與組隊列240(例如，也可以是SQL表)中一個條目相關(guān)聯(lián)。
發(fā)送消息發(fā)送子系統(tǒng)客戶機250、252、254可以調(diào)用Sender(發(fā)送者)對象，Sender在下文中使用API(應(yīng)用程序編程接口)來定義。例如，Sender對象可以被定義如下public Sender(Type queueAccessType)；public Sender(Type queueAccessType，string serverId)；public Guid BeginMessageGroup(int messageType，int priority，Guid correlationId)；
public void Send(object messageBody)；public void EndMessageGroup()；public void CancelMessageGroup()；首先，發(fā)送子系統(tǒng)客戶機創(chuàng)建Sender對象。構(gòu)造函數(shù)的參數(shù)一般是提供IQueueAccess接口(在下文中描述)的類的System.Type(系統(tǒng)類型)。替換構(gòu)造函數(shù)可以采用serverId(服務(wù)器ID)，serverID可以是標(biāo)識發(fā)送消息的服務(wù)器實例的任意串。如果項目服務(wù)器中僅有一個實例在給定的機器上運行，那么serverID可以是機器名。發(fā)送子系統(tǒng)客戶機一般不使用ServerID值。
一旦構(gòu)造了Sender對象，客戶機調(diào)用BeginMessageGroup()(開始消息組)。messageType(消息類型)參數(shù)是可以用于區(qū)分共享公共隊列的不同類型的消息的客戶機定義的值。例如，消息類型可以是Save(保存)、Publish(發(fā)布)和Report(報告)類型的消息。客戶機可以為這些消息類型定義某些任意的常量，并且該值可以用來分支到接收方上正確的消息處理代碼。
priority(優(yōu)先級)參數(shù)可以用于為消息組指定優(yōu)先級值。例如，值“1”可以是最高優(yōu)先級，而較大的數(shù)字可以是較低的優(yōu)先級。
correlationId(相關(guān)ID)參數(shù)一般是用于使分離的消息組相關(guān)的客戶機提供的GUID。例如，根據(jù)預(yù)定的順序(諸如以它們被接收的順序)處理來自特定用戶的消息(諸如來自時間表條目程序的消息)。每一時間表的提交可以作為一個消息組發(fā)送。排隊服務(wù)器200可以使用相關(guān)Id來確保即使存在處理時間表消息的多個線程，這些組中的每一個也是根據(jù)預(yù)定的順序(諸如按順序的次序)來處理的。在該時間表示例中，correlationId值可以是ResourceID(資源ID)。
BeginMessageGroup()的返回值是組的UID。UID可以用于涉及消息組狀態(tài)的查詢。
在調(diào)用BeginMessageGroup之后，發(fā)送子系統(tǒng)客戶機可以使用Send()來發(fā)送任何數(shù)量的消息。messageBody(消息正文)參數(shù)一般是表示正被發(fā)送的消息的任意對象。messageBody參數(shù)可以包括消息數(shù)據(jù)，以及甚至用于在接收方處理數(shù)據(jù)的方法。然而，該任意對象應(yīng)該能夠根據(jù)預(yù)定的順序來組織(諸如能夠被串行化)。排隊服務(wù)器200一般維護對象的串行化和反串行化，以存儲在隊列數(shù)據(jù)庫表中。隊列數(shù)據(jù)庫表可以被優(yōu)化，使得如果消息已經(jīng)是二進制格式的(例如，字節(jié)數(shù)組)，那么系統(tǒng)可以將數(shù)據(jù)“按原狀”寫入數(shù)據(jù)庫。
一旦發(fā)送了所有消息，客戶機可以調(diào)用EndMessageGroup()(結(jié)束消息組)。EndMessageGroup()關(guān)閉該組，并標(biāo)識該組為準(zhǔn)備好由接收代碼(在下文描述)來處理。
如果為某種原因而需要丟棄未完成的組，那么可以調(diào)用CancelMessageGroup()(取消消息組)。CancelMessageGroup()可以用來從隊列中移除在調(diào)用BeginMessageGroup()之后發(fā)送的所有消息。盡管在調(diào)用EndMessageGroup之后不能向消息組添加另外的消息，但是可以通過僅再次調(diào)用BeginMessageGroup來重復(fù)使用Sender對象本身。由Begin/EndMessageGroup對之間發(fā)送的所有消息定義的消息組一般不被處理，直到成功調(diào)用EndMessageGroup。倘若在發(fā)送消息時系統(tǒng)崩潰，將在隊列中留下未完成的組。該未完成的組可以由下文描述的清除進程來成功地移除。
接收消息接收者系統(tǒng)被設(shè)計成作為從隊列中檢索出消息并然后調(diào)用適當(dāng)?shù)奶幚泶a的線程來工作。作為結(jié)果，處理消息的代碼的開發(fā)者一般不需要使用由以下API定義的任何Receiver(接收者)對象。該API用來在項目服務(wù)器被啟動或由管理員手動激活時設(shè)置接收服務(wù)。Receiver對象可以定義如下public Receiver(Type queueAccessType，Type processMessageType，string serverId)；public void Start(bool asynchronous)；public void Stop()；public bool Done；public int ServiceLimit；public int ThreadSleepTime；Receiver對象是使用queueAccessType(隊列訪問類型)、processMessageType(處理消息類型)和serverID參數(shù)來構(gòu)造的。queueAccessType參數(shù)是支持IQueueAccess接口的對象的System.Type，processMessageType是支持IprocessMessage接口的對象的System.Type，而serverID一般是用于標(biāo)識接收者所屬的服務(wù)器實例的任意串。如果每個機器僅使用一個實例，那么serverID可以是機器名。(這些構(gòu)造函數(shù)參數(shù)的操作將在下文更完全地描述。)一旦構(gòu)造了Receiver對象，那么可以通過調(diào)用Start()(啟動)來啟動它。一般接收者應(yīng)該多半運行為線程，從而“asynchronous(異步)”參數(shù)應(yīng)該為“true(真)”，盡管它可以通過傳遞參數(shù)“false(假)”來同步運行?？梢詫崿F(xiàn)替換實施例，使得系統(tǒng)可以總是異步地運行。
不論同步還是異步啟動，接收服務(wù)可以通過調(diào)用Stop()(停止)來關(guān)閉。調(diào)用Stop指導(dǎo)接收服務(wù)關(guān)閉任何活動的工作者線程并然后退出。當(dāng)接收者線程以及與該接收者相關(guān)聯(lián)的所有工作者線程實際完成時，Done(完成)屬性可以被設(shè)為“true”。
ServiceLimit(服務(wù)限制)是可以用來指定接收者可以使用多少工作者線程的讀/寫屬性。ServiceLimit可以被設(shè)為默認(rèn)為值“1”。ServiceLimit一般可以在接收者線程運行時被更改。
ThreadSleepTime(線程睡眠時間)是指定接收者線程在每次向隊列輪詢新消息之間睡眠多長時間(例如，以毫秒為單位)的讀/寫屬性。ThreadSleepTime可以被設(shè)為默認(rèn)為值1000，當(dāng)使用毫秒為單位時即一秒鐘。
由于線程的考慮，發(fā)送者和接收者一般為queueAccess和processMessageType(而不是對象的實例本身)采用System.Type值。如果Sender和Receiver采納它們請求的對象的實例，那么這些對象必須是完全線程安全的，這意味著這些對象引用的任何其它對象也必須是線程安全的。為了避免這個問題，Sender和Receiver(使用傳遞的System.Type對象)為每一產(chǎn)生的線程例示指定對象的副本。從而，只有提供IqueueAccess或IprocessMessage的對象應(yīng)該必須是部分線程安全的(這意味著它們必須保護對靜態(tài)類成員的訪問，但不保護對任何實例對象的訪問)。
處理消息當(dāng)啟動接收服務(wù)時，它采用的參數(shù)之一是支持IProcessMessage接口的對象的System.Type，IProcessMessage接口定義如下public interface IProcessMessage{bool ProcessMessageCallback(Message msg，Group messageGroup，MessageContext mContext)；void StartMessageGroup(Group messageGroup，MessageContext mContext)；void EndMessageGroup(Group messageGroup)；}
每一Receiver對象的工作者線程例示了客戶機對象的一個實例。在讀取任何消息之前，調(diào)用IProcessMessage.StartMessageGroup()(處理消息的啟動消息組)。這向客戶機給出在處理消息組之前進行所需的初始化或其它處理的機會。下一步，對消息組中的每一消息，調(diào)用IProcessMessage.ProcessMessageCallback()(處理消息的處理消息返回)。
ProcessMessageCallback的返回值指定了該消息是否被成功處理。如果返回了值“true”，那么該消息可以出隊。返回值“false”指示該消息失敗，且排隊系統(tǒng)然后可以使用同一消息再次調(diào)用ProcessMessageCallback。
當(dāng)接收線程完成讀消息(或者通過接收最近的消息，或者由于異常而中止)時，可以調(diào)用IProcessMessage.EndMessageGroup()(處理消息的結(jié)束消息組)。這向客戶機給出進行可能所需的任何清除或結(jié)束的機會。
Message(消息)參數(shù)一般是消息本身。該對象含有以下屬性public int MessageId；public object MessageBody；MessageId給出了消息的ID，該ID在該組中唯一。組中第一條消息一般具有ID 1，而該組中第二條消息也具有ID 1，依此類推。MessageBody是最初通過Sender.Send()方法發(fā)送的對象。
Group(組)參數(shù)是一般含有關(guān)于消息所屬的組的元數(shù)據(jù)的對象。Group參數(shù)提供以下屬性public Guid GroupId；public Guid CorrelationId；public int MessageType；public int Priority；public int LastMessageId；GroupId(組ID)是該組的唯一標(biāo)識符。每一消息組具有唯一的GroupId。CorrelationId是消息的相關(guān)組的唯一標(biāo)識符。它對應(yīng)于當(dāng)調(diào)用Sender.BeginMessageGroup()(發(fā)送者的開始消息組)時傳遞給Sender.BeginMessageGroup()的參數(shù)。MessageType是指定消息類型的客戶機定義的枚舉類型。MessageType對應(yīng)于傳遞給Sender.BeginMessageGroup()的參數(shù)。Priority是組的優(yōu)先級。Priority對應(yīng)于傳遞給Sender.BeginMessageGroup()的參數(shù)。LastMessageId(最后消息ID)給出了組中最后一條消息的MessageId。從而當(dāng)遇到組中最后一條消息時msg.MessageId與messageGroup.LastMessageId相同。
MessageContext(消息上下文)參數(shù)可以包含關(guān)于消息的當(dāng)前處理狀態(tài)的額外信息。MessageContext參數(shù)可以定義如下public int RetryCount；public int GroupRetryCount；public int SleepBeforeRetry；RetryCount(重試計數(shù))是使用特定消息調(diào)用ProcessMessageCallback的次數(shù)。在第一次調(diào)用時，值一般為“1”。GroupRetryCount(組重試計數(shù))是特定組嘗試處理的次數(shù)。如果由于某種原因接收者工作者線程異常中止處理組，GroupRetryCount將重試該組，一般從第一條未處理的消息開始。SleepBeforeRetry(重試之前睡眠)是客戶機設(shè)定的參數(shù)，它告知工作者線程萬一消息的處理失敗，它在重試消息之前應(yīng)該睡眠多長時間。
低級隊列訪問排隊服務(wù)器200一般是隊列存儲“不可知的”(即，服務(wù)器不依賴于隊列存儲的內(nèi)部工作方式)。排隊服務(wù)器200通過支持IqueueAcess(隊列訪問)的對象進行隊列讀/寫/出隊訪問，IQueueAcess的System.Type被傳遞給Sender和Receiver對象的構(gòu)造函數(shù)。IQueueAcess可以定義如下public interface IQueueAccess{//獲取MSPSQS應(yīng)該處理的下一組void GetNextGroup(out Group msgGroup)；//從隊列中移除指定組void PopGroup(Group msgGroup)；//返回隊列中g(shù)roupId與msgGroup.GroupId相等的下一條消息void ReadMessage(Group msgGroup，out Message msg)；//由msgGroup和msg指定的消息出隊)
void PopMessage(Group msgGroup，Message msg)；//給定組元數(shù)據(jù)，打開消息組void openGroup(Group msgGroup)；//將由msgGroup和msg指定的消息入隊void SendMessage(Group msgGroup，Message msg)；//關(guān)閉消息組void CloseGroup(Group msgGroup)；//從消息隊列和組隊列中刪除給定組的所有記錄void FlushGroup(Group msgGroup)；//為由名為serverId的服務(wù)器實例鎖定發(fā)送的組解除鎖定)void UnlockServerGroups(string serverId)；}IQueueAcess的默認(rèn)實現(xiàn)可以使用兩個SQL表(例如，消息隊列230和組隊列240)來構(gòu)建。然而，由于排隊服務(wù)器200的剩余部分與隊列訪問的分離，整個系統(tǒng)可以被構(gòu)建在任一合適的存儲系統(tǒng)(諸如MSMQ或Yukon SSB)之上。
隊列存儲消息隊列230是持有從發(fā)送子系統(tǒng)客戶機發(fā)送的消息的實際消息正文數(shù)據(jù)的表。對每一Sender.Send()調(diào)用，一般向該表添加一行。盡管附圖將消息組示為群集在一起，但是實際上，來自多個組的消息可以是交錯的。消息隊列230一般用作數(shù)據(jù)容器。經(jīng)常在該表上執(zhí)行的操作是插入(Insert)新的消息、刪除(Delete)處理過的消息和選擇(Select)(讀)下一消息。該表中的記錄對應(yīng)于上述Message對象。
所示實施例示出了消息隊列230的一個表，但是替換實施例可以按所需的將該表分割成多個表。替換實施例僅需增強IQueueAccess.ReadMessage、IQueueAccess.PopMessage及IQueueAccess.SendMessage的實現(xiàn)來實現(xiàn)多個表。第二張表，即組隊列(240)用于選取下一組、處理和管理組及相關(guān)鎖、以及持有額外的元數(shù)據(jù)。該組中的記錄對應(yīng)于上述Group對象。在消息隊列230和組隊列(240)中的記錄之間經(jīng)常存在多對一的關(guān)系。消息隊列230一般含有對發(fā)送的每一個別消息的記錄。組隊列(240)一般對發(fā)送的每一消息組含有一條記錄。
向隊列添加新組當(dāng)發(fā)送子系統(tǒng)客戶機調(diào)用Sender.BeginMessageGroup()時，新的記錄被添加到該組隊列。該記錄被標(biāo)記為“鎖定發(fā)送”，來確保沒有接收者在該組完成之前會開始處理該組。當(dāng)客戶機調(diào)用了Sender.Send()任意次數(shù)后，可以調(diào)用Sender.EndMessageGroup()，它使用發(fā)送的最后一條消息的ID來更新組記錄，并將該組標(biāo)記為未鎖定。
獲取下一可用的組圖3示出了根據(jù)本發(fā)明的各方面，示出用于獲取下一可用組的進程的操作流程圖。一般而言，該進程尋找這樣的最高優(yōu)先級的組，其相關(guān)組(共享相關(guān)ID的那些組)沒有鎖定接收，其組沒有鎖定發(fā)送，且其相關(guān)不含有擁有更高優(yōu)先級的、在鎖定發(fā)送的隊列前端的組。該進程的邏輯可以依據(jù)排隊系統(tǒng)的使用方式而不同。
該進程在開始框300處開始，并前進至框310，在那里獲取其相關(guān)沒有鎖定接收的所有組的列表。該列表可以按照隊列中的位置和特定消息組的優(yōu)先級來排序。
在框320中，作出該列表是否非空的判斷，并且如果在列表中存在組，那么前進至框340。如果沒有組存在于列表中，該進程前進至框330并終止。
在框340處，獲取列表中的第一組，并在框350中評估該組來確定該框是否鎖定發(fā)送。如果該框被鎖定發(fā)送，那么該進程前進至框360，在那里從列表中移除共享鎖定組的相關(guān)ID的所有組。如果該框沒有被鎖定發(fā)送，那么該進程前進至框370，在那里該框被鎖定發(fā)送，并被返回至調(diào)用進程。
獲取下一可用組圖4示出了根據(jù)本發(fā)明的各方面，示出用于使用接收者和工作者線程的進程的操作流程圖。一般而言，接收者線程監(jiān)視隊列的可用組。在接收者線程開始輪詢隊列之前，它首先對按照被傳遞給構(gòu)造函數(shù)的serverId參數(shù)的服務(wù)器實例名稱鎖定發(fā)送的任何組解除鎖定。組被解除鎖定來允許清除/恢復(fù)進程。如果接收者線程異常停止(例如，由于機器重引導(dǎo))，當(dāng)前處理的組將以其它方式保持鎖定發(fā)送。從而，一旦服務(wù)器實例重新啟動，這些組就被解除鎖定。
之后，接收者線程向隊列輪詢可用組。當(dāng)有一組可用，且工作者線程的數(shù)量小于允許的最大值，那么接收者線程可以創(chuàng)建工作者線程來處理該組。如果工作者線程成功地處理該組，那么該組項從組隊列中移除。如果沒有成功處理，那么工作者線程重新啟動該組。
該進程在開始框400處開始，并前進至框405，在那里按照接受者所屬的且serverId相關(guān)聯(lián)的服務(wù)器實例對任何鎖定的線程解除鎖定接收。
在框410中，作出關(guān)于是否有可用的任何工作者線程的判斷。如果有任何可用的工作者線程，該進程前進至框415，在那里獲取下一個可用的組。如果沒有可用的工作者線程，那么該進程前進至框430，以檢查工作者線程的狀態(tài)之前進行等待。
在框420中，作出關(guān)于是否獲取下一可用組的判斷。如果獲取了下一可用組，那么該進程前進至框425，在那里啟動工作者線程。當(dāng)工作者線程被啟動之后，該進程返回至框410。如果沒有獲取下一可用組，那么該進程前進至框430，以在檢查工作者線程的狀態(tài)之前進行等待。
在框430中的等待之后，該進程前進至框435，在那里檢查工作者線程的狀態(tài)。在框440中，作出關(guān)于是否已經(jīng)處理了下一可用組中的所有消息的判斷。如果不是下一可用組中的所有消息尚未被處理，那么該進程前進至框445，在那里重新啟動工作者線程。如果下一可用組中的所有消息都已經(jīng)被處理，那么該進程前進至框450處，在那里從組隊列中移除該組。
在框445中重新啟動工作者線程或者框450中從組隊列中移除組之后，該進程前進至框455，在那里作出是否還存在要檢查的工作者線程的判斷。如果還存在要檢查的工作者線程，那么該進程返回至框435，在那里檢查工作者線程的狀態(tài)。如果不存在要檢查的工作者線程，那么該進程返回至框410，在那里再次作出關(guān)于是否有任何可用的工作者線程的判斷。
消息處理工作者線程圖5示出了根據(jù)本發(fā)明的各方面，示出用于使用消息處理工作者線程的進程的操作流程圖。一般而言，消息處理工作者線程循環(huán)操作。當(dāng)消息位于消息隊列上時，消息處理工作者線程讀消息并調(diào)用IProcessMessage.ProcessMessageCallback()。如果該函數(shù)返回“true”(指示消息的成功處理)，那么從隊列中移除該消息。否則重試。
該進程在開始框500處開始，并前進至框505，在那里讀消息。在框520中，作出關(guān)于是否成功獲取消息的判斷。如果成功地獲取了消息，那么該進程前進至框530。如果沒有成功獲取消息，那么該進程前進至框560并終止。
在框530中，處理成功獲取的消息，且該進程前進至框540，在那里作出關(guān)于是否成功地處理了該消息的判斷。如果消息沒有被成功地處理，那么該進程返回至框530，在那里再次處理獲取的消息。(可以在進程邏輯中放置檢查，以當(dāng)消息不能被正確地處理時異常中止處理。)如果消息被成功地處理了，那么該進程前進至框550，在那里該消息從隊列中“出隊”(即，被移除并調(diào)整相關(guān)聯(lián)的指針)。在消息被出隊之后，該進程返回至框510，在那里讀取另一條消息。該進程反復(fù)，直到不再獲取消息，在該情況中，然后處理在結(jié)束框560處終止。
從子系統(tǒng)故障中恢復(fù)解決了子系統(tǒng)故障的兩種情況其中接收機器被重新引導(dǎo)并返回在線的情形，以及其中接收機器崩潰并且在相當(dāng)?shù)囊欢螘r間內(nèi)沒有返回在線的情形。(相當(dāng)一段時間可以是可以向另一機器分配由崩潰的機器執(zhí)行的處理負(fù)載的長度的時間。)可通過當(dāng)組隊列240中的組條目被鎖定接收時，使用接收者的實例名稱(傳遞給構(gòu)造函數(shù)的serverId參數(shù))標(biāo)記它，來使得能夠從發(fā)送子系統(tǒng)崩潰中恢復(fù)。在重新引導(dǎo)的情形中，在接收服務(wù)重啟之后的第一個動作一般是對由該示例鎖定接收的任何組解除鎖定。然后可以挑選組并由任何可用的接收服務(wù)來處理該組。
當(dāng)接收子系統(tǒng)崩潰并且在相當(dāng)?shù)臅r間內(nèi)沒有返回時，那么(如同發(fā)送者崩潰的情況)一般存在失去時效的、被標(biāo)記為用于接收的一個或多個組。這種情況的清除是通過對這些組解除鎖定來實現(xiàn)的。一旦這些組被解除鎖定，可以挑選這些組來由消息處理線程繼續(xù)處理。
以上說明書、示例和數(shù)據(jù)提供了本發(fā)明的組成部分的制造和使用的完整描述。由于可以實現(xiàn)本發(fā)明的多個實施例，而不背離本發(fā)明的精神和范圍，因此本發(fā)明由此后所附的權(quán)利要求書定義。
權(quán)利要求
1.一種用于排隊消息的計算機實現(xiàn)的方法，包括在排隊系統(tǒng)中接收從發(fā)送者子系統(tǒng)發(fā)送的消息組，其中，每一消息組包含至少一條消息；使用所述排隊系統(tǒng)以預(yù)定的順序存儲所接收到的消息組；在所述排隊系統(tǒng)中接收每一消息組的相關(guān)標(biāo)識符，其中，所述相關(guān)標(biāo)識符用于關(guān)聯(lián)消息組；使用所述排隊系統(tǒng)存儲所接收的相關(guān)標(biāo)識符；以及根據(jù)所述預(yù)定的順序和所述相關(guān)標(biāo)識符來發(fā)送所存儲的消息組。
2.如權(quán)利要求1所述的計算機實現(xiàn)的方法，其特征在于，所述接收到的消息組被存儲在SQL表中。
3.如權(quán)利要求1所述的計算機實現(xiàn)的方法，其特征在于，所述存儲的消息組被發(fā)送給多臺機器。
4.如權(quán)利要求1所述的計算機實現(xiàn)的方法，其特征在于，一優(yōu)先級值與每一接收到的消息組相關(guān)聯(lián)。
5.如權(quán)利要求4所述的計算機實現(xiàn)的方法，其特征在于，所述消息組是根據(jù)所述相關(guān)聯(lián)的優(yōu)先級值來發(fā)送的。
6.如權(quán)利要求1所述的計算機實現(xiàn)的方法，其特征在于，一GUID被用作所屬相關(guān)標(biāo)識符。
7.如權(quán)利要求6所述的計算機實現(xiàn)的方法，其特征在于，所述GUID是客戶機提供的。
8.如權(quán)利要求1所述的計算機實現(xiàn)的方法，其特征在于，所述預(yù)定的順序是接收所述消息組的順序。
9.如權(quán)利要求1所述的計算機實現(xiàn)的方法，其特征在于，相關(guān)聯(lián)組的最后一個消息組是在發(fā)送所述相關(guān)聯(lián)組的任何存儲的消息組之前接收的。
10.如權(quán)利要求1所述的計算機實現(xiàn)的方法，其特征在于，還包括對由所述相關(guān)標(biāo)識符關(guān)聯(lián)的接收到的消息組鎖定發(fā)送，以及一旦接收到由所述相關(guān)標(biāo)識符關(guān)聯(lián)的最后一個消息組，就對所接收的消息組解除鎖定發(fā)送。
11.一種用于排隊消息的系統(tǒng)，包括用于在排隊系統(tǒng)中發(fā)送從發(fā)送者子系統(tǒng)發(fā)送的消息組的裝置，其中，每一消息組包含至少一條消息；用于使用所述排隊系統(tǒng)以預(yù)定的順序存儲所接收到的消息組的裝置；用于在所述排隊系統(tǒng)中接收每一消息組的相關(guān)標(biāo)識符的裝置，其中，所述相關(guān)標(biāo)識符用于關(guān)聯(lián)消息組；用于使用所述排隊系統(tǒng)存儲所接收的相關(guān)標(biāo)識符的裝置；以及用于根據(jù)所述預(yù)定的順序和所述相關(guān)標(biāo)識符來發(fā)送所存儲的消息組的裝置。
12.如權(quán)利要求11所述的系統(tǒng)，其特征在于，所述接收到的消息組被存儲在SQL表中。
13.如權(quán)利要求11所述的系統(tǒng)，其特征在于，所述存儲的消息組被發(fā)送給多臺機器。
14.如權(quán)利要求11所述的系統(tǒng)，其特征在于，一優(yōu)先級值與每一接收到的消息組相關(guān)聯(lián)。
15.如權(quán)利要求14所述的系統(tǒng)，其特征在于，所述消息組是根據(jù)所述相關(guān)聯(lián)的優(yōu)先級值來發(fā)送的。
16.一種含有用于管理消息的排隊系統(tǒng)的計算機可執(zhí)行指令的計算機可讀介質(zhì)，包括用于在排隊系統(tǒng)中接收從發(fā)送者子系統(tǒng)發(fā)送的消息組的指令，其中，每一消息組包含至少一條消息；用于使用所述排隊系統(tǒng)以預(yù)定的順序存儲所接收到的消息組的指令；用于在所述排隊系統(tǒng)中接收每一消息組的相關(guān)標(biāo)識符的指令，其中，所述相關(guān)標(biāo)識符用于關(guān)聯(lián)消息組；用于使用所述排隊系統(tǒng)存儲所接收的相關(guān)標(biāo)識符的指令；以及用于根據(jù)所述預(yù)定的順序和所述相關(guān)標(biāo)識符來發(fā)送所存儲的消息組的指令。
17.如權(quán)利要求16所述的計算機可讀介質(zhì)，其特征在于，一GUID被用作所述相關(guān)標(biāo)識符。
18.如權(quán)利要求16所述的計算機可讀介質(zhì)，其特征在于，所述預(yù)定的順序是接收所述消息組的順序。
19.如權(quán)利要求16所述的計算機可讀介質(zhì)，其特征在于，相關(guān)聯(lián)組的最后一個消息組是在發(fā)送所述相關(guān)聯(lián)組的任何存儲的消息組之前接收的。
20.如權(quán)利要求16所述的計算機可讀介質(zhì)，其特征在于，還包括對由所述相關(guān)標(biāo)識符關(guān)聯(lián)的接收到的消息組鎖定發(fā)送，以及一旦接收到由所述相關(guān)標(biāo)識符關(guān)聯(lián)的最后一個消息組，就對所接收的消息組解除鎖定發(fā)送。
全文摘要
一種用于可靠消息傳送的排隊服務(wù)器，其中一個子系統(tǒng)想要異步地執(zhí)行一個或多個已排序操作。消息被成組地發(fā)送給隊列，一組中可以含有一條或多條消息。在特定組中的消息以預(yù)定的順序處理。可任選地，消息組可以被標(biāo)記為相關(guān)的，使得特定相關(guān)中的所有組可以按預(yù)定的順序處理。消息可以被存儲在SQL數(shù)據(jù)庫表中，直到對該消息的處理完成。消息系統(tǒng)的接收方可以跨多個機器和/或跨任何給定機器的可用資源而縮放。系統(tǒng)可以處理發(fā)送方的“災(zāi)難”情形(即，發(fā)送機器在發(fā)送組過程中崩潰)和接收方的“災(zāi)難”情形(即，電源故障引起至少一個接收機器上的重新引導(dǎo))。
文檔編號H04L29/06GK1798111SQ20051012875
公開日2006年7月5日 申請日期2005年11月30日 優(yōu)先權(quán)日2004年12月30日
發(fā)明者C·-J·黃, J·M·科斯坦恩, P·嘎納帕斯拉杰, S·科雷普爾 申請人:微軟公司