專利名稱：計算機軟件系統(tǒng)中基于云計算的實時事件處理系統(tǒng)及方法
技術(shù)領(lǐng)域：
本發(fā)明涉及計算機軟件應(yīng)用技術(shù)領(lǐng)域，特別涉及計算機軟件系統(tǒng)中的事件處理技術(shù)領(lǐng)域，具體是指一種計算機軟件系統(tǒng)中基于云計算的實時事件處理系統(tǒng)及方法。
背景技術(shù)：
當(dāng)今是一個IT事件爆發(fā)的時代，每一個應(yīng)用軟件系統(tǒng)都在不停地產(chǎn)生著大量的事件。云計算環(huán)境下的海量事件的捕獲、實時處理、準(zhǔn)實時分析已經(jīng)成為當(dāng)前乃至未來若干年的網(wǎng)絡(luò)信息技術(shù)的一個重要領(lǐng)域。當(dāng)各個應(yīng)用系統(tǒng)均以主動推送的方式發(fā)送實時事件時，要做到高吞吐量下的低延遲處理就成為一個棘手的技術(shù)問題。業(yè)界在解決大數(shù)據(jù)量實時處理的問題時，呈現(xiàn)著百花齊放的狀況。例如有的方案把事件統(tǒng)一發(fā)送到一個消息中間件集群中，以此為中介再發(fā)送到訂閱消息的客戶端；有的方案則利用分布式計算框架把事件分發(fā)到不同的機器上處理；有的則強調(diào)流計算的概念， 把事件送入數(shù)據(jù)流并根據(jù)預(yù)先配置好的模式或規(guī)則進行不停的匹配。以上技術(shù)方案在事件處理邏輯復(fù)雜冗長，特別在需要與大量歷史數(shù)據(jù)關(guān)聯(lián)處理的情況下顯得能力不足。例如，在BAM (Business Activity Monitoring,業(yè)務(wù)活動監(jiān)控)等實時監(jiān)控與準(zhǔn)實時分析類的系統(tǒng)中，當(dāng)我們接收到大量的實時業(yè)務(wù)數(shù)據(jù)時，每一條都要與過去一年甚至更長周期中的數(shù)據(jù)做關(guān)聯(lián)計算；每一條都會經(jīng)過一個復(fù)雜冗長的處理流程，如數(shù)據(jù)串聯(lián)、還原為流程數(shù)據(jù)、對流程數(shù)據(jù)做違規(guī)判斷、進入數(shù)據(jù)倉庫或KPI (KeyPerformance Indication)指標(biāo)引擎。在這種復(fù)雜的應(yīng)用場景下，很多通用的技術(shù)方案會顯得力不從心，分布式計算技術(shù)能帶來更多的CPU和內(nèi)存，但要與海量歷史數(shù)據(jù)做串聯(lián)操作，瓶頸卻在關(guān)系數(shù)據(jù)庫；消息中間件集群雖然能快速的存儲和轉(zhuǎn)發(fā)事件，但一連串冗長的處理將全部拋給一個客戶端機器，每一個處理環(huán)節(jié)無法根據(jù)其特點做單獨的性能設(shè)計；流計算技術(shù)也無法解決時間窗口過長帶來的存儲與延遲的問題。SEDA (Staged Event-Driven Architecture,分階段事件驅(qū)動架構(gòu))可以把一個請求處理過程分成幾個Stage (階段)，不同資源消耗的Stage使用不同數(shù)量的線程來處理、使用不同數(shù)量不同配置的機器來承載，支持同一個Stage的并行處理，支持多個Stage間的串行處理，Stage間使用事件驅(qū)動的異步通信模式，其設(shè)計目標(biāo)就是支持大規(guī)模并發(fā)處理、簡化系統(tǒng)開發(fā)、支持資源管理。內(nèi)存數(shù)據(jù)庫也稱為NoSQL數(shù)據(jù)庫或非關(guān)系型數(shù)據(jù)庫，傳統(tǒng)的緩存技術(shù)在未命中的時候仍然會查詢關(guān)系數(shù)據(jù)庫，這在頻繁更新的場景下并不能顯著提升性能，反而使處理邏輯更加復(fù)雜。內(nèi)存數(shù)據(jù)庫則可以在一些場景下完全取代關(guān)系數(shù)據(jù)庫，在大數(shù)據(jù)量的時代背景下，在高吞吐量低延遲的實時需求下，以關(guān)系數(shù)據(jù)庫為核心的架構(gòu)正在向著以內(nèi)存技術(shù)為核心的架構(gòu)發(fā)展，沒有內(nèi)存技術(shù)的業(yè)務(wù)邏輯看似正確，然而卻已經(jīng)難堪重負(fù)
發(fā)明內(nèi)容
本發(fā)明的目的是克服了上述現(xiàn)有技術(shù)中的缺點，提供一種將SEDA與內(nèi)存數(shù)據(jù)庫相融合，可以應(yīng)對實時監(jiān)控或準(zhǔn)實時分析類系統(tǒng)中的高并發(fā)請求與大數(shù)據(jù)量處理，實現(xiàn)復(fù)雜的業(yè)務(wù)邏輯處理流程，滿足高吞吐量、低延遲的性能需求，并且有效控制系統(tǒng)資源、提高運行過程的可靠性，達到性能可以分段設(shè)計，在一定范圍內(nèi)自由伸縮的目標(biāo)，適合應(yīng)用于性能要求苛刻的業(yè)務(wù)活動監(jiān)控或準(zhǔn)實時分析類系統(tǒng)中，且系統(tǒng)結(jié)構(gòu)簡單，成本低廉的計算機軟件系統(tǒng)中基于云計算實現(xiàn)實時事件處理的系統(tǒng)及方法。為了實現(xiàn)上述的目的，本發(fā)明的計算機軟件系統(tǒng)中基于云計算實現(xiàn)實時事件處理的系統(tǒng)具有如下構(gòu)成該系統(tǒng)包括SEDA分布式消息框架和Redis (REmote Dictionary Server,遠程目錄服務(wù)器)核心內(nèi)存處理框架。 其中，SEDA分布式消息框架包括控制平臺、配置數(shù)據(jù)庫和服務(wù)容器，所述的控制平臺和服務(wù)容器均連接所述的配置數(shù)據(jù)庫，所述的服務(wù)容器包括容器基礎(chǔ)模塊、消息處理服務(wù)模塊、路由模塊、服務(wù)解析模塊和返回監(jiān)聽模塊；所述的消息處理服務(wù)模塊包括至少一個業(yè)務(wù)邏輯單元和六個消息通道，所述的各業(yè)務(wù)邏輯單元對應(yīng)不同的服務(wù)應(yīng)用業(yè)務(wù)，所述的業(yè)務(wù)邏輯單元通過所述的消息通道連接所述的Redis核心內(nèi)存處理框架，所述的六個消息通道為請求接出通道、請求接入通道、返回接出通道、返回接入通道、錯誤接出通道和錯誤接入通道。而Redis核心內(nèi)存處理框架包括多個Redis服務(wù)器、關(guān)系數(shù)據(jù)庫、模板工具模塊、連接池服務(wù)模塊、數(shù)據(jù)分片服務(wù)模塊、主從熱備模塊、數(shù)據(jù)同步服務(wù)模塊和在線擴容模塊。其中，模板工具模塊對外提供的接口，連接所述的SEDA分布式消息框架；連接池服務(wù)模塊對應(yīng)每一個所述的Redis服務(wù)器提供一個連接池；數(shù)據(jù)分片服務(wù)模塊將數(shù)據(jù)分布存儲于不同的Redis服務(wù)器中；主從熱備模塊為每一個所述的Redis服務(wù)器配置一臺從服務(wù)器，Redis核心內(nèi)存處理框架自動檢測主從的狀態(tài)并在主機宕機時切換到對應(yīng)的從服務(wù)器；數(shù)據(jù)同步服務(wù)模塊維護一個寫緩沖隊列，緩沖隊列到達一定數(shù)量后將寫入所述的關(guān)系數(shù)據(jù)庫；在線擴容模塊用以支持在不間斷運行的狀況下對所述的Redis核心內(nèi)存處理框架進行擴容。該計算機軟件系統(tǒng)中基于云計算實現(xiàn)實時事件處理的系統(tǒng)中，所述的容器基礎(chǔ)模塊包括資源管理單元、超時管理單元、心跳服務(wù)單元、集群通知單元、遠程通信單元、負(fù)載均衡單元、通道管理單元和消息創(chuàng)建工具單元，所述的資源管理單元、超時管理單元、心跳服務(wù)單元、集群通知單元、遠程通信單元、負(fù)載均衡單元、通道管理單元和消息創(chuàng)建工具單元均連接所述的服務(wù)容器。本發(fā)明還提供一種利用所述的系統(tǒng)進行基于云計算實現(xiàn)實時事件處理的方法，該方法包括接收消息操作和發(fā)送消息操作。所述的接收消息操作包括以下步驟(al)所述的SEDA分布式消息框架進行啟動初始化；(a2)所述的Redis核心內(nèi)存處理框架進行啟動初始化；(a3)所述的SEDA分布式消息框架接收到http請求包，并將該http請求包反序列化為消息；(a4)系統(tǒng)調(diào)用所述的Redis核心內(nèi)存處理框架的模板工具模塊將消息持久化到Redis服務(wù)器；(a5)系統(tǒng)根據(jù)所述消息的消息頭判斷消息為請求消息還是返回消息；(a6)如果是請求消息，則將消息發(fā)送到所述的請求接入通道，并尋找對應(yīng)的業(yè)務(wù)邏輯單元進行處理；(a7)如果是返回消息，則將消息發(fā)送到所 述的返回接入通道，并尋找對應(yīng)的業(yè)務(wù)邏輯單元進行處理；(a8)所述的請求接入通道調(diào)用所述的連接池服務(wù)模塊進行消息處理；(a9)所述的消息的業(yè)務(wù)邏輯代碼通過所述的Redis核心內(nèi)存處理框架來實現(xiàn)，并與所述的關(guān)系數(shù)據(jù)庫解耦合；(alO)所述的消息的業(yè)務(wù)邏輯構(gòu)建返回消息并調(diào)用服務(wù)容器進行發(fā)送。所述的發(fā)送消息操作包括以下步驟(bl)所述的SEDA分布式消息框架進行啟動初始化；(b2)所述的Redis核心內(nèi)存處理框架進行啟動初始化；(b3)業(yè)務(wù)代碼通過調(diào)用容器基礎(chǔ)模塊的消息創(chuàng)建工具單元，將業(yè)務(wù)對象包裝為消息，并調(diào)用服務(wù)容器分發(fā)接口 ；(b4)如果是雙向消息，業(yè)務(wù)代碼調(diào)用所述的返回監(jiān)聽模塊和容器基礎(chǔ)模塊的超時管理單元進行監(jiān)聽；(b5)系統(tǒng)根據(jù)所述消息的消息頭確定對應(yīng)的接出通道；(b6)所述的接出通道根據(jù)所述的消息頭確定對應(yīng)的路由信息為本地路由或遠程路由；(b7)如果是本地路由，則直接投遞到本地的消息接入通道；(b8)如果是遠程路由，則序列化消息并通過http遠程工具發(fā)送。該進行基于云計算實現(xiàn)實時事件處理的方法中，所述的SEDA分布式消息框架進行啟動初始化，具體包括以下步驟(1-1)所述的SEDA分布式消息框架根據(jù)本地ip地址與管理端口，從所述的配置數(shù)據(jù)庫中查詢屬于本節(jié)點的配置信息；(1-2)所述的SEDA分布式消息框架將本節(jié)點的ip地址、管理端口以及其它配置信息拼成urI,并啟動Jetty服務(wù)器；(1-3)所述的SEDA分布式消息框架利用屬于本節(jié)點的業(yè)務(wù)邏輯全路徑與服務(wù)類型的對應(yīng)信息，初始化所述的服務(wù)解析模塊；(1-4)所述的SEDA分布式消息框架利用所述的配置數(shù)據(jù)庫中所有服務(wù)類型與url的對應(yīng)信息，初始化所述的路由模塊；(1-5)所述的SEDA分布式消息框架利用所述的本節(jié)點的線程池配置信息初始化所述的消息通道；(1-6)所述的SEDA分布式消息框架根據(jù)所述的配置數(shù)據(jù)庫中所有集群節(jié)點的信息，初始化心跳服務(wù)。該進行基于云計算實現(xiàn)實時事件處理的方法中，所述的Redis核心內(nèi)存處理框架進行啟動初始化，具體包括以下步驟(2-1)所述的Redis核心內(nèi)存處理框架根據(jù)配置數(shù)據(jù)庫中的Redis主機、從機地址信息以及連接池的連接數(shù)參數(shù)、等待時間參數(shù)，初始化所述的連接池服務(wù)模塊；(2-2)所述的Redis核心內(nèi)存處理框架根據(jù)配置數(shù)據(jù)庫中的數(shù)據(jù)集名稱與Redis服務(wù)器id的對應(yīng)信息，初始化所述的數(shù)據(jù)分片服務(wù)模塊；(2-3)所述的Redis核心內(nèi)存處理框架根據(jù)配置數(shù)據(jù)庫中的所有客戶端地址，初始化所述的主從熱備模塊；(2-4)所述的Redis核心內(nèi)存處理框架根據(jù)配置數(shù)據(jù)庫中的關(guān)系數(shù)據(jù)庫連接信息以及同步任務(wù)數(shù)量參數(shù)，初始化所述的數(shù)據(jù)同步服務(wù)模塊。該進行基于云計算實現(xiàn)實時事件處理的方法中，所述的步驟(a3)具體包括以下步驟(a3_l)所述的SEDA分布式消息框架的Jetty服務(wù)器從HttpServletRequest請求信息中提取出InputStream輸入流,并且轉(zhuǎn)換為字節(jié)數(shù)組；(a3-2)所述的Jetty服務(wù)器讀取所述的字節(jié)數(shù)組前4位并轉(zhuǎn)換為10進制的數(shù)字N；(a3-3)所述的Jetty服務(wù)器讀取所述的字節(jié)數(shù)組的第5位到第N位，并轉(zhuǎn)換為字符串；(a3_4)所述的Jetty服務(wù)器以該字符串作為類的全路徑，反射得到序列化器類的實例；(a3-5)所述的Jetty服務(wù)器調(diào)用該類的反序列化方法處理后續(xù)所有字節(jié)得到消
肩、O該進行基于云計算實現(xiàn)實時事件處理的方法中，所述的步驟(a4)具體包括以下步驟(a4_l)系統(tǒng)根據(jù)數(shù)據(jù)集名稱參數(shù)調(diào)用數(shù)據(jù)分片服務(wù)接口，獲得對應(yīng)的Redis服務(wù)器 id 與 dbid ；(a4_2)系統(tǒng)調(diào)用連接池服務(wù)接口獲得Redis的客戶端連接Jedis (Java內(nèi)存數(shù)據(jù)庫連接工具包)，并判斷連接是否成功；(a4_3)如果獲取連接失敗則調(diào)用關(guān)系數(shù)據(jù)庫的回調(diào)任務(wù)，將數(shù)據(jù)更新邏輯寫入所述的關(guān)系數(shù)據(jù)庫中；(a4_4)如果獲取連接成功則調(diào)用Redis命令select dbid選擇數(shù)據(jù)庫標(biāo)識dbid ；(a4-5)系統(tǒng)調(diào)用Redis的回調(diào)任務(wù)，將數(shù)據(jù)更新操作寫入內(nèi)存數(shù)據(jù)庫Redis中；(a4-6)系統(tǒng)調(diào)用連接池服務(wù)接口將客戶端連接Jedis歸還至連接池；(a4_7)系統(tǒng)調(diào)用數(shù)據(jù)同步服務(wù)接口將關(guān)系數(shù)據(jù)庫回調(diào)任務(wù)存放在內(nèi)存隊列中，達到閾值時，將批量隊列更新到關(guān)系數(shù)據(jù)庫。該進行基于云計算實現(xiàn)實時事件處理的方法中，步驟(a6)中所述的將消息發(fā)送到所述的請求接入通道，并尋找對應(yīng)的業(yè)務(wù)邏輯單元進行處理，具體包括以下步驟(a6_l)所述的SEDA分布式消息框架根據(jù)消息頭中的服務(wù)類型和服務(wù)碼，從本地節(jié)點的各業(yè)務(wù)邏輯單元中查找對應(yīng)的業(yè)務(wù)邏輯；(a6-2)如果找到一條業(yè)務(wù)邏輯，則將消息發(fā)送到連接池服務(wù)模塊處理；(a6-3)如果找到多條業(yè)務(wù)邏輯，則將消息多次發(fā)送到連接池服務(wù)模塊并行處理。該進行基于云計算實現(xiàn)實時事件處理的方法中，所述的步驟(b4)具體包括以下步驟(b4_l)所述的雙向消息的業(yè)務(wù)代碼實現(xiàn)返回監(jiān)聽的回調(diào)方法，并構(gòu)建出上下文；(b4_2)所述的雙向消息的業(yè)務(wù)代碼調(diào)用服務(wù)容器接口，將返回監(jiān)聽注冊到所述的返回監(jiān)聽模塊，供返回接入通道使用；(b4_3)所述的雙向消息的業(yè)務(wù)代碼實現(xiàn)超時監(jiān)聽接口，并調(diào)用服務(wù)容器接口注冊到容器基礎(chǔ)模塊的超時管理單元；(b4-4)所述的超時管理單元將超時監(jiān)聽按照時間長度取模，并分別放在分別由5個線程管理的5個等級的隊列中，每個線程將定時查看對應(yīng)等級的隊列，如果規(guī)定時間內(nèi)沒有收到返回消息就會執(zhí)行超時監(jiān)聽中的邏輯，收到返回消息則從隊列中刪除超時監(jiān)聽對
象。 該進行基于云計算實現(xiàn)實時事件處理的方法中，所述的步驟(b6)具體包括以下步驟(b6_l)所述的接出通道根據(jù)消息頭判斷該消息是請求消息還是返回消息；(b6-2)當(dāng)消息是請求消息時，所述的接出通道調(diào)用路由模塊的請求路由查詢接Π ；(b6-3)當(dāng)消息是返回消息時，所述的接出通道調(diào)用路由模塊的返回路由查詢接Π ；( b6-4 )所述的請求路由查詢接口將根據(jù)其從配置數(shù)據(jù)庫中獲取的集群全局配置信息以及消息頭中的服務(wù)類型查找到處理該消息的所有節(jié)點；(b6_5)當(dāng)多個節(jié)點的業(yè)務(wù)邏輯相同時，所述的請求路由利用負(fù)載均衡算法得出唯一節(jié)點；(b6-6)當(dāng)多個節(jié)點的業(yè)務(wù)邏輯不同時，所述的請求路由同時將消息發(fā)送到多個節(jié)占.(b6_7)所述的返回路由查詢接口將根據(jù)消息頭中的返回地址直接定位到目標(biāo)節(jié)點。該進行基于云計算實現(xiàn)實時事件處理的方法還包括心跳檢測操作，所述的心跳檢測操作包括以下步驟(Cl)所述的容器基礎(chǔ)模塊的心跳服務(wù)中心維護一個心跳線程；(c2)每一個所述的服務(wù)容器均通過所述的控制臺變更通知維護一個列表，所述列表中的每一個對象都代表著一個其它的服務(wù)容器，每個對象內(nèi)部都維護一個任務(wù)隊列；(c2)所述的心跳線程到達設(shè)定的心跳間隔時間后，就在所述列表中的每個對象的任務(wù)隊列中添加一個任務(wù)；(c3)所述對象收到任務(wù)后，向?qū)?yīng)的服務(wù)容器發(fā)出socket心跳消息；(c4)當(dāng)socket沒有正常返回時，拋出異常，說明本次心跳失敗，并將對應(yīng)的服務(wù)容器狀態(tài)設(shè)置為非活動；(c5)當(dāng)再次向狀態(tài)為非活動的服務(wù)容器發(fā)出socket心跳消息，socket正常返回時，將對應(yīng)的服務(wù)容器狀態(tài)設(shè)置為活動；(c6)所述的路由模塊丟棄發(fā)向非活動的服務(wù)容器的消息，并返回異常。采用了該發(fā)明的計算機軟件系統(tǒng)中基于云計算實現(xiàn)實時事件處理的系統(tǒng)，其包括SEDA分布式消息框架和Redis核心內(nèi)存處理框架。利用該系統(tǒng)實現(xiàn)實時事件處理的方法包括接收消息操作和發(fā)送消息操作。該方法將分布式消息框架和Redis核心內(nèi)存處理框架融合，從而可以有效地應(yīng)對實時監(jiān)控或準(zhǔn)實時分析類系統(tǒng)中的高并發(fā)請求與大數(shù)據(jù)量處理需求，實現(xiàn)復(fù)雜的業(yè)務(wù)邏輯處理流程，滿足高吞吐量、低延遲的性能要求，并且有效控制系統(tǒng)資源、提高運行過程的可靠性，達到性能可以分段設(shè)計，在一定范圍內(nèi)自由伸縮的目標(biāo)，適合應(yīng)用于性能要求苛刻的業(yè)務(wù)活動監(jiān)控或準(zhǔn)實時分析類系統(tǒng)中，且本發(fā)明的計算機軟件系統(tǒng)中基于云計算實現(xiàn)實時事件處理的系統(tǒng)及方法，其系統(tǒng)結(jié)構(gòu)簡單，應(yīng)用成本低廉。


