一種消息處理系統的製作方法
2023-10-05 05:08:19 1
一種消息處理系統的製作方法
【專利摘要】本實用新型提供一種消息處理系統，所述系統包括客戶端，與所述客戶端連接的消息總線以及與所述消息總線連接的任務處理器；以及消息機制，用於將所述消息包緩存在本地伺服器，通過序列化的方式將所述消息包存儲於磁碟中，通過高效的讀寫機制訪問所述消息包。其中，所述消息總線包括監聽器、中轉站以及路由器。本技術方案提高了可靠性的同時提高了工作效率。
【專利說明】一種消息處理系統
【技術領域】
[0001]本實用新型涉及信息處理領域，尤其涉及一種消息處理系統。
【背景技術】
[0002]在醫療系統中，系統傳輸的信息可能是患者的診療數據，與患者的生命安全息息相關。如何在不穩定的環境下(如網絡中斷、網絡繁忙、伺服器宕機等)，提供穩定的消息服務，保證消息包和軟體系統的高可靠性，是一項具有挑戰性的工作。
[0003]傳統的消息處理模型分為發送方和接收方，發送方是消息的來源，接收方接收來自發送方的消息包，是一對一的關係。它們之間消息傳遞是通過網絡傳輸協議同步進行的，發送方發出數據後，等待接收方發迴響應以後才發下一個數據包，而網絡常常是不穩定的，在帶寬不夠、網絡繁忙、網絡中斷時，會發生發送方發送了消息包，而接收方並沒有收到消息包時，這時系統的發送方和接收方都會等待對方的結果，相互阻塞，只有接收到結果消息包後才往下繼續處理其他的消息。此外，消息的發送方和接收方由於各自的處理任務的能力不一致也會出現相互等待的情況。這樣，長時間的相互等待會影響系統性能，在大量消息並發阻塞時會導致系統崩潰。
[0004]一種改進方式是採用分布式消息處理模型，它通過採用消息隊列把消息緩存在內存中來保證本地消息不丟失，在網絡不穩定或者中斷時，如果出現消息包丟失，則不停地重發此消息包直到成功，來保證消息的可靠傳輸。但是，當整個分布式集群的緩存伺服器死機或者內存故障時，還是會出現消息的丟失，即使重啟機器也無法恢復原有的消息包，降低了系統的安全性。
實用新型內容
[0005]本實用新型解決的問題是提供方法一種消息處理系統，不僅具有高可靠性，還提高了工作效率。
[0006]為了解決上述問題，本實用新型提供了一種消息處理系統，包括括客戶端，與所述客戶端連接的消息總線以及與所述消息總線連接的任務處理器。
[0007]上述所述一種消息處理系統，其中，所述客戶端、消息總線以及任務處理器之間的傳遞為消息包。
[0008]上述所述一種消息處理系統，其中，所述消息包包括請求消息包和結果消息包。
[0009]上述所述一種消息處理系統，其中，所述請求消息包的格式包括業務狀態、狀態標識和業務數據。
[0010]上述所述一種消息處理系統，其中，所述結果消息包的格式包括業務編碼、狀態標識和結果信息。
[0011]上述所述一種消息處理系統，其中，所述系統具有消息機制，用於將所述消息包緩存在本地伺服器，通過序列化的方式將所述消息包存儲於磁碟中，通過高效的讀寫機制訪問所述消息包。[0012]上述所述一種消息處理系統，其中，所述消息總線包括監聽器、中轉站以及路由器。
[0013]上述所述一種消息處理系統，其中，所述中轉站與磁碟連接。
[0014]上述所述一種消息處理系統，其中，所述路由器通過心跳機制與所述任務處理器連接。
[0015]與現有技術相比，本實用新型把系統解耦成客戶端、消息總線和任務處理器三個獨立的模塊，每個模塊提供獨立的消息服務，當任意一個模塊中暫時，不會影響其它模塊提供消息服務，在保證消息處理系統可靠性的同時也提高了其工作效率；
[0016]進一步地，採用消息機制確保消息包在各個模塊的傳統中不會丟失，使得消息處理系統具有聞可罪性；
[0017]進一步地，通過把消息總線模塊接收的請求消息包實時寫入磁碟，當伺服器宕機現象恢復之後，可從磁碟文件中恢復消息包繼續工作，使得消息處理系統具有自我恢復能力。
【專利附圖】
【附圖說明】
[0018]圖1所示為本實用新型實施例一種消息處理系統的結構示意圖；
[0019]圖2所示為本實用新型實施例請求消息包的結構示意圖；
[0020]圖3所示為本實用新型實施例結果消息包的結構示意圖。
【具體實施方式】
[0021]在下面的描述中闡述了很多具體細節以便於充分理解本實用新型。但是本實用新型能夠以很多不同於在此描述的其它方式來實施，本領域技術人員可以在不違背本實用新型內涵的情況下做類似推廣，因此本實用新型不受下面公開的具體實施的限制。
[0022]其次，本實用新型利用示意圖進行詳細描述，在詳述本實用新型實施例時，為便於說明，所述示意圖只是實例，其在此不應限制本實用新型保護的範圍。
[0023]下面結合附圖和實施例對本實用新型一種消息處理系統進行詳細地說明。本實用新型實施例消息處理系統如圖1所示，所述消息處理系統包括客戶端1，與所述客戶端I連接的消息總線2以及與所述消息總線2連接的任務處理器3。其中，所述客戶端、消息總線以及任務處理器之間的傳遞為消息包，所述消息包包括請求消息包和結果消息包。具體地，在本實施例中，首先，用戶通過客戶端I提交所述請求消息包給消息總線2。其中，所述請求消息包的格式如圖2所示，包括頭信息和業務數據，頭信息包括業務名稱和狀態標識。業務名稱指的是請求需要的業務名稱，代理會根據業務名稱從路由表中查找相應的任務處理器來處理相應的業務需求；狀態標識有已發送和未發送，當把此消息成功發送給請求線程後，會改寫為已發送，否則標識成未發送；業務數據是用戶需要處理的業務數據，如查詢消息時需要的查詢條件。
[0024]此外，所述系統具有消息機制，用於將所述消息包緩存在本地伺服器，通過序列化的方式將所述消息包存儲於磁碟中，通過高效的讀寫機制訪問所述消息包。客戶端採用多線程先進先出的方式讀取消息隊列。具體地，客戶端使用消息隊列，把消息包緩存在本地，及時消息總線出現暫時不可達的情況(如網絡突然中斷、宕機等)，客戶端也能在消息總線回復正常後，繼續提交消息包，保證整個消息處理系統的高可用性。用戶通過客戶端將消息包寫入請求消息隊列，再通過請求線程將消息按照緩存順序逐個發給消息總線，如果收到消息總線返回的是發送成功應答，則對該消息包進行標識，不再發送；如果在指定時間內沒有應答到達(指定時間T= I秒)，則重新發送，如果多次重發之後，還是沒有應答，則對該消息包進行標識，並把失敗原因返回給用戶，用戶可選擇放棄發送該消息，也可以選擇繼續重發消息包。需要說明的是，在本實施例中，多次重發的次數為10次。
[0025]接著，消息總線2接收客戶端I發送的請求，指派任務請求給任務處理器3處理任務。所述消息總線包括監聽器21、中轉站22以及路由器23。為了保證在消息總線死機時不丟失數據，消息總線支持自動回復功能。消息總線中的中轉站將接收到的客戶端請求的消息包實時寫入磁碟文件4。如果消息總線宕機，當宕機現象恢復之後，消息總線可以從磁碟文件中重新獲得消息包，繼續為客戶端和任務處理器提供消息服務。具體地，在本實施例中，消息總線2中的監聽器21接收來自客戶端的請求消息包。監聽器獲得客戶端的請求消息後，首先查找監聽列表中是否含有客戶端地址，如果沒有，則把客戶端IP位址和埠號加入監聽列表中，監聽器會把此任務提交給中轉站22。中轉站22把監聽器21提交的請求消息包寫入磁碟文件中，解析請求消息包，並提交請求消息包給路由器23處理。具體地，中轉站通過先進先出的方式解析消息包獲得業務名稱，並把業務名稱發送給路由器。
[0026]路由器23匹配請求消息包的任務名稱(即服務名稱)和任務處理器，把請求消息包發送給相應的任務處理器3，並異步等待接收任務處理器返回的結果消息包。路由器中存儲了所有的任務處理器的服務地址表，路由器通過心跳機制與任務處理器保持聯繫，當路由器超過一定時間不能接收到來自任務處理器的心跳消息包，則認定此任務處理器失效，更新路由列表把此服務設置為失效狀態。路由器接收來自中轉站的服務請求，根據具體的業務類型在服務映射表中查找任務處理器，當查找到此任務處理器後，路由器會把消息包轉發給任務處理器。需要說明的是，服務名稱需在路由器中註冊。
[0027]接著，任務處理器3接收來自路由器的請求消息包，進行業務邏輯的處理，完成後把結果消息包返回給路由器。所述結果消息包的格式如圖3所示，包含頭信息和結果信息，頭信息包括業務編碼和狀態標識。業務編碼對客戶端無實際的意義，是消息總線統一分配的消息包標識編碼，目的是跟蹤消息包，方便調試；狀態標識有「成功」、「失敗」以及「異常」，「成功」表示任務處理器已經成功處理此消息，「失敗」表示處理此消息失敗，「異常」表示消息包處理遇到問題，如查詢條件不符合規範；結果信息中包含了任務處理器處理此請求後的結果信息，如查詢消息時查詢到的信息列表。
[0028]任務處理器定時發送心跳包給路由器，告知自己在線，並實時監聽並接收到來自路由器發送的請求消息包，並將其保存在請求消息隊列中。任務處理器後臺的多線程從隊列中讀取請求消息包，對其進行處理，處理完成後生成結果消息包，並保存到結果消息隊列中。任務處理器把結果消息隊列中的結果消息包異步多線程發送給路由器。
[0029]路由器通過異步回調的方式獲得任務處理器返回的結果，並把結果返回給中轉站，中轉站通過監聽器把結果消息包返回給客戶端，如果發送失敗，則會不停地重試發送，直至成功；當查找不到相應的任務處理器，路由器會告知中轉站不能查找到相應的任務處理器，中轉站同時會把錯誤信息通過監聽器發送給客戶端。需要說明的是，當中轉站成功接收到路由器返回的結果，且收到客戶端發送的任務處理完成的確認消息包，才能把對應的請求消息包從磁碟文件中刪除，否則該請求消息包會一直保留在磁碟文件中。
[0030]當客戶端接收到結果信息包後，把結果信息包放入結果消息隊列中，用戶可從此隊列中獲取返回的結果。需要說明的是，客戶端需要綁定消息總線地址，並通過後臺輪詢線程異步取得返回的結果。客戶端發送完本地隊列中所有的請求包後，不需要同步等待消息總線處理完的返回結果，而是利用後臺輪詢線程異步接收來自消息總線的返回結果信息包。從而在保證系統高可靠性的同時也提高了工作效率。
[0031]本實用新型雖然已以較佳實施例公開如上，但其並不是用來限定本實用新型，任何本領域技術人員在不脫離本實用新型的精神和範圍內，都可以利用上述揭示的方法和技術內容對本實用新型技術方案做出可能的變動和修改，因此，凡是未脫離本實用新型技術方案的內容，依據本實用新型的技術實質對以上實施例所作的任何簡單修改、等同變化及修飾，均屬於本實用新型技術方案的保護範圍。
【權利要求】
1.一種消息處理系統，其特徵在於，包括客戶端；與所述客戶端連接的消息總線，通過所述消息總線中的監聽器接收所述客戶端的消息包以及與所述消息總線連接的任務處理器，通過所述消息總線中的路由器將所述消息包傳遞給所述任務處理器。
2.如權利要求1所述一種消息處理系統，其特徵在於，所述客戶端、消息總線以及任務處理器之間的傳遞為消息包。
3.如權利要求2所述一種消息處理系統，其特徵在於，所述消息包包括請求消息包和結果消息包。
4.如權利要求3所述一種消息處理系統，其特徵在於，所述請求消息包的格式包括業務狀態、狀態標識和業務數據。
5.如權利要求3所述一種消息處理系統，其特徵在於，所述結果消息包的格式包括業務編碼、狀態標識和結果信息。
6.如權利要求1所述一種消息處理系統，其特徵在於，所述系統具有消息機制，用於將所述消息包緩存在本地伺服器，通過序列化的方式將所述消息包存儲於磁碟中，通過讀寫機制訪問所述消息包。
7.如權利要求1所述一種消息處理系統，其特徵在於，所述消息總線包括監聽器、中轉站以及路由器。
8.如權利要求7所述一種消息處理系統，其特徵在於，所述中轉站與磁碟連接。
9.如權利要求7所述一種消息處理系統，其特徵在於，所述路由器通過心跳機制與所述任務處理器連接。
【文檔編號】H04L12/58GK203574673SQ201320419457
【公開日】2014年4月30日 申請日期:2013年7月15日 優先權日:2013年7月15日
【發明者】陳國富, 陳文娟 申請人:上海聯影醫療科技有限公司