圖1為本發(fā)明的計算機軟件系統(tǒng)中基于云計算實現(xiàn)實時事件處理的系統(tǒng)結(jié)構(gòu)示意圖。圖2為本發(fā)明的系統(tǒng)中的Redis核心內(nèi)存處理框架示意圖。圖3為本發(fā)明的系統(tǒng)中的Redis核心內(nèi)存處理框架中的主要模塊間的依賴關(guān)系示意圖。圖4為本發(fā)明的分布式消息框架的接收消息流程示意圖。圖5為本發(fā)明的分布式消息框架的發(fā)送消息流程示意圖。圖6為本發(fā)明的Redis核心內(nèi)存處理框架的模板方法流程示意圖。圖7為本發(fā)明的Redis核心內(nèi)存處理框架的連接池服務(wù)流程圖。圖8為本發(fā)明的基于SEDA的分布式消息框架的消息示意圖。圖9為本發(fā)明的基于SEDA的分布式消息框架的路由類圖。圖10為本發(fā)明的基于SEDA的分布式消息框架的返回監(jiān)聽與超時管理類圖。圖11為本發(fā)明的基于SEDA的分布式消息框架的心跳服務(wù)類圖。
具體實施例方式為了能夠更清楚地理解本發(fā)明的技術(shù)頁面，特舉以下實施例詳細說明。請參閱圖I所示，為本發(fā)明的計算機軟件系統(tǒng)中基于云計算實現(xiàn)實時事件處理的系統(tǒng)。在一種實施方式中，該系統(tǒng)包括SEDA分布式消息框架和Redis核心內(nèi)存處理框架。其中，SEDA分布式消息框架包括控制平臺、配置數(shù)據(jù)庫和服務(wù)容器，所述的控制平臺和服務(wù)容器均連接所述的配置數(shù)據(jù)庫，所述的服務(wù)容器包括容器基礎(chǔ)模塊、消息處理服務(wù)模塊、路由模塊、服務(wù)解析模塊和返回監(jiān)聽模塊；所述的消息處理服務(wù)模塊包括至少一個業(yè)務(wù)邏輯單元和六個消息通道，所述的各業(yè)務(wù)邏輯單元對應(yīng)不同的服務(wù)應(yīng)用業(yè)務(wù)，所述的業(yè)務(wù)邏輯單元通過所述的消息通道連接所述的Redis核心內(nèi)存處理框架，所述的六個消息通道為請求接出通道、請求接入通道、返回接出通道、返回接入通道、錯誤接出通道和錯誤接入通道。所述的容器基礎(chǔ)模塊包括資源管理單元、超時管理單元、心跳服務(wù)單元、集群通知單元、遠程通信單元、負(fù)載均衡單元、通道管理單元和消息創(chuàng)建工具單元，所述的資源管理單元、超時管理單元、心跳服務(wù)單元、集群通知單元、遠程通信單元、負(fù)載均衡單元、通道管理單元和消息創(chuàng)建工具單元均連接所述的服務(wù)容器。
如圖2所示，所述的Redis核心內(nèi)存處理框架包括多個Redis服務(wù)器、關(guān)系數(shù)據(jù)庫、模板工具模塊、連接池服務(wù)模塊、數(shù)據(jù)分片服務(wù)模塊、主從熱備模塊、數(shù)據(jù)同步服務(wù)模塊和在線擴容模塊。其中，模板工具模塊對外提供的接口，連接所述的SEDA分布式消息框架；連接池服務(wù)模塊對應(yīng)每一個所述的Redis服務(wù)器提供一個連接池；數(shù)據(jù)分片服務(wù)模塊將數(shù)據(jù)分布存儲于不同的Redis服務(wù)器中；主從熱備模塊為每一個所述的Redis服務(wù)器配置一臺從服務(wù)器，Redis核心內(nèi)存處理框架自動檢測主從的狀態(tài)并在主機宕機時切換到對應(yīng)的從服務(wù)器；數(shù)據(jù)同步服務(wù)模塊維護一個寫緩沖隊列，緩沖隊列到達一定數(shù)量后將寫入所述的關(guān)系數(shù)據(jù)庫；在線擴容模塊用以支持在不間斷運行的狀況下對所述的Redis核心內(nèi)存處理框架進行擴容。本發(fā)明還一種利用所述的系統(tǒng)進行基于云計算實現(xiàn)實時事件處理的方法。在一種實施方式中，該方法包括接收消息操作和發(fā)送消息操作。其中，所述的接收消息操作，如圖4所示，包括以下步驟 (al)所述的SEDA分布式消息框架進行啟動初始化；(a2)所述的Redis核心內(nèi)存處理框架進行啟動初始化；(a3)所述的SEDA分布式消息框架接收到http請求包，并將該http請求包反序列化為消息；(a4)系統(tǒng)調(diào)用所述的Redis核心內(nèi)存處理框架的模板工具模塊將消息持久化到Redis服務(wù)器；(a5)系統(tǒng)根據(jù)所述消息的消息頭判斷消息為請求消息還是返回消息；(a6)如果是請求消息，則將消息發(fā)送到所述的請求接入通道，并尋找對應(yīng)的業(yè)務(wù)邏輯單元進行處理；(a7)如果是返回消息，則將消息發(fā)送到所述的返回接入通道，并尋找對應(yīng)的業(yè)務(wù)邏輯單元進行處理；(a8)所述的請求接入通道調(diào)用所述的連接池服務(wù)模塊進行消息處理；(a9)所述的消息的業(yè)務(wù)邏輯代碼通過所述的Redis核心內(nèi)存處理框架來實現(xiàn)，并與所述的關(guān)系數(shù)據(jù)庫解耦合；(alO)所述的消息的業(yè)務(wù)邏輯構(gòu)建返回消息并調(diào)用服務(wù)容器進行發(fā)送。所述的發(fā)送消息操作，如圖5所示，包括以下步驟(bl)所述的SEDA分布式消息框架進行啟動初始化；(b2)所述的Redis核心內(nèi)存處理框架進行啟動初始化；(b3)業(yè)務(wù)代碼通過調(diào)用容器基礎(chǔ)模塊的消息創(chuàng)建工具單元，將業(yè)務(wù)對象包裝為消息，并調(diào)用服務(wù)容器分發(fā)接口 ；(b4)如果是雙向消息，業(yè)務(wù)代碼調(diào)用所述的返回監(jiān)聽模塊和容器基礎(chǔ)模塊的超時管理單元進行監(jiān)聽；(b5)系統(tǒng)根據(jù)所述消息的消息頭確定對應(yīng)的接出通道；(b6)所述的接出通道根據(jù)所述的消息頭確定對應(yīng)的路由信息為本地路由或遠程路由；(b7)如果是本地路由，則直接投遞到本地的消息接入通道；(b8)如果是遠程路由，則序列化消息并通過http遠程工具發(fā)送。
在一種較優(yōu)選的實施方式中，步驟(al)與(bl)所述的SEDA分布式消息框架進行啟動初始化，具體包括以下步驟(1-1 )所述的SEDA分布式消息框架根據(jù)本地ip地址與管理端口，從所述的配置數(shù)據(jù)庫中查詢屬于本節(jié)點的配置信息；(1-2)所述的SEDA分布式消息框架將本節(jié)點的ip地址、管理端口以及其它配置信息拼成url,并啟動Jetty服務(wù)器；(1-3)所述的SEDA分布式消息框架利用屬于本節(jié)點的業(yè)務(wù)邏輯全路徑與服務(wù)類型的對應(yīng)信息，初始化所述的服務(wù)解析模塊；(1-4)所述的SEDA分布式消息框架利用所述的配置數(shù)據(jù)庫中所有服務(wù)類型與url的對應(yīng)信息，初始化所述的路由模塊；(1-5)所述的SEDA分布式消息框架利用所述的本節(jié)點的線程池配置信息初始化所述的消息通道；(1-6)所述的SEDA分布式消息框架根據(jù)所述的配置數(shù)據(jù)庫中所有集群節(jié)點的信息，初始化心跳服務(wù)。步驟(a2)和(b2)所述的Redis核心內(nèi)存處理框架進行啟動初始化，具體包括以下步驟(2-1)所述的Redis核心內(nèi)存處理框架根據(jù)配置數(shù)據(jù)庫中的Redis主機、從機地址信息以及連接池的連接數(shù)參數(shù)、等待時間參數(shù)，初始化所述的連接池服務(wù)模塊；(2-2)所述的Redis核心內(nèi)存處理框架根據(jù)配置數(shù)據(jù)庫中的數(shù)據(jù)集名稱與Redis服務(wù)器id的對應(yīng)信息，初始化所述的數(shù)據(jù)分片服務(wù)模塊；(2-3)所述的Redis核心內(nèi)存處理框架根據(jù)配置數(shù)據(jù)庫中的所有客戶端地址，初始化所述的主從熱備模塊；(2-4)所述的Redis核心內(nèi)存處理框架根據(jù)配置數(shù)據(jù)庫中的關(guān)系數(shù)據(jù)庫連接信息以及同步任務(wù)數(shù)量參數(shù)，初始化所述的數(shù)據(jù)同步服務(wù)模塊。在進一步優(yōu)選的實施方式中，所述的步驟(a3)具體包括以下步驟(a3_l)所述的SEDA分布式消息框架的Jetty服務(wù)器從HttpServletRequest請求信息中提取出InputStream輸入流,并且轉(zhuǎn)換為字節(jié)數(shù)組；(a3-2)所述的Jetty服務(wù)器讀取所述的字節(jié)數(shù)組前4位并轉(zhuǎn)換為10進制的數(shù)字N；(a3-3)所述的Jetty服務(wù)器讀取所述的字節(jié)數(shù)組的第5位到第N位，并轉(zhuǎn)換為字符串；(a3-4)所述的Jetty服務(wù)器以該字符串作為類的全路徑，反射得到序列化器類的實例；(a3-5)所述的Jetty服務(wù)器調(diào)用該類的反序列化方法處理后續(xù)所有字節(jié)得到消
肩、O所述的步驟(a4)具體包括以下步驟(a4_l)系統(tǒng)根據(jù)數(shù)據(jù)集名稱參數(shù)調(diào)用數(shù)據(jù)分片服務(wù)接口，獲得對應(yīng)的Redis服務(wù)器 id 與 dbid ；(a4-2)系統(tǒng)調(diào)用連接池服務(wù)接口獲得Redis的客戶端連接Jedis，并判斷連接是否成功；(a4_3)如果獲取連接失敗則調(diào)用關(guān)系數(shù)據(jù)庫的回調(diào)任務(wù)，將數(shù)據(jù)更新邏輯寫入所述的關(guān)系數(shù)據(jù)庫中；(a4_4)如果獲取連接成功則調(diào)用Redis命令select dbid選擇數(shù)據(jù)庫標(biāo)識dbid ；(a4_5)系統(tǒng)調(diào)用Redis的回調(diào)任務(wù)，將數(shù)據(jù)更新操作寫入內(nèi)存數(shù)據(jù)庫Redis中；(a4-6)系統(tǒng)調(diào)用連接池服務(wù)接口將客戶端連接Jedis歸還至連接池；(a4_7)系統(tǒng)調(diào)用數(shù)據(jù)同步服務(wù)接口將關(guān)系數(shù)據(jù)庫回調(diào)任務(wù)存放在內(nèi)存隊列中，達到閾值時，將批量隊列更新到關(guān)系數(shù)據(jù)庫。且步驟(a6)中所述的將消息發(fā)送到所述的請求接入通道，并尋找對應(yīng)的業(yè)務(wù)邏輯單元進行處理，具體包括以下步驟·(a6_l)所述的SEDA分布式消息框架根據(jù)消息頭中的服務(wù)類型和服務(wù)碼，從本地節(jié)點的各業(yè)務(wù)邏輯單元中查找對應(yīng)的業(yè)務(wù)邏輯；(a6-2)如果找到一條業(yè)務(wù)邏輯，則將消息發(fā)送到連接池服務(wù)模塊處理；(a6_3)如果找到多條業(yè)務(wù)邏輯，則將消息多次發(fā)送到連接池服務(wù)模塊并行處理。在另一種進一步優(yōu)選的實施方式中，所述的步驟(b4)具體包括以下步驟(b4_l)所述的雙向消息的業(yè)務(wù)代碼實現(xiàn)返回監(jiān)聽的回調(diào)方法，并構(gòu)建出上下文；(b4_2)所述的雙向消息的業(yè)務(wù)代碼調(diào)用服務(wù)容器接口，將返回監(jiān)聽注冊到所述的返回監(jiān)聽模塊，供返回接入通道使用；(b4_3)所述的雙向消息的業(yè)務(wù)代碼實現(xiàn)超時監(jiān)聽接口，并調(diào)用服務(wù)容器接口注冊到容器基礎(chǔ)模塊的超時管理單元；(b4_4)所述的超時管理單元將超時監(jiān)聽按照時間長度取模，并分別放在分別由5個線程管理的5個等級的隊列中，每個線程將定時查看對應(yīng)等級的隊列，如果規(guī)定時間內(nèi)沒有收到返回消息就會執(zhí)行超時監(jiān)聽中的邏輯，收到返回消息則從隊列中刪除超時監(jiān)聽對象。且步驟(b6)具體包括以下步驟(b6_l)所述的接出通道根據(jù)消息頭判斷該消息是請求消息還是返回消息；(b6-2)當(dāng)消息是請求消息時，所述的接出通道調(diào)用路由模塊的請求路由查詢接Π ；(b6-3)當(dāng)消息是返回消息時，所述的接出通道調(diào)用路由模塊的返回路由查詢接Π ；( b6-4 )所述的請求路由查詢接口將根據(jù)其從配置數(shù)據(jù)庫中獲取的集群全局配置信息以及消息頭中的服務(wù)類型查找到處理該消息的所有節(jié)點；(b6_5)當(dāng)多個節(jié)點的業(yè)務(wù)邏輯相同時，所述的請求路由利用負(fù)載均衡算法得出唯一節(jié)點；(b6-6)當(dāng)多個節(jié)點的業(yè)務(wù)邏輯不同時，所述的請求路由同時將消息發(fā)送到多個節(jié)占.(b6_7)所述的返回路由查詢接口將根據(jù)消息頭中的返回地址直接定位到目標(biāo)節(jié)點。在一種更優(yōu)選的實施方式中，所述的方法還包括心跳檢測操作，所述的心跳檢測操作包括以下步驟(Cl)所述的容器基礎(chǔ)模塊的心跳服務(wù)中心維護一個心跳線程；(c2)每一個所述的服務(wù)容器均通過所述的控制臺變更通知維護一個列表，所述列表中的每一個對象都代表著一個其它的服務(wù)容器，每個對象內(nèi)部都維護一個任務(wù)隊列；(c2)所述的心跳線程到達設(shè)定的心跳間隔時間后，就在所述列表中的每個對象的任務(wù)隊列中添加一個任務(wù)；(c3)所述對象收到任務(wù)后，向?qū)?yīng)的服務(wù)容器發(fā)出socket心跳消息；(c4)當(dāng)socket沒有正常返回時，拋出異常，說明本次心跳失敗，并將對應(yīng)的服務(wù)容器狀態(tài)設(shè)置為非活動；
(c5)當(dāng)再次向狀態(tài)為非活動的服務(wù)容器發(fā)出socket心跳消息，socket正常返回時，將對應(yīng)的服務(wù)容器狀態(tài)設(shè)置為活動；(c6)所述的路由模塊丟棄發(fā)向非活動的服務(wù)容器的消息，并返回異常。在本發(fā)明的應(yīng)用中，本發(fā)明的系統(tǒng)主要由兩個框架組成，分布式消息框架和內(nèi)存處理框架。分布式消息框架基于SEDA (分段事件驅(qū)動架構(gòu))的思想，完全依賴自身的技術(shù)積累來設(shè)計和實現(xiàn)。內(nèi)存處理框架則包裝了小巧開源的內(nèi)存數(shù)據(jù)庫Redis，在其外圍提供豐富的功能組件使其達到企業(yè)級應(yīng)用的需求。分布式消息框架和其中包裝的業(yè)務(wù)邏輯依賴內(nèi)存處理框架，這不僅是為了提高處理速度，更是為了減輕對關(guān)系數(shù)據(jù)庫的壓力，使性能在一定范圍內(nèi)自由伸縮。分布式消息框架的架構(gòu)如圖I所示，服務(wù)容器是分布式消息框架的頂層概念，一個web應(yīng)用中至多可以配置一個服務(wù)容器，業(yè)務(wù)邏輯代碼在任何需要的地方都可以調(diào)用唯一的服務(wù)容器所提供的sendMessage方法。一個服務(wù)容器內(nèi)可以配置多個業(yè)務(wù)邏輯，每個業(yè)務(wù)邏輯所處理的服務(wù)類型、服務(wù)碼是不同的，這些信息存于配置數(shù)據(jù)庫中，并應(yīng)用與服務(wù)解析模塊，inRequestChannel接收到的消息會根據(jù)服務(wù)解析模塊的結(jié)果定位到某一個業(yè)務(wù)服務(wù)邏輯。一個服務(wù)容器有且僅有6個channel (通道)。服務(wù)容器對外提供的sendMessage方法將把消息發(fā)送到本地的outRequestChannel請求接出通道。三個outchannel接出通道都將使用路由模塊將消息發(fā)送到一個遠程服務(wù)容器或本地服務(wù)容器的inchannel接入通道。其中outRequestChannel請求接出通道將使用請求路由將消息發(fā)送到遠程或本地服務(wù)容器的inRequestChannel請求接入通道,outReplyChannel回復(fù)接出通道將使用返回路由將消息發(fā)送到遠程或本地服務(wù)容器的inReplyChannel回復(fù)接入通道，outErrorChannel錯誤接出通道將使用返回路由將消息發(fā)送到遠程或本地服務(wù)容器的inErrorChannel錯誤接入通道?？刂婆_模塊由前端提供頁面并且直接做數(shù)據(jù)庫表的操作，只是在發(fā)變更集群通知時調(diào)用引擎提供的一個接口?；赟EDA思想的分布式消息框架用于把處理過程拆分為多個段，部署在不同的物理機器上承載。不同資源消耗的段使用不同的數(shù)量的線程、不同配置規(guī)格的機器來處理，段間采用http協(xié)議傳遞消息，業(yè)務(wù)數(shù)據(jù)被包裝在消息的消息體中?？梢园淹活愋偷南⒎职l(fā)到多個節(jié)點實現(xiàn)負(fù)載均衡即并行處理；可以把原有的處理過程打散，用消息包裝數(shù)據(jù)在多個節(jié)點之間傳送，使一個過程的不同環(huán)節(jié)在不同的物理節(jié)點上處理，實現(xiàn)了串行處理。這符合“性能應(yīng)該可以分開設(shè)計”的思想。
內(nèi)存處理框架以Redis為基礎(chǔ)，為消息框架以及其中包裝的業(yè)務(wù)邏輯提供在內(nèi)存中存取數(shù)據(jù)的服務(wù)，有持久化、同步到關(guān)系數(shù)據(jù)庫、主從切換、數(shù)據(jù)分片、連接池、在線擴容等功能，并對外提供模板工具作為接口。內(nèi)存處理框架的架構(gòu)圖如下所示，該圖說明了內(nèi)存處理框架僅依賴關(guān)系數(shù)據(jù)庫和Redis Server。而依賴內(nèi)存處理框架的主要是兩個部分,一是業(yè)務(wù)邏輯,通常它們已經(jīng)被包裝在分布式消息框架中了，比如數(shù)據(jù)關(guān)聯(lián)、數(shù)據(jù)還原、合規(guī)判斷；二是分布式消息框架中的三個入隊列，它們會把消息保存在Redis中，并利用Redis做巖機恢復(fù)。圖3表示內(nèi)存處理框架中的6個主要的模塊間的依賴關(guān)系。模板工具模板是對外提供的接口，用戶只需要實現(xiàn)回調(diào)方法，方法中使用jedis做業(yè)務(wù)邏輯即可，其他均不必關(guān)心。連接池服務(wù)對應(yīng)每一個Redis服務(wù)器，都會提供一個連接池，避免創(chuàng)建和銷毀連 接時的時間損耗。數(shù)據(jù)分片服務(wù)把數(shù)據(jù)分布的存儲在不同的Redis server中，因為一臺機器的內(nèi)存總是有限的，通過數(shù)據(jù)分片可以利用更多的內(nèi)存。主從熱備可以為每一個Redis服務(wù)器配置一臺從機，框架將自動檢測主從的狀態(tài)并在主機宕掉時發(fā)出切換通知。數(shù)據(jù)同步服務(wù)是一個寫緩沖隊列，到達一定數(shù)量后將寫入oracle數(shù)據(jù)庫，以此保證總有一份關(guān)系數(shù)據(jù)庫中的數(shù)據(jù)是可靠的。在線擴容框架的設(shè)計方案支持在不間斷運行的狀況下進行擴容。本發(fā)明的方法的整體處理流程包括對業(yè)務(wù)邏輯進行分段、段間使用消息進行異步通信、根據(jù)分段后的配置信息各個服務(wù)容器節(jié)點進行啟動初始化、任何一個服務(wù)容器都具有多個邏輯通道可以發(fā)送或接收消息、將業(yè)務(wù)對象包裝為消息再調(diào)用分發(fā)接口、根據(jù)消息頭和配置信息尋找遠程或本地路由、將消息序列化后通過http協(xié)議發(fā)送到遠端的服務(wù)容器、服務(wù)容器使用內(nèi)嵌jetty的方式接收http協(xié)議包并從中反序列化出消息、根據(jù)消息頭把消息發(fā)到適當(dāng)?shù)奶幚硗ǖ?、通道將對請求消息調(diào)用適當(dāng)?shù)臉I(yè)務(wù)邏輯進行處理、通道將對返回消息調(diào)用適當(dāng)?shù)姆祷乇O(jiān)聽進行處理、對于需要返回結(jié)果的消息可以在發(fā)送端做超時控制、接收消息的一端將使用先保存再處理的可靠性原則通過內(nèi)存處理框架把消息持久化到內(nèi)存數(shù)據(jù)庫、并據(jù)此實現(xiàn)宕機恢復(fù)等可靠性功能、被分段和包裝的業(yè)務(wù)邏輯可以把原有的關(guān)系數(shù)據(jù)庫相關(guān)邏輯重構(gòu)為使用內(nèi)存處理框架?；赟EDA的分布式消息框架的消息示意圖，如圖8所示?；赟EDA的分布式消息框架的路由類圖如圖9所示。本發(fā)明的方法應(yīng)用集群中的所有服務(wù)容器節(jié)點以及內(nèi)存數(shù)據(jù)庫服務(wù)器，在接收消息環(huán)節(jié)包括以下步驟(I)基于SEDA的分布式消息框架進行啟動初始化操作；(a)根據(jù)本地ip與管理端口，從數(shù)據(jù)庫配置表中查詢屬于本節(jié)點的配置信息；(b)根據(jù)本節(jié)點的ip、管理端口以及其他配置信息，拼成url并啟動Jetty服務(wù)器；(C)使用屬于本節(jié)點的業(yè)務(wù)邏輯全路徑與服務(wù)類型的對應(yīng)信息，初始化服務(wù)解析模塊；(d)使用配置表中所有服務(wù)類型與url的對應(yīng)信息，初始化路由模塊；
(e)使用本節(jié)點的線程池配置信息初始化接入通道；(f)根據(jù)配置表中所有集群節(jié)點的信息，初始化心跳服務(wù)。(2)以Redis為核心的內(nèi)存處理框架進行啟動初始化操作；(a)根據(jù)數(shù)據(jù)庫配置表中的Redis主機、從機地址信息，以及連接池的連接數(shù)參數(shù)、等待時間參數(shù)，初始化連接池服務(wù)模塊；(b)根據(jù)配置表中的數(shù)據(jù)集名稱與Redis服務(wù)器id的對應(yīng)信息，初始化數(shù)據(jù)分片模塊；(c)根據(jù)配置表中的所有客戶端地址，初始化主從熱備模塊；(d)根據(jù)配置表中的關(guān)系數(shù)據(jù)庫連接信息以及同步任務(wù)數(shù)量參數(shù)，初始化數(shù)據(jù)同·步模塊。(3)消息框架中的Jetty服務(wù)器接收到http請求包，并反序列化為消息；(a)從HttpServletRequest中提取出InputStream,并且轉(zhuǎn)換為字節(jié)數(shù)組；(b)讀取前4位并轉(zhuǎn)換為10進制的數(shù)字N ；(C)從第5位讀取到第N位，并轉(zhuǎn)換為字符串；(d)以該字符串作為類的全路徑，反射得到序列化器類的實例；(e)調(diào)用該類的反序列化方法處理后續(xù)所有字節(jié)得到消息。(4)通過內(nèi)存處理框架將消息持久化到內(nèi)存數(shù)據(jù)庫Redis ；(a)根據(jù)數(shù)據(jù)集名稱參數(shù)調(diào)用數(shù)據(jù)分片服務(wù)接口，獲得對應(yīng)的Redis服務(wù)器id與dbid ；(b)調(diào)用連接池服務(wù)接口獲得Redis的客戶端連接Jedis ；(C)如果獲取連接失敗則調(diào)用關(guān)系數(shù)據(jù)庫回調(diào)任務(wù)，將數(shù)據(jù)更新邏輯做到關(guān)系數(shù)據(jù)庫中；Cd)如果獲取連接成功則調(diào)用Redis命令select dbid ；(e)調(diào)用Redis的回調(diào)任務(wù)，將數(shù)據(jù)更新操作做到內(nèi)存數(shù)據(jù)庫Redis中；(f)調(diào)用連接池服務(wù)接口將客戶端連接Jedis歸還到連接池；(g)調(diào)用數(shù)據(jù)同步服務(wù)接口將關(guān)系數(shù)據(jù)庫回調(diào)任務(wù)存放在內(nèi)存隊列，達到閥值時將批量更新到關(guān)系數(shù)據(jù)庫。(5)根據(jù)消息頭判斷是請求消息還是返回消息；(6)如果是請求消息則發(fā)送到請求接入通道，并找到合適的業(yè)務(wù)邏輯進行處理；(a)根據(jù)消息頭中的服務(wù)類型和服務(wù)碼，從本地節(jié)點的業(yè)務(wù)邏輯服務(wù)集合中找到合適的業(yè)務(wù)邏輯；(b)如果找到一條業(yè)務(wù)邏輯，則將消息發(fā)送到線程池處理；(C)如果找到多條業(yè)務(wù)邏輯，則將消息多次發(fā)送到線程池處理即多個線程并行處理。(7)如果是返回消息則發(fā)送到返回接入通道進行處理；(8)請求接入通道以線程池的方式實現(xiàn)，不阻塞后續(xù)請求；(9)業(yè)務(wù)邏輯代碼通過內(nèi)存處理框架來實現(xiàn)，與關(guān)系數(shù)據(jù)庫解耦合；(10)業(yè)務(wù)邏輯可以構(gòu)建返回消息并調(diào)用服務(wù)容器的分發(fā)接口進行發(fā)送。在發(fā)送消息環(huán)節(jié)包括以下步驟
(I)基于SEDA的分布式消息框架進行啟動初始化操作；(2)以Redis為核心的內(nèi)存處理框架進行啟動初始化操作；(3)業(yè)務(wù)代碼調(diào)用消息構(gòu)建工具類把業(yè)務(wù)對象包裝為消息，并調(diào)用容器的分發(fā)接Π ；(4)如果是雙向消息，業(yè)務(wù)代碼可以調(diào)用容器接口注冊返回監(jiān)聽以及超時監(jiān)聽；(a)業(yè)務(wù)代碼需實現(xiàn)返回監(jiān)聽的回調(diào)方法并構(gòu)建出上下文；(b)業(yè)務(wù)代碼調(diào)用容器接口將返回監(jiān)聽注冊到返回監(jiān)聽管理器，供返回接入通道使用；(C)業(yè)務(wù)代碼需實現(xiàn)超時監(jiān)聽接口，并調(diào)用容器接口注冊到超時管理器中；
(d)超時管理器會將超時監(jiān)聽按照時間長度取模分別放在5個level的隊列中分別由5個線程來管理，每個線程將定時查看自己的隊列，如果規(guī)定時間內(nèi)沒有收到返回消息就會執(zhí)行超時監(jiān)聽中的邏輯，收到返回消息則從隊列中刪除超時監(jiān)聽對象。本發(fā)明的基于SEDA的分布式消息框架的返回監(jiān)聽與超時管理類圖如圖10所示。(5)根據(jù)消息頭將消息發(fā)送到合適的接出通道；(6)接出通道根據(jù)消息頭尋找合適的路由信息；(a)根據(jù)消息頭判斷該消息是請求消息還是返回消息；(b)當(dāng)消息是請求消息時，調(diào)用路由模塊的請求路由查詢接口 ；(c)當(dāng)消息是返回消息時，調(diào)用路由模塊的返回路由查詢接口 ；(d)請求路由查詢接口將根據(jù)其從配置表中獲取的集群全局配置信息以及消息頭中的服務(wù)類型查找到可以處理該消息的所有節(jié)點；(e)當(dāng)多個節(jié)點的業(yè)務(wù)邏輯相同時會使用負(fù)載均衡算法得出唯一結(jié)果；(f)當(dāng)多個節(jié)點的業(yè)務(wù)邏輯不同時會同時將消息發(fā)送到多個節(jié)點；(g)返回路由查詢接口將根據(jù)消息頭中的返回地址直接定位到目標(biāo)節(jié)點。(7)如果是本地路由，則直接投遞到本地的消息接入通道；(8)如果是遠程路由，則序列化消息并通過http遠程工具發(fā)送；(9)如果查詢到多個遠程路由，則通過負(fù)載均衡算法得出唯一的遠程路由。同時，因為本地消息有可能被發(fā)送到任何其他節(jié)點，所以要對集群中所有節(jié)點持續(xù)做心跳檢測，本發(fā)明的基于SEDA的分布式消息框架的心跳服務(wù)類圖如圖11所示，心跳檢測操作包括以下步驟( I)每一個服務(wù)容器都會維護一個列表，列表中的每一個對象都代表著一個其他的服務(wù)容器，這個列表依靠控制臺的變更通知來維護；(2)心跳線程到了心跳的間隔時間后就為列表中的每個對象添加一個任務(wù)，每個對象內(nèi)部都有一個任務(wù)隊列；(3)對象收到任務(wù)后負(fù)責(zé)向自己對應(yīng)的服務(wù)容器發(fā)出socket心跳消息；(4)當(dāng)socket沒有正常返回時會拋出異常，說明本次心跳失敗，此時并不會將該對象從列表刪除，而只是設(shè)置其狀態(tài)為非活動，下次心跳時間到來時仍然會嘗試向其發(fā)送心跳消息；(5)沒有死亡判斷，而是在活動與非活動之間交替轉(zhuǎn)換，在非活動時仍然會發(fā)心跳消息，成功后其狀態(tài)轉(zhuǎn)換為活動，路由模塊又可以發(fā)消息給它，而在它非活動時發(fā)向它的消息直接丟棄，返回異常。所述的配置信息將集中放在數(shù)據(jù)庫表中并依靠變更通知支持熱加載。當(dāng)實施人員在控制臺中修改了某個服務(wù)容器的配置、或新增刪除某個服務(wù)容器，控制臺會主動調(diào)用引擎提供的一個接口，該接口會從已經(jīng)存在的服務(wù)容器中尋找一個來發(fā)送變更通知，因為任何一個服務(wù)容器都維護著其他容器的信息，所以收到變更通知的這個容器會向所有其他的容器發(fā)送內(nèi)部變更通知，所有容器都將查詢數(shù)據(jù)庫得到最新的配置信息，依靠這些最新的配置，它們將維護自己的路由規(guī)則庫、服務(wù)解析模塊、服務(wù)容器集群服務(wù)等。實際應(yīng)用中的內(nèi)存處理框架中模板方法，如圖6所示，包括如下實現(xiàn)步驟1、Redis 開關(guān)在某些項目實施中，沒有高性能的要求，為了減小實施難度、減小系統(tǒng)運行的復(fù)雜度、減小發(fā)生事故的可能性，我們做了 Redis開關(guān)，當(dāng)在數(shù)據(jù)庫中配置為關(guān)閉時，內(nèi)存處理框架將直接執(zhí)行RDBCallback任務(wù)，且不對RedisCallback做任何保存。2、獲取數(shù)據(jù)分片信息調(diào)用數(shù)據(jù)分片服務(wù)的接口，獲得當(dāng)前要處理的數(shù)據(jù)集所對應(yīng)的分配信息，即RedisServerName 和 dbid。3、獲取 Jedis 連接調(diào)用連接池服務(wù)的接口，根據(jù)RedisServerName獲得Jedis連接,該Jedis是框架包裝后的Jedis，把其所屬的JedisPool也放入其中，這樣方便歸還，并代理了原始Jedis的所有方法，使得用戶可以像使用原始Jedis —樣方便操作。4、select dbid分片信息中還包含dbid，是在一個Redis服務(wù)器實例中對數(shù)據(jù)進行分庫以提升性能，在進行任務(wù)Redis操作之前,應(yīng)該先執(zhí)行select dbid轉(zhuǎn)換到該數(shù)據(jù)集對應(yīng)的正確的庫。5、調(diào)用 RedisCallback轉(zhuǎn)換到正確的庫后，就可以調(diào)用Redis的回調(diào)方法對Redis做業(yè)務(wù)邏輯了。6、歸還Jedis到連接池Redis回調(diào)方法結(jié)束后，應(yīng)該把jedis返還到它所屬的連接池，可能是正常返還，也可能因操作過程中發(fā)生了異常而中斷返還，該Jedis是框架包裝后的，可以從中直接取出JedisPool進行返還。7、把RDBCallback放入任務(wù)隊列因為需要把所有更新操作同步到關(guān)系數(shù)據(jù)庫以保證總有一份數(shù)據(jù)是最可靠的，但又不能對性能影響太大，所以在同步數(shù)據(jù)服務(wù)中實現(xiàn)了緩沖任務(wù)隊列，當(dāng)達到一定數(shù)量時進行批處理，RDBCallback不僅是一個回調(diào)接口，其中也封裝了數(shù)據(jù)庫操作中所需的數(shù)據(jù)。8、切換開關(guān)如果獲取Jedis連接失敗，說明Redis主機已經(jīng)宕機且沒有從機可用或從機也已經(jīng)宕機。如果切換開關(guān)打開，說明項目實施要求切換到關(guān)系數(shù)據(jù)庫、要保證業(yè)務(wù)邏輯正常運行即使慢一點，所有直接調(diào)用RDBCal Iback對關(guān)系數(shù)據(jù)庫進行操作。如果切換開關(guān)關(guān)閉，說明該項目認(rèn)為Redis宕機后應(yīng)該中斷服務(wù)，人為介入處理。9、調(diào)用 RDBCallback
10、把 RedisCallback 存入任務(wù)隊列為了在Redis恢復(fù)后平滑切換到Redis,還需要把Redis中斷后的所有更新操作同步到Redis，所有此處會把RedisCallback存入內(nèi)存任務(wù)隊列，到達一定數(shù)量后序列號到數(shù)據(jù)庫。當(dāng)Redi s重啟后會檢查內(nèi)存和數(shù)據(jù)庫中的Redi sCal Iback任務(wù)并在Redi s服務(wù)器上重放，這一部分在內(nèi)存處理框架的啟動監(jiān)聽中實現(xiàn)。需要注意的是為了使增刪改任務(wù)在不同時間執(zhí)行可以對Redis產(chǎn)生同樣的效果、且只對Redis產(chǎn)生效果，RedisCallback只能包裝Redis相關(guān)的操作，db邏輯和其他業(yè)務(wù)邏輯放在外面。本發(fā)明的內(nèi)存處理框架中，連接池服務(wù)的一種參考實現(xiàn)方式如下連接池模塊會根據(jù)配置表中Redis服務(wù)器的地址以及連接池參數(shù)，為每個Redis服務(wù)器的主服務(wù)器創(chuàng)建一個連接池，主服務(wù)器和從服務(wù)器會使用同一個Redis服務(wù)器名稱。當(dāng)模板方法請求分配連接時，連接池模塊會首先根據(jù)Redis服務(wù)器名稱嘗試從主服務(wù)器獲取連接，當(dāng)獲取失敗或者獲取到的連接在測試可用性時失敗(連接池的testOnBorrow屬性設(shè)為true,連接池在獲取連接時會使用ping進行測試，失敗則拋出異常)，將等待2秒，如果連續(xù)5次失敗，將調(diào)用主從熱備模塊的接口到數(shù)據(jù)庫的Redis服務(wù)器狀態(tài)表中查詢該Redisserver的狀態(tài)，如果已經(jīng)死亡且從機正常，則銷毀主服務(wù)器連接池、重建從服務(wù)器連接池、自動切換到從機的連接池。在配置表中，有主從之別，但在運行當(dāng)中，主從是可以來回切換的，只有當(dāng)前和備用的區(qū)別。從連接池中獲取連接的實現(xiàn)，如圖7所示，包括以下步驟I、根據(jù)參數(shù)RedisServerName從該Redis服務(wù)器的當(dāng)前連接池獲取連接；2、如果獲取連接時拋出了異常，可能是檢測連接可用性時出了問題，等待2秒，重新從該連接池獲取，如果仍失敗則繼續(xù)嘗試，嘗試5次；3、5次嘗試均告失敗則調(diào)用主從熱備模塊接口查詢當(dāng)前主機的狀態(tài)；4、如果當(dāng)前主機的狀態(tài)是死亡則銷毀當(dāng)前連接池，重建從機連接池，切換到從機(目前僅支持一個從機);5、調(diào)用主從熱備的切換同步接口 ；6、如果所有客戶端均切換成功則從新的連接池獲取連接。本發(fā)明的內(nèi)存處理框架中，主從熱備模塊的一種參考實現(xiàn)方式如下Redis具有Master-slave的功能,可以在主服務(wù)器上掛一臺從服務(wù)器,對主服務(wù)器的改動會通過socket傳送到從服務(wù)器執(zhí)行一遍。但Redis提供的是服務(wù)器端的功能，在本模塊中，我們從客戶端入手即從內(nèi)存處理框架入手，提供在多客戶端的部署環(huán)境中、在分片的環(huán)境中的王從連接池切換功能。主從熱備模塊在啟動過程中會把自己的ip地址和管理端口放入Redis客戶端注冊表。連接池模塊會根據(jù)Redis配置表中的主從配置創(chuàng)建出主服務(wù)器的連接池。使用過程中，當(dāng)從連接池獲取連接失敗，會sleep兩秒再獲取連接，多次失敗后，該客戶端認(rèn)為當(dāng)前連接池對應(yīng)的主服務(wù)器宕機。進而調(diào)用主從熱備模塊的接口把該結(jié)果寫入Redis服務(wù)器狀態(tài)表，再向其他客戶端發(fā)出巖機檢查通知，主從模塊內(nèi)部會從Redis客戶端配置表中讀取出此時此刻所有的客戶端地址，并調(diào)用心跳服務(wù)一一檢查這些客戶端的狀態(tài)，向正常運行的客戶端發(fā)送socket消息,并將成功發(fā)送消息的客戶端地址記錄在內(nèi)存中(socket無異常即是發(fā)送成功了)，其他客戶端接收到這個消息后通過被認(rèn)為宕機的Redis服務(wù)器對應(yīng)的連接池中獲取連接并測試連通性的方式確認(rèn)該服務(wù)器是否宕機，并把測試結(jié)果與自己的地址寫入Redis服務(wù)器狀態(tài)表，該過程中首個發(fā)現(xiàn)宕機的客戶端采用輪詢的方式查看Redis服務(wù)器狀態(tài)表，直到所有接到通知的客戶端都檢查完畢時收集這些測試結(jié)果，只有所有客戶端都認(rèn)為該Redis服務(wù)器宕機，才能進入下一個環(huán)節(jié)即切換連接池。最早發(fā)現(xiàn)宕機的客戶端首先切換了連接池(銷毀主連接池、初始化從連接池)，但此時它還不能使用新的連接池，它會向所有正常運行的客戶端發(fā)出切換通知，其他客戶端切換后會向Redis狀態(tài)表中記錄切換標(biāo)不，起始客戶端收集到所有結(jié)果后與入冋步完成標(biāo)識，此刻所有客戶端都可以使用新的連接池了，起始客戶端還負(fù)責(zé)在Redis配置表中記錄切換歷史(可用于頁面監(jiān)控臺的實時展現(xiàn))。
該方案解決以下幾個問題當(dāng)某客戶端與Redis服務(wù)器連接斷開時，不會切換到從服務(wù)器從而導(dǎo)致主從數(shù)據(jù)不一致；當(dāng)某客戶端使用的Redis服務(wù)器其他客戶端此刻并未用到，仍然可以獲取其他所有客戶端的連通性測試結(jié)果，從而達到統(tǒng)一切換的目的；當(dāng)某客戶端宕機時，它不會收到宕機測試通知，其他客戶端也不會等待它的返回結(jié)果；因為有切換同步的過程，所以不存在主從數(shù)據(jù)不一致的狀況。另外，維護人員在監(jiān)控臺中看到宕機與切換的通知后，需要人工修改從服務(wù)器的配置文件使其不再從屬于其他機器(為了日后重啟)，需要把主服務(wù)器的配置文件改為從屬于新的主服務(wù)器，重啟宕機的服務(wù)器。本發(fā)明的內(nèi)存處理框架中，數(shù)據(jù)同步模塊的一種參考實現(xiàn)方式如下為了在提高下性能的同時最大程度的保證數(shù)據(jù)安全，我們決定仍然在關(guān)系數(shù)據(jù)庫中存一份主數(shù)據(jù)，當(dāng)Redis巖機或Redis數(shù)據(jù)文件無法恢復(fù)時，內(nèi)存處理框架可以自動切換到關(guān)系數(shù)據(jù)庫相關(guān)的業(yè)務(wù)邏輯，既保證產(chǎn)品可以運行下去，也保證數(shù)據(jù)完整性。數(shù)據(jù)同步模塊有一個任務(wù)隊列和一個線程，任務(wù)隊列中保存的是RDBCallback，每次加入一條新的任務(wù)都會喚醒線程，線程檢查隊列中的任務(wù)數(shù)量是否達到內(nèi)置的閥值(t匕如1000)，如果達到則按照先進先出的順序執(zhí)行這些RDBCallback任務(wù)，該回調(diào)方法中完整的封裝了 oracle相關(guān)的所有更新操作(不包括查詢)，且該對象中已經(jīng)提前放入了當(dāng)時的數(shù)據(jù)上下文。數(shù)據(jù)同步的模塊中還包括另一個功能，即Redis數(shù)據(jù)文件備份功能，該功能由shell腳本定時復(fù)制出每個Redis服務(wù)器的數(shù)據(jù)文件放在備份目錄中，并加上時效，比如三個月前的可以刪除，該shell腳本需要在部署Redis的同時人工部署和啟動。在上述實施例中，使用的是基于Java語言的描述，當(dāng)然也可以根據(jù)需要采用其它的面向?qū)ο缶幊陶Z目。在某BAM (業(yè)務(wù)活動監(jiān)控)產(chǎn)品中，我們使用基于SEDA和內(nèi)存數(shù)據(jù)庫的實時事件處理方法對原有處理過程進行改造后，整體性能可以提升1(Γ15倍，甚至不僅僅是提升，而是把不可能變?yōu)榭赡堋Ｊ褂脙?nèi)存處理框架改造業(yè)務(wù)事件關(guān)聯(lián)環(huán)節(jié)后，數(shù)據(jù)庫壓力下降5倍(數(shù)據(jù)庫服務(wù)器的CPU占有率從80%下降到15%)，關(guān)聯(lián)環(huán)節(jié)的整體處理時間降低(1000萬數(shù)據(jù)的處理時間由3小時降低為I小時)。此時，在分布式消息框架的幫助下，將三個主要的處理環(huán)節(jié)(關(guān)聯(lián)、還原、違規(guī)判斷)拆分后使用5臺機器承載，3小時處理了 I. 5億數(shù)據(jù)，性能提升15倍。考慮到存量數(shù)據(jù)對關(guān)系數(shù)據(jù)庫的巨大影響，當(dāng)達到I. 5億數(shù)據(jù)量時，處理延時很可能已經(jīng)無法容忍。如果沒有內(nèi)存處理框架的幫助，多上一臺機器，關(guān)系數(shù)據(jù)庫將被壓垮。采用了該發(fā)明的計算機軟件系統(tǒng)中基于云計算實現(xiàn)實時事件處理的系統(tǒng)，其包括SEDA分布式消息框架和Redis核心內(nèi)存處理框架。利用該系統(tǒng)實現(xiàn)實時事件處理的方法包括接收消息操作和發(fā)送消息操作。該方 法將分布式消息框架和Redis核心內(nèi)存處理框架融合，從而可以有效地應(yīng)對實時監(jiān)控或準(zhǔn)實時分析類系統(tǒng)中的高并發(fā)請求與大數(shù)據(jù)量處理需求，實現(xiàn)復(fù)雜的業(yè)務(wù)邏輯處理流程，滿足高吞吐量、低延遲的性能要求，并且有效控制系統(tǒng)資源、提高運行過程的可靠性，達到性能可以分段設(shè)計，在一定范圍內(nèi)自由伸縮的目標(biāo)，適合應(yīng)用于性能要求苛刻的業(yè)務(wù)活動監(jiān)控或準(zhǔn)實時分析類系統(tǒng)中，且本發(fā)明的計算機軟件系統(tǒng)中基于云計算實現(xiàn)實時事件處理的系統(tǒng)及方法，其系統(tǒng)結(jié)構(gòu)簡單，應(yīng)用成本低廉。在此說明書中，本發(fā)明已參照其特定的實施例作了描述。但是，很顯然仍可以作出各種修改和變換而不背離本發(fā)明的精神和范圍。因此，說明書和附圖應(yīng)被認(rèn)為是說明性的而非限制性的。
權(quán)利要求
1.一種計算機軟件系統(tǒng)中基于云計算實現(xiàn)實時事件處理的系統(tǒng)，其特征在于，所述的系統(tǒng)包括SEDA分布式消息框架和Redis核心內(nèi)存處理框架； 所述的SEDA分布式消息框架包括控制平臺、配置數(shù)據(jù)庫和服務(wù)容器，所述的控制平臺和服務(wù)容器均連接所述的配置數(shù)據(jù)庫，所述的服務(wù)容器包括容器基礎(chǔ)模塊、消息處理服務(wù)模塊、路由模塊、服務(wù)解析模塊和返回監(jiān)聽模塊；所述的消息處理服務(wù)模塊包括至少一個業(yè)務(wù)邏輯單元和六個消息通道，所述的各業(yè)務(wù)邏輯單元對應(yīng)不同的服務(wù)應(yīng)用業(yè)務(wù)，所述的業(yè)務(wù)邏輯單元通過所述的消息通道連接所述的Redis核心內(nèi)存處理框架，所述的六個消息通道為請求接出通道、請求接入通道、返回接出通道、返回接入通道、錯誤接出通道和錯誤接入通道； 所述的Redis核心內(nèi)存處理框架包括多個Redis服務(wù)器和關(guān)系數(shù)據(jù)庫，還包括 模板工具模塊，對外提供的接口，連接所述的SEDA分布式消息框架； 連接池服務(wù)模塊，對應(yīng)每一個所述的Redis服務(wù)器提供一個連接池； 數(shù)據(jù)分片服務(wù)模塊，將數(shù)據(jù)分布存儲于不同的Redis服務(wù)器中； 主從熱備模塊，為每一個所述的Redis服務(wù)器配置一臺從服務(wù)器，Redis核心內(nèi)存處理框架自動檢測主從的狀態(tài)并在主機宕機 時切換到對應(yīng)的從服務(wù)器； 數(shù)據(jù)同步服務(wù)模塊，維護一個寫緩沖隊列，緩沖隊列到達一定數(shù)量后將寫入所述的關(guān)系數(shù)據(jù)庫； 在線擴容模塊，用以支持在不間斷運行的狀況下對所述的Redis核心內(nèi)存處理框架進行擴容。
2.根據(jù)權(quán)利要求I所述的計算機軟件系統(tǒng)中基于云計算實現(xiàn)實時事件處理的系統(tǒng)，其特征在于，所述的容器基礎(chǔ)模塊包括資源管理單元、超時管理單元、心跳服務(wù)單元、集群通知單元、遠程通信單元、負(fù)載均衡單元、通道管理單元和消息創(chuàng)建工具單元，所述的資源管理單元、超時管理單元、心跳服務(wù)單元、集群通知單元、遠程通信單元、負(fù)載均衡單元、通道管理單元和消息創(chuàng)建工具單元均連接所述的服務(wù)容器。
3.一種利用權(quán)利要求I所述的系統(tǒng)進行基于云計算實現(xiàn)實時事件處理的方法，其特征在于，所述的方法包括接收消息操作和發(fā)送消息操作，所述的接收消息操作包括以下步驟 (al)所述的SEDA分布式消息框架進行啟動初始化； (a2)所述的Redis核心內(nèi)存處理框架進行啟動初始化； (a3)所述的SEDA分布式消息框架接收到http請求包,并將該http請求包反序列化為消息； (a4)系統(tǒng)調(diào)用所述的Redis核心內(nèi)存處理框架的模板工具模塊將消息持久化到Redis服務(wù)器； (a5)系統(tǒng)根據(jù)所述消息的消息頭判斷消息為請求消息還是返回消息； (a6)如果是請求消息，則將消息發(fā)送到所述的請求接入通道，并尋找對應(yīng)的業(yè)務(wù)邏輯單元進行處理； (a7)如果是返回消息，則將消息發(fā)送到所述的返回接入通道，并尋找對應(yīng)的業(yè)務(wù)邏輯單元進行處理； (a8)所述的請求接入通道調(diào)用所述的連接池服務(wù)模塊進行消息處理；(a9)所述的消息的業(yè)務(wù)邏輯代碼通過所述的Redis核心內(nèi)存處理框架來實現(xiàn)，并與所述的關(guān)系數(shù)據(jù)庫解耦合； (alO)所述的消息的業(yè)務(wù)邏輯構(gòu)建返回消息并調(diào)用服務(wù)容器進行發(fā)送； 所述的發(fā)送消息操作包括以下步驟 (bl)所述的SEDA分布式消息框架進行啟動初始化； (b2)所述的Redis核心內(nèi)存處理框架進行啟動初始化； (b3)業(yè)務(wù)代碼通過調(diào)用容器基礎(chǔ)模塊的消息創(chuàng)建工具單元，將業(yè)務(wù)對象包裝為消息， 并調(diào)用服務(wù)容器分發(fā)接口； (b4)如果是雙向消息，業(yè)務(wù)代碼調(diào)用所述的返回監(jiān)聽模塊和容器基礎(chǔ)模塊的超時管理單元進行監(jiān)聽； (b5)系統(tǒng)根據(jù)所述消息的消息頭確定對應(yīng)的接出通道； (b6)所述的接出通道根據(jù)所述的消息頭確定對應(yīng)的路由信息為本地路由或遠程路由； (b7)如果是本地路由，則直接投遞到本地的消息接入通道； (b8)如果是遠程路由，則序列化消息并通過http遠程工具發(fā)送。
4.根據(jù)權(quán)利要求3所述的進行基于云計算實現(xiàn)實時事件處理的方法，其特征在于，所述的SEDA分布式消息框架進行啟動初始化，具體包括以下步驟 (1-1)所述的SEDA分布式消息框架根據(jù)本地ip地址與管理端口，從所述的配置數(shù)據(jù)庫中查詢屬于本節(jié)點的配置信息； (1-2)所述的SEDA分布式消息框架將本節(jié)點的ip地址、管理端口以及其它配置信息拼成url,并啟動Jetty服務(wù)器； (1-3)所述的SEDA分布式消息框架利用屬于本節(jié)點的業(yè)務(wù)邏輯全路徑與服務(wù)類型的對應(yīng)信息，初始化所述的服務(wù)解析模塊； (1-4)所述的SEDA分布式消息框架利用所述的配置數(shù)據(jù)庫中所有服務(wù)類型與url的對應(yīng)信息，初始化所述的路由模塊； (1-5)所述的SEDA分布式消息框架利用所述的本節(jié)點的線程池配置信息初始化所述的消息通道； (1-6)所述的SEDA分布式消息框架根據(jù)所述的配置數(shù)據(jù)庫中所有集群節(jié)點的信息，初始化心跳服務(wù)。
5.根據(jù)權(quán)利要求3所述的進行基于云計算實現(xiàn)實時事件處理的方法，其特征在于，所述的Redis核心內(nèi)存處理框架進行啟動初始化,具體包括以下步驟 (2-1)所述的Redis核心內(nèi)存處理框架根據(jù)配置數(shù)據(jù)庫中的Redis主機、從機地址信息以及連接池的連接數(shù)參數(shù)、等待時間參數(shù)，初始化所述的連接池服務(wù)模塊； (2-2)所述的Redis核心內(nèi)存處理框架根據(jù)配置數(shù)據(jù)庫中的數(shù)據(jù)集名稱與Redis服務(wù)器id的對應(yīng)信息，初始化所述的數(shù)據(jù)分片服務(wù)模塊； (2-3)所述的Redis核心內(nèi)存處理框架根據(jù)配置數(shù)據(jù)庫中的所有客戶端地址，初始化所述的主從熱備模塊； (2-4)所述的Redis核心內(nèi)存處理框架根據(jù)配置數(shù)據(jù)庫中的關(guān)系數(shù)據(jù)庫連接信息以及同步任務(wù)數(shù)量參數(shù)，初始化所述的數(shù)據(jù)同步服務(wù)模塊。
6.根據(jù)權(quán)利要求3所述的進行基于云計算實現(xiàn)實時事件處理的方法，其特征在于，所述的步驟(a3)具體包括以下步驟 (a3_l)所述的SEDA分布式消息框架的Jetty服務(wù)器從HttpServletRequest請求信息中提取出InputStream輸入流,并且轉(zhuǎn)換為字節(jié)數(shù)組； (a3-2)所述的Jetty服務(wù)器讀取所述的字節(jié)數(shù)組前4位并轉(zhuǎn)換為10進制的數(shù)字N ； (a3_3)所述的Jetty服務(wù)器讀取所述的字節(jié)數(shù)組的第5位到第N位，并轉(zhuǎn)換為字符串； (a3-4)所述的Jetty服務(wù)器以該字符串作為類的全路徑，反射得到序列化器類的實例； (a3-5)所述的Jetty服務(wù)器調(diào)用該類的反序列化方法處理后續(xù)所有字節(jié)得到消息。
7.根據(jù)權(quán)利要求3所述的進行基于云計算實現(xiàn)實時事件處理的方法，其特征在于，所述的步驟(a4)具體包括以下步驟 (a4_l)系統(tǒng)根據(jù)數(shù)據(jù)集名稱參數(shù)調(diào)用數(shù)據(jù)分片服務(wù)接口，獲得對應(yīng)的Redis服務(wù)器id與 dbid ； (a4-2)系統(tǒng)調(diào)用連接池服務(wù)接口獲得Redis的客戶端連接Jedis，并判斷連接是否成功； (a4_3)如果獲取連接失敗則調(diào)用關(guān)系數(shù)據(jù)庫的回調(diào)任務(wù)，將數(shù)據(jù)更新邏輯寫入所述的關(guān)系數(shù)據(jù)庫中； (a4_4)如果獲取連接成功則調(diào)用Redis命令select dbid選擇數(shù)據(jù)庫標(biāo)識dbid ； (a4-5)系統(tǒng)調(diào)用Redis的回調(diào)任務(wù)，將數(shù)據(jù)更新操作寫入內(nèi)存數(shù)據(jù)庫Redis中； (a4-6)系統(tǒng)調(diào)用連接池服務(wù)接口將客戶端連接Jedis歸還至連接池； (a4_7)系統(tǒng)調(diào)用數(shù)據(jù)同步服務(wù)接口將關(guān)系數(shù)據(jù)庫回調(diào)任務(wù)存放在內(nèi)存隊列中，達到閾值時，將批量隊列更新到關(guān)系數(shù)據(jù)庫。
8.根據(jù)權(quán)利要求3所述的進行基于云計算實現(xiàn)實時事件處理的方法，其特征在于，所述的步驟(a6)中所述的將消息發(fā)送到所述的請求接入通道，并尋找對應(yīng)的業(yè)務(wù)邏輯單元進行處理，具體包括以下步驟 (a6-l)所述的SEDA分布式消息框架根據(jù)消息頭中的服務(wù)類型和服務(wù)碼，從本地節(jié)點的各業(yè)務(wù)邏輯單元中查找對應(yīng)的業(yè)務(wù)邏輯； (a6-2)如果找到一條業(yè)務(wù)邏輯，則將消息發(fā)送到連接池服務(wù)模塊處理； (a6-3)如果找到多條業(yè)務(wù)邏輯，則將消息多次發(fā)送到連接池服務(wù)模塊并行處理。
9.根據(jù)權(quán)利要求3所述的進行基于云計算實現(xiàn)實時事件處理的方法，其特征在于，所述的步驟(b4)具體包括以下步驟 (b4-l)所述的雙向消息的業(yè)務(wù)代碼實現(xiàn)返回監(jiān)聽的回調(diào)方法，并構(gòu)建出上下文；(b4-2)所述的雙向消息的業(yè)務(wù)代碼調(diào)用服務(wù)容器接口，將返回監(jiān)聽注冊到所述的返回監(jiān)聽模塊，供返回接入通道使用； (b4-3)所述的雙向消息的業(yè)務(wù)代碼實現(xiàn)超時監(jiān)聽接口，并調(diào)用服務(wù)容器接口注冊到容器基礎(chǔ)模塊的超時管理單元； (b4-4)所述的超時管理單元將超時監(jiān)聽按照時間長度取模，并分別放在分別由5個線程管理的5個等級的隊列中，每個線程將定時查看對應(yīng)等級的隊列，如果規(guī)定時間內(nèi)沒有收到返回消息就會執(zhí)行超時監(jiān)聽中的邏輯，收到返回消息則從隊列中刪除超時監(jiān)聽對象。
10.根據(jù)權(quán)利要求3所述的進行基于云計算實現(xiàn)實時事件處理的方法，其特征在于，所述的步驟(b6)具體包括以下步驟 (b6-l)所述的接出通道根據(jù)消息頭判斷該消息是請求消息還是返回消息； (b6-2)當(dāng)消息是請求消息時，所 述的接出通道調(diào)用路由模塊的請求路由查詢接口 ；(b6-3)當(dāng)消息是返回消息時，所述的接出通道調(diào)用路由模塊的返回路由查詢接口 ；(b6-4)所述的請求路由查詢接口將根據(jù)其從配置數(shù)據(jù)庫中獲取的集群全局配置信息以及消息頭中的服務(wù)類型查找到處理該消息的所有節(jié)點； (b6-5)當(dāng)多個節(jié)點的業(yè)務(wù)邏輯相同時，所述的請求路由利用負(fù)載均衡算法得出唯一節(jié)占. (b6-6)當(dāng)多個節(jié)點的業(yè)務(wù)邏輯不同時，所述的請求路由同時將消息發(fā)送到多個節(jié)點； (b6-7)所述的返回路由查詢接口將根據(jù)消息頭中的返回地址直接定位到目標(biāo)節(jié)點。
11.根據(jù)權(quán)利要求3至10中任一項所述的進行基于云計算實現(xiàn)實時事件處理的方法，其特征在于，所述的方法還包括心跳檢測操作，所述的心跳檢測操作包括以下步驟 (Cl)所述的容器基礎(chǔ)模塊的心跳服務(wù)中心維護一個心跳線程； (c2)每一個所述的服務(wù)容器均通過所述的控制臺變更通知維護一個列表，所述列表中的每一個對象都代表著一個其它的服務(wù)容器，每個對象內(nèi)部都維護一個任務(wù)隊列； (c2)所述的心跳線程到達設(shè)定的心跳間隔時間后，就在所述列表中的每個對象的任務(wù)隊列中添加一個任務(wù)； (c3)所述對象收到任務(wù)后，向?qū)?yīng)的服務(wù)容器發(fā)出socket心跳消息； (c4)當(dāng)socket沒有正常返回時，拋出異常，說明本次心跳失敗，并將對應(yīng)的服務(wù)容器狀態(tài)設(shè)置為非活動； (c5)當(dāng)再次向狀態(tài)為非活動的服務(wù)容器發(fā)出socket心跳消息，socket正常返回時，將對應(yīng)的服務(wù)容器狀態(tài)設(shè)置為活動； (c6)所述的路由模塊丟棄發(fā)向非活動的服務(wù)容器的消息，并返回異常。
全文摘要
本發(fā)明涉及一種計算機軟件系統(tǒng)中基于云計算的實時事件處理系統(tǒng)及方法，屬于計算機軟件應(yīng)用技術(shù)領(lǐng)域。該系統(tǒng)包括SEDA分布式消息框架和Redis核心內(nèi)存處理框架。利用該系統(tǒng)的方法包括接收消息操作和發(fā)送消息操作。通過該方法將分布式消息框架和Redis核心內(nèi)存處理框架融合，從而可以有效地應(yīng)對高并發(fā)請求與大數(shù)據(jù)量處理需求，實現(xiàn)復(fù)雜的業(yè)務(wù)邏輯處理流程，滿足高吞吐量、低延遲的性能要求，并且有效控制系統(tǒng)資源、提高運行過程的可靠性，達到性能可以分段設(shè)計，在一定范圍內(nèi)自由伸縮的目標(biāo)，適合應(yīng)用于性能要求苛刻的業(yè)務(wù)活動監(jiān)控或準(zhǔn)實時分析類系統(tǒng)中，且本發(fā)明的計算機軟件系統(tǒng)中基于云計算實現(xiàn)實時事件處理的系統(tǒng)及方法，其系統(tǒng)結(jié)構(gòu)簡單，應(yīng)用成本低廉。
文檔編號G06F9/44GK102880475SQ20121040767
公開日2013年1月16日 申請日期2012年10月23日 優(yōu)先權(quán)日2012年10月23日
發(fā)明者蘇陽 申請人:上海普元信息技術(shù)股份有限公司