一種高可用的流式處理系統(tǒng)及方法
【專利摘要】本發(fā)明公開了一種高可用的流式處理系統(tǒng)及方法，其中，該系統(tǒng)包括：上游應用系統(tǒng)，用于根據(jù)上游業(yè)務應用的進程，實時產(chǎn)生原始數(shù)據(jù)，逐條發(fā)送至接收裝置；接收裝置，用于將原始數(shù)據(jù)轉(zhuǎn)發(fā)至消息中間件裝置的消息隊列；消息中間件裝置，用于以消息隊列的形式為流式處理拓撲裝置緩存數(shù)據(jù)；流式處理拓撲裝置，用于處理原始數(shù)據(jù)的數(shù)據(jù)流，生成數(shù)據(jù)結(jié)果；下游應用系統(tǒng)，對應業(yè)務場景，用于根據(jù)對數(shù)據(jù)結(jié)果進行后續(xù)處理。
【專利說明】
一種高可用的流式處理系統(tǒng)及方法
技術領域
[0001] 本發(fā)明涉及信息處理領域，尤指一種高可用的流式處理系統(tǒng)及方法。
【背景技術】
[0002] "流數(shù)據(jù)"名詞最早出現(xiàn)在通信領域，隨著信息網(wǎng)絡技術的發(fā)展，其定義和應用范 圍在不斷擴展。在數(shù)據(jù)分析、風險監(jiān)控和網(wǎng)絡安全等領域，各類業(yè)務系統(tǒng)產(chǎn)生的數(shù)據(jù)序列快 速到達、可持續(xù)生成、無限增長，我們亦稱之流數(shù)據(jù)。然而，傳統(tǒng)的集中式處理IT架構在處理 此類數(shù)據(jù)時，面臨著幾大難題。第一，企業(yè)用戶對流數(shù)據(jù)的新增了實時分析處理的需求，即 數(shù)據(jù)從上游應用系統(tǒng)業(yè)務生成到下游應用系統(tǒng)處理完畢總共花費的時間不超過秒級。第 二，傳統(tǒng)主機由于其單節(jié)點集中式處理的特性，存儲能力和處理能力受限，在業(yè)務量高峰期 難以承載高吞吐量。第三，由于高性能主機價格及運維費用高昂，企業(yè)承受巨大的前期投資 及后期維護等經(jīng)濟性成本的重壓。綜上所述，企業(yè)IT架構紛紛向廉價的分布式服務器處理 技術轉(zhuǎn)型。
[0003] 分布式流式數(shù)據(jù)處理技術結(jié)合分布式服務器集群部署以及實時流數(shù)據(jù)處理技術， 具有成本低廉、集群可彈性伸縮、數(shù)據(jù)處理吞吐量大以及數(shù)據(jù)處理時效性強等顯著優(yōu)點。但 和集中式處理IT架構相比，由于分布式節(jié)點的故障率增大，分布式架構在負載均衡、故障恢 復、數(shù)據(jù)恢復等方面又面臨著巨大的挑戰(zhàn)。此外，傳統(tǒng)的數(shù)據(jù)處理系統(tǒng)與上層應用的耦合度 過高，難以兼容多種數(shù)據(jù)分析處理場景，若需修改或新增業(yè)務模塊，需要同時修改底層數(shù)據(jù) 處理框架。因此，企業(yè)亟需一種改進的高可用的流式數(shù)據(jù)處理系統(tǒng)，在穩(wěn)定運行的前提下， 不僅做到對數(shù)據(jù)的快速處理，同時能及時恢復故障節(jié)點和丟失的數(shù)據(jù)，并且其底層處理框 架可支持多種業(yè)務場景。

【發(fā)明內(nèi)容】

[0004] 為應對大規(guī)模處理環(huán)境中發(fā)生的各種問題，本發(fā)明提出了一種高可用的流式處理 系統(tǒng)及方法。本發(fā)明設計實現(xiàn)了拓撲的分布式流數(shù)據(jù)計算框架，克服了數(shù)據(jù)在傳遞和處理 過程中因磁盤I/O效率低下的問題，通過在每個數(shù)據(jù)流處理節(jié)點使用本地內(nèi)存，有效保證了 數(shù)據(jù)實時處理性能;本發(fā)明改進了傳統(tǒng)數(shù)據(jù)處理方法難以兼容多種數(shù)據(jù)分析處理場景的問 題，將基礎框架模塊與具體業(yè)務邏輯模塊進行松耦合設計，從而對復雜多樣的業(yè)務模型提 供堅實的底層支持;本發(fā)明克服了傳統(tǒng)數(shù)據(jù)處理系統(tǒng)單點負載過大的問題，采用去中心化 的架構設計，設計多個節(jié)點并發(fā)地進行相同業(yè)務處理，合理利用集群計算資源;本發(fā)明克服 了因分布式工作節(jié)點故障引發(fā)的集群工作不穩(wěn)定、數(shù)據(jù)丟失等難點，利用Zookeeper技術實 現(xiàn)了故障自動恢復機制，同時，利用Spark內(nèi)存快速計算實現(xiàn)了丟失數(shù)據(jù)的準實時查找。
[0005] 具體的，本發(fā)明提出的高可用的流式處理系統(tǒng)包括:上游應用系統(tǒng)，用于根據(jù)上游 業(yè)務應用的進程，實時產(chǎn)生原始數(shù)據(jù)，逐條發(fā)送至接收裝置;接收裝置，用于將原始數(shù)據(jù)轉(zhuǎn) 發(fā)至消息中間件裝置的消息隊列；消息中間件裝置，用于以消息隊列的形式為流式處理拓 撲裝置緩存數(shù)據(jù);流式處理拓撲裝置，用于處理原始數(shù)據(jù)的數(shù)據(jù)流，生成數(shù)據(jù)結(jié)果；下游應 用系統(tǒng)，對應業(yè)務場景，用于根據(jù)對數(shù)據(jù)結(jié)果進行后續(xù)處理。
[0006] 進一步的，所述流式處理拓撲裝置包括:采集組件、模型組件、轉(zhuǎn)發(fā)組件，每個組件 對應多個工作節(jié)點;其中，所述采集組件，用于從所述消息中間件裝置的消息隊列中讀取上 游應用系統(tǒng)的原始數(shù)據(jù)記錄，將原始數(shù)據(jù)轉(zhuǎn)化為內(nèi)部組件的工作節(jié)點能操作的 MessageObject消息對象格式，根據(jù)路由表設定將轉(zhuǎn)化后的數(shù)據(jù)轉(zhuǎn)發(fā)給下游的模型組件;模 型組件，一條數(shù)據(jù)處理鏈路中串行存在一個或多個模型組件，每個模型組件用于將轉(zhuǎn)化后 的數(shù)據(jù)按上層應用系統(tǒng)指定的業(yè)務邏輯進行處理，生成數(shù)據(jù)結(jié)果，轉(zhuǎn)發(fā)至下游模型組件或 轉(zhuǎn)發(fā)組件，如果一條數(shù)據(jù)處理鏈路有多個模型組件，則按序依次對轉(zhuǎn)化后的數(shù)據(jù)進行處理； 轉(zhuǎn)發(fā)組件，用于將數(shù)據(jù)結(jié)果轉(zhuǎn)發(fā)至對應的下游應用系統(tǒng)。
[0007] 進一步的，該系統(tǒng)還包括:心跳探測裝置，用于周期性的接收來自流式處理拓撲裝 置的工作節(jié)點的心跳信息，將已發(fā)送心跳的工作節(jié)點列表轉(zhuǎn)發(fā)至系統(tǒng)守衛(wèi)裝置;系統(tǒng)守衛(wèi) 裝置，用于接收心跳探測裝置的發(fā)送的列表信息，監(jiān)控流式處理拓撲裝置的運行狀況;還用 于重啟故障工作節(jié)點，恢復其正常工作;還用于以細粒度模式恢復系統(tǒng)運行中丟失的數(shù)據(jù)。
[0008] 進一步的，該系統(tǒng)還包括:系統(tǒng)信息持久化裝置，用于管理維護系統(tǒng)中的相關組件 和工作節(jié)點的信息，以及記錄各個工作節(jié)點的運行狀態(tài)，以及緩存待恢復的數(shù)據(jù)記錄。
[0009] 進一步的，該系統(tǒng)還包括:海量日志管理裝置，用于收集、存儲框架日志，供后續(xù)挖 掘使用；日志對賬裝置，用于找到在處理過程中丟失的數(shù)據(jù)記錄，通過基于對賬機制的挖掘 算法，定期讀取海量日志管理裝置中框架日志，最終將將丟失的數(shù)據(jù)記錄信息寫入系統(tǒng)信 息持久化裝置用于恢復處理。
[0010] 進一步的，所述系統(tǒng)守衛(wèi)裝置包括監(jiān)控管理單元、故障恢復單元、數(shù)據(jù)恢復單元； 其中，監(jiān)控管理單元，用于監(jiān)測系統(tǒng)中各個組件的工作節(jié)點的運行狀態(tài)，周期性地接收來自 心跳探測裝置的消息，消息內(nèi)容包括在本周期內(nèi)已成功發(fā)送心跳的工作節(jié)點列表，監(jiān)控管 理單元將該工作節(jié)點列表寫入系統(tǒng)信息持久化裝置中；故障恢復單元，用于周期性地將系 統(tǒng)信息持久化裝置中記錄的成功發(fā)送心跳的工作節(jié)點列表與流式處理拓撲裝置的全體工 作節(jié)點進行比對，尋找沒有發(fā)送心跳的工作節(jié)點，對于預設的時間區(qū)間內(nèi)沒有及時發(fā)送心 跳的工作節(jié)點，故障恢復單元判斷該工作節(jié)點發(fā)生故障，將故障工作節(jié)點信息寫入系統(tǒng)信 息持久化裝置，并從系統(tǒng)信息持久化裝置中找到該故障節(jié)點的服務器IP端口信息和配置信 息，在目的地服務器進行遠程重啟;數(shù)據(jù)恢復單元，用于定期從系統(tǒng)信息持久化裝置中讀取 系統(tǒng)運行過程中丟失的數(shù)據(jù)記錄，并進行逐條細粒度恢復。
[0011] 進一步的，所述數(shù)據(jù)恢復單元，用于讀取系統(tǒng)信息持久化裝置中數(shù)據(jù)丟失時的組 件ID，并按既定策略確定數(shù)據(jù)重新發(fā)送給該組件的某個工作節(jié)點ID，找到該工作節(jié)點的服 務器IP和端口；
[0012] 當所述數(shù)據(jù)恢復單元讀取到丟失的數(shù)據(jù)記錄，將其由文本重新封裝成消息對象， 根據(jù)發(fā)送目的地服務器IP和端口重新發(fā)送至流式處理拓撲裝置的對應組件工作節(jié)點。
[0013] 本發(fā)明還提出了一種高可用的流式處理方法，該方法包括:步驟S1，上游應用系統(tǒng) 實時產(chǎn)生原始數(shù)據(jù)，逐條發(fā)送至接收裝置;步驟S2,接收裝置將原始數(shù)據(jù)轉(zhuǎn)發(fā)至消息中間件 裝置的消息隊列，消息中間件裝置以消息隊列的形式為流式處理拓撲裝置緩存數(shù)據(jù);步驟 S3,流式處理拓撲裝置啟動，采集組件、模型組件、轉(zhuǎn)發(fā)組件的工作節(jié)點進行初始化工作，在 內(nèi)存中加載工作組件轉(zhuǎn)發(fā)路由信息和數(shù)據(jù)映射信息公共數(shù)據(jù);步驟S4,心跳探測裝置、系統(tǒng) 守衛(wèi)裝置進行實時保衛(wèi)系統(tǒng)正常運行，心跳探測裝置監(jiān)控系統(tǒng)所有工作節(jié)點，當系統(tǒng)守衛(wèi) 裝置監(jiān)測到工作節(jié)點發(fā)生故障，進行遠程重啟；步驟S5,流式處理拓撲裝置的采集組件從消 息中間件裝置的消息隊列中讀取并處理原始數(shù)據(jù)轉(zhuǎn)變?yōu)橄ο?，在流式處理拓撲裝置中 根據(jù)工作組件轉(zhuǎn)發(fā)路由信息和數(shù)據(jù)映射信息傳遞至下游的一個或多個模型組件;步驟S6， 每條數(shù)據(jù)處理鏈路分支的模型組件以上層應用系統(tǒng)指定的業(yè)務邏輯對數(shù)據(jù)記錄進行處理， 根據(jù)工作組件轉(zhuǎn)發(fā)路由信息和數(shù)據(jù)映射信息轉(zhuǎn)發(fā)至下游模型組件或轉(zhuǎn)發(fā)組件;每條數(shù)據(jù)處 理鏈路分支存在一個或多個模型組件，最后一個模型組件將數(shù)據(jù)轉(zhuǎn)發(fā)到轉(zhuǎn)發(fā)組件;步驟S7， 轉(zhuǎn)發(fā)組件將數(shù)據(jù)轉(zhuǎn)發(fā)到下游應用系統(tǒng);在步驟S5、S6、S7中所有組件的工作節(jié)點會實時地在 工作日志中記錄當前的處理狀態(tài)，用于后續(xù)數(shù)據(jù)恢復組件查找丟失的數(shù)據(jù)記錄;步驟S8,日 志對賬裝置定期查找在步驟S5、S6、S7中轉(zhuǎn)發(fā)失敗的數(shù)據(jù)記錄信息，由系統(tǒng)守衛(wèi)裝置進行數(shù) 據(jù)記錄恢復發(fā)送。
[0014] 進一步的，在步驟S4中，還包括:步驟S401，流式處理拓撲裝置的工作節(jié)點在正常 工作時，定期向心跳探測裝置發(fā)送心跳，心跳探測裝置定期將已收到心跳的工作節(jié)點收集 成列表，轉(zhuǎn)發(fā)至監(jiān)控管理單元；步驟S402,監(jiān)控管理單元收集成功發(fā)送心跳的工作節(jié)點列 表，將該工作節(jié)點列表寫入系統(tǒng)信息持久化裝置中；步驟S403,故障恢復單元查找故障節(jié) 點，并遠程重啟故障節(jié)點。
[0015] 進一步的，在步驟S403中，還包括:故障恢復單元將系統(tǒng)信息持久化裝置中記錄的 成功發(fā)送心跳的工作節(jié)點列表與全體工作節(jié)點進行比對，尋找沒有發(fā)送心跳的工作節(jié)點， 對于預設的時間區(qū)間內(nèi)沒有及時發(fā)送心跳的工作節(jié)點，故障恢復單元判斷該工作節(jié)點發(fā)生 故障；故障恢復單元將故障工作節(jié)點信息寫入系統(tǒng)信息持久化裝置，并從系統(tǒng)信息持久化 裝置中找到該故障節(jié)點的服務器IP端口信息和配置信息，采用SSH協(xié)議在目的地服務器進 行遠程重啟。
[0016] 進一步的，在步驟S8中，還包括:步驟S801，各個環(huán)節(jié)工作節(jié)點實時地在日志中記 錄處理數(shù)據(jù)記錄時的中間結(jié)果；步驟S802，日志對賬裝置周期性地查找丟失的數(shù)據(jù)；步驟 S803,數(shù)據(jù)恢復單元周期性地恢復丟失的數(shù)據(jù)記錄。
[0017] 進一步的，在步驟S802中，還包括:步驟S8021，將框架日志中相同主鍵數(shù)據(jù)記錄的 日志信息匯聚一個集合;步驟S8022,分析相同主鍵數(shù)據(jù)記錄的日志信息集合，從集合中找 到H標識和T標識的日志信息，檢查數(shù)據(jù)丟失的情況;步驟S8023,定位丟失的數(shù)據(jù)的在傳輸 過程中丟失時的路徑;步驟S8024,定位丟失的數(shù)據(jù)在故障轉(zhuǎn)發(fā)路徑發(fā)生數(shù)據(jù)丟失時所在組 件位置。
[0018] 本發(fā)明提出的一種高可用的流式處理系統(tǒng)及方法，可以應用于高性能數(shù)據(jù)處理平 臺，能在秒級水平對上游應用系統(tǒng)生成的數(shù)據(jù)進行處理，并采取多種措施提高系統(tǒng)的穩(wěn)定 性。具體包括以下優(yōu)點：
[0019] 1、本系統(tǒng)及方法將基礎框架模塊與具體業(yè)務邏輯模塊進行松耦合設計，可同時支 持多個高速實時的數(shù)據(jù)分析處理場景，對復雜多樣的業(yè)務模型提供堅實的底層支持，保證 數(shù)據(jù)得到快速有效的處理。
[0020] 2、本系統(tǒng)及方法提出的日志對賬方法可保障上游應用系統(tǒng)產(chǎn)生的每一條數(shù)據(jù)得 到處理，對于因異常丟失的數(shù)據(jù)，精確定位到具體位置和業(yè)務模型。
[0021] 3、本系統(tǒng)及方法對分布式集群的工作節(jié)點進行實時監(jiān)控，對發(fā)生故障的節(jié)點及時 響應并迅速恢復，確保系統(tǒng)持續(xù)對外正常服務。
【附圖說明】
[0022]此處所說明的附圖用來提供對本發(fā)明的進一步理解，構成本申請的一部分，并不 構成對本發(fā)明的限定。在附圖中：
[0023]圖1為本發(fā)明一實施例的高可用的流式處理系統(tǒng)結(jié)構示意圖。
[0024] 圖2為本發(fā)明一實施例的流式處理拓撲裝置的結(jié)構示意圖。
[0025] 圖3為本發(fā)明一實施例的采集、模型和轉(zhuǎn)發(fā)組件與節(jié)點關系的示意圖。
[0026] 圖4為本發(fā)明一實施例的采集、模型和轉(zhuǎn)發(fā)運作模式示意圖。
[0027]圖5為本發(fā)明另一實施例的流式處理拓撲裝置的結(jié)構示意圖。
[0028]圖6為本發(fā)明一實施例的系統(tǒng)守衛(wèi)裝置的結(jié)構示意圖。
[0029]圖7為本發(fā)明一實施例的高可用的流式處理方法流程圖。
[0030]圖8為本發(fā)明一實施例的步驟S4的系統(tǒng)保衛(wèi)流程示意圖。
[0031] 圖9為本發(fā)明一實施例的步驟S5、S6中采集組件和模型組件工作節(jié)點的數(shù)據(jù)轉(zhuǎn)發(fā) 流程示意圖。
[0032] 圖10為本發(fā)明一實施例的步驟S8的數(shù)據(jù)恢復流程示意圖。
[0033]圖11為本發(fā)明一實施例的采集、模型和轉(zhuǎn)發(fā)工作節(jié)點正常運行時日志記錄規(guī)則 圖。
[0034]圖12為本發(fā)明一實施例的采集、模型和轉(zhuǎn)發(fā)工作節(jié)點異常運行時日志記錄規(guī)則 圖。
[0035]圖13為本發(fā)明一實施例的步驟S802查找并定位丟失數(shù)據(jù)記錄的算法流程圖。
[0036]圖14為本發(fā)明一實施例的高可用得流式處理系統(tǒng)的日志收集流程圖。
【具體實施方式】
[0037]以下配合圖示及本發(fā)明的較佳實施例，進一步闡述本發(fā)明為達成預定發(fā)明目的所 采取的技術手段。
[0038]圖1為本發(fā)明一實施例的高可用的流式處理系統(tǒng)結(jié)構示意圖。如圖1所示，該系統(tǒng) 包括:上游應用系統(tǒng)101、接收裝置102、消息中間件裝置103、流式處理拓撲裝置104、下游應 用系統(tǒng)105、心跳探測裝置106、系統(tǒng)守衛(wèi)裝置107、系統(tǒng)信息持久化裝置108、海量日志管理 裝置109和日志對賬裝置110。其中，上游應用系統(tǒng)101和下游應用系統(tǒng)105為同本系統(tǒng)產(chǎn)生 聯(lián)系的外部裝置。為了確保系統(tǒng)核心裝置，即流式處理拓撲裝置104能夠持久穩(wěn)定地對上游 和下游應用系統(tǒng)提供服務，這樣可以采取多種措施保障系統(tǒng)的正常工作，并且做到對故障 節(jié)點及時響應和迅速恢復。
[0039] 具體的，上游應用系統(tǒng)101，用于根據(jù)上游業(yè)務應用的進程，實時產(chǎn)生原始數(shù)據(jù)，逐 條發(fā)送至接收裝置。所述上游應用系統(tǒng)101產(chǎn)生的數(shù)據(jù)以單條數(shù)據(jù)記錄為基本單位，每條數(shù) 據(jù)記錄包括一個唯一的數(shù)據(jù)主鍵，以及應用相關的細節(jié)信息。在系統(tǒng)內(nèi)部，數(shù)據(jù)以單條數(shù)據(jù) 記錄的細粒度模式進行傳輸和處理。
[0040] 接收裝置102,用于將原始數(shù)據(jù)轉(zhuǎn)發(fā)至消息中間件裝置的消息隊列;所述裝置設有 多個接收端，每個接收端異步且并發(fā)地處理數(shù)據(jù)，確保數(shù)據(jù)及時高效地傳遞給消息中間件 裝置103。
[0041]消息中間件裝置103,用于以消息隊列的形式為流式處理拓撲裝置緩存數(shù)據(jù)。消息 中間件裝置103以消息隊列的形式管理數(shù)據(jù)，有助于數(shù)據(jù)安全可靠地傳遞。同時，消息中間 件裝置103與接收裝置102的組合還打破了流式處理拓撲裝置104和上游應用系統(tǒng)101的直 接聯(lián)系，實現(xiàn)了結(jié)構松耦合。具體的，在業(yè)務高峰時段，上游應用系統(tǒng)101數(shù)據(jù)生成速度超過 流式處理的處理速度，消息中間件裝置103暫時緩存未能及時處理的數(shù)據(jù)，待業(yè)務低峰期將 數(shù)據(jù)消化處理。進一步地，若流式處理拓撲裝置104發(fā)生系統(tǒng)中斷等異常情況，消息中間件 裝置103暫停向流式處理拓撲裝置104供數(shù)，仍保持正常收數(shù)，確保暫停期間數(shù)據(jù)不丟失。本 系統(tǒng)可支持現(xiàn)有的多種消息中間件產(chǎn)品，若要根據(jù)應用需求更換消息中間件產(chǎn)品，只需下 游組件更新訪問消息中間件的方式，確保系統(tǒng)其余部分不做大的改動。
[0042]流式處理拓撲裝置104,用于處理原始數(shù)據(jù)的數(shù)據(jù)流，生成數(shù)據(jù)結(jié)果。流式處理拓 撲裝置104為本系統(tǒng)的核心裝置，部署在由多臺服務器組成的分布式集群之上，負責具體處 理數(shù)據(jù)流。該裝置包括采集組件、模型組件以及轉(zhuǎn)發(fā)組件。為了支持不同的數(shù)據(jù)分析處理場 景，將基礎框架模塊與具體業(yè)務邏輯模塊進行松耦合設計，所述松耦合設計是指本裝置著 重于數(shù)據(jù)的接收、緩存、轉(zhuǎn)發(fā)以及組件高可用性，不涉及具體數(shù)據(jù)處理的業(yè)務邏輯，只向上 層應用提供業(yè)務處理接口，由上層應用通過該業(yè)務處理接口進行指定和注入業(yè)務處理邏 輯。
[0043] 具體的，一條數(shù)據(jù)記錄先后經(jīng)過采集組件、模型組件和轉(zhuǎn)發(fā)組件傳遞到對應的下 游應用系統(tǒng)。為了提高系統(tǒng)的并發(fā)處理能力，每個組件對應多個工作節(jié)點，每個工作節(jié)點負 責相同的任務，可部署運行在不同服務器中。若一個工作節(jié)點發(fā)生故障，同一組件的其他節(jié) 點負擔起故障節(jié)點的工作量，直到故障節(jié)點恢復工作;若在業(yè)務高峰期，現(xiàn)有的工作節(jié)點無 法承受突然增加的工作量，可在不影響當前運行環(huán)境的前提下動態(tài)地增加工作節(jié)點。新的 組件工作節(jié)點加入工作后，系統(tǒng)會通知對應上游組件的所有工作節(jié)點更新轉(zhuǎn)發(fā)路由信息， 在轉(zhuǎn)發(fā)數(shù)據(jù)時可將數(shù)據(jù)轉(zhuǎn)發(fā)至新增的工作節(jié)點。
[0044] 下游應用系統(tǒng)105,對應業(yè)務場景，用于根據(jù)對數(shù)據(jù)結(jié)果進行后續(xù)處理。本系統(tǒng)可 同時支持多個業(yè)務場景，因此可設有多個下游應用系統(tǒng)。
[0045] 心跳探測裝置106,用于周期性的接收來自流式處理拓撲裝置的工作節(jié)點的心跳 信息，將已發(fā)送心跳的工作節(jié)點列表轉(zhuǎn)發(fā)至系統(tǒng)守衛(wèi)裝置。心跳探測裝置106采用了分布式 的服務框架，具體為Zookeeper技術。Zookeeper是一個開源的、分布式的服務框架，可以提 供分布式應用場景中的狀態(tài)同步服務，大大簡化了分布式協(xié)調(diào)服務的開發(fā)成本。
[0046]系統(tǒng)守衛(wèi)裝置107,用于接收心跳探測裝置的發(fā)送的列表信息，監(jiān)控流式處理拓撲 裝置的運行狀況;還用于重啟故障工作節(jié)點，恢復其正常工作;還用于以細粒度模式恢復系 統(tǒng)運行中丟失的數(shù)據(jù)。
[0047]系統(tǒng)信息持久化裝置108,用于管理維護系統(tǒng)中的相關組件和工作節(jié)點的信息，以 及記錄各個工作節(jié)點的運行狀態(tài)，以及緩存待恢復的數(shù)據(jù)記錄。系統(tǒng)信息持久化裝置108是 本系統(tǒng)高可用的不可缺少的中間環(huán)節(jié)，也是系統(tǒng)管理員實時觀測系統(tǒng)運行情況的必備接 口。具體的，該裝置采用了Oracle數(shù)據(jù)庫系統(tǒng)，但所述裝置對于數(shù)據(jù)庫的選擇沒有限制，也 可采用其他通用的關系數(shù)據(jù)庫系統(tǒng)。
[0048]海量日志管理裝置109，用于收集、存儲框架日志，供后續(xù)挖掘使用。海量日志管理 裝置109包括：日志收集器和日志存儲器。流式處理拓撲裝置104在運行時，每個組件工作節(jié) 點實時地生成框架日志，記錄組件工作節(jié)點中數(shù)據(jù)處理的中間結(jié)果。
[0049] 具體的，組件工作節(jié)點將框架日志內(nèi)容發(fā)送至日志收集器，日志收集器接收后將 內(nèi)容寫入日志文件，存儲于日志存儲器。為了增強所述裝置的效用，本系統(tǒng)對該裝置進行了 改進：1、為了不影響組件工作節(jié)點的正常工作，組件工作節(jié)點向日志收集器傳輸非核心日 志內(nèi)容時采取異步發(fā)送。2、為了保證日志數(shù)據(jù)收集的完整性，采用兩個位于不同服務器的 日志收集器對日志分別進行收集備份，在后續(xù)挖掘前先對兩份日志內(nèi)容進行整合去重。3、 由于生成的日志文件數(shù)據(jù)量龐大，將日志按按照分鐘長度切分管理日志，便于組織管理。4、 日志存儲器采用Hadoop分布式文件系統(tǒng)存儲這些海量日志。Hadoop文件系統(tǒng)是具有高容錯 性和高可靠性的分布式文件系統(tǒng)，可部署在廉價的服務器集群中，被廣泛地應用于大規(guī)模 數(shù)據(jù)存儲管理。
[0050] 日志對賬裝置110,用于找到在處理過程中丟失的數(shù)據(jù)記錄，通過基于對賬機制的 挖掘算法，定期讀取海量日志管理裝置109中框架日志，最終將將丟失的數(shù)據(jù)記錄信息寫入 系統(tǒng)信息持久化裝置108用于恢復處理。基于對賬機制的挖掘算法于后述圖10及圖13所示 實施例進行詳細講解，簡言之，一條數(shù)據(jù)記錄流經(jīng)流式處理拓撲裝置104的每個工作節(jié)點 時，工作節(jié)點在工作日志中用標識13、1?、1'、05和01?記錄當時的處理狀態(tài)，其中11和1'分別為 首、尾標識。最后匯總工作日志時，分析每條數(shù)據(jù)記錄是否有對應的首尾標識，若無，則說明 該條數(shù)據(jù)記錄在處理過程中丟失，可進一步找到數(shù)據(jù)記錄丟失位置。本實施例中挖掘算法 采用了 Spark技術實現(xiàn)，Spark作為一種通用的并行計算框架，基于分布式內(nèi)存并引入了內(nèi) 存計算的工作流程，同時具備MapReduce的計算特性以及快捷的數(shù)據(jù)處理效率。在數(shù)據(jù)恢復 上，所述裝置可以定位到數(shù)據(jù)丟失時的中間結(jié)果以及所位于的組件，保證后續(xù)數(shù)據(jù)恢復時 直接將數(shù)據(jù)中間結(jié)果發(fā)送至該組件的工作節(jié)點，真正確保了細粒度恢復。
[0051]圖2為本發(fā)明一實施例的流式處理拓撲裝置的結(jié)構示意圖。如圖2所示，流式處理 拓撲裝置104包括:采集組件1041、模型組件1042、轉(zhuǎn)發(fā)組件1043,每個組件對應多個工作節(jié) 點。其中，
[0052]組件是一類具有特定處理邏輯的虛擬組織，工作節(jié)點是組件具體的執(zhí)行者。如圖3 所示，一個組件對應多個工作節(jié)點，同一組件的工作節(jié)點擁有同一套處理邏輯，每個工作節(jié) 點可運行在不同服務器中，可并行工作。需要說明的是，采集組件1041、模型組件1042、轉(zhuǎn)發(fā) 組件1043的內(nèi)部結(jié)構相同，但其所承擔的工作任務類型不同，具體業(yè)務處理邏輯由上層應 用通過特定的業(yè)務處理接口進行指定和注入。在本系統(tǒng)中，為了區(qū)分組件，每個組件具有一 個特定的ID。同樣的，每個組件內(nèi)部的不同工作節(jié)點設有ID進行區(qū)分標識。在系統(tǒng)信息持久 化裝置108中通過ID記錄了組件間的路由轉(zhuǎn)發(fā)信息以及工作節(jié)點所在服務器IP和端口等內(nèi) 容。
[0053]如圖4所示，采集、模型和轉(zhuǎn)發(fā)工作節(jié)點的運作模式示意圖，在每個工作節(jié)點內(nèi)部， 按照生產(chǎn)者消費者模式維護著三個工作線程以及兩個消息隊列。所述生產(chǎn)者消費者模式指 對一個共享內(nèi)存進行寫數(shù)和取數(shù)操作，寫線程就是生產(chǎn)者(生產(chǎn)數(shù)據(jù)），取數(shù)線程就是消費 者（消費數(shù)據(jù)）。所述三個工作線程分別為接收線程、計算線程和發(fā)送線程，它們各司其職， 異步工作。計算線程負責根據(jù)本身的處理邏輯對數(shù)據(jù)進行分析處理;接收、發(fā)送線程分別負 責跟上、下游的組件工作節(jié)點進行數(shù)據(jù)交互。所述消息隊列，為接收消息隊列和發(fā)送消息隊 列。
[0054]具體的，在流式處理拓撲裝置104啟動后，每個組件工作節(jié)點初始化時，首先從系 統(tǒng)信息持久化裝置108中讀取路由信息和下游組件工作節(jié)點信息。系統(tǒng)信息持久化裝置108 中的工作組件轉(zhuǎn)發(fā)路由如下表1所示，已知每個組件有且只有唯一的上游組件，從下表可知 組件1無上游組件，則推斷出該組件為采集組件，組件2的上游組件為組件1，可推斷出該組 件為模型組件，模型組件可以依次類推，若該組組件無下游組件，可推斷出該組件為轉(zhuǎn)發(fā)組 件，由此推得數(shù)據(jù)轉(zhuǎn)發(fā)路徑:采集組件1-模型組件2-模型組件3-轉(zhuǎn)發(fā)組件4。表2所示的 組件節(jié)點信息表則記錄了本系統(tǒng)中所有組件節(jié)點的具體部署信息，內(nèi)容包括組件ID、節(jié)點 ID、部署服務器IP和端口等。另外，每個工作節(jié)點的公共內(nèi)存中記錄了其所在組件的下游組 件列表，以及每個組件所含工作節(jié)點的IP端口。工作節(jié)點需要獲取下游組件節(jié)點信息時，內(nèi) 部線程訪問可訪問這些公共數(shù)據(jù)，提高訪問效率。
[0055] 表1:工作組件轉(zhuǎn)發(fā)路由表示例一
[0057]表2:組件節(jié)點信息表示例
[0059]采集組件1041，用于從消息中間件裝置103的消息隊列中讀取上游應用系統(tǒng)101的 原始數(shù)據(jù)記錄，將數(shù)據(jù)轉(zhuǎn)化為本系統(tǒng)內(nèi)部組件工作節(jié)點可操作的MessageObject消息對象 格式，然后根據(jù)路由表設定將數(shù)據(jù)轉(zhuǎn)發(fā)給下游模型組件。所述MessageObject采用了 HashMap數(shù)據(jù)結(jié)構用于存儲原始數(shù)據(jù)記錄的信息。一個采集組件對應多個采集工作節(jié)點，每 個采集工作節(jié)點并發(fā)地按照上述相同的處理邏輯進行工作。在采集工作節(jié)點內(nèi)部，接收線 程、計算線程和發(fā)送線程具有各自不同的處理流程。
[0060] 具體的，接收線程負責訪問消息中間件裝置103,從消息隊列中讀取數(shù)據(jù)，寫入接 收隊列。由于本系統(tǒng)的消息中間件裝置103可能使用不同的中間件產(chǎn)品，因此接收線程訪問 消息中間件時可根據(jù)產(chǎn)品采用不同的連接方式。在更換消息中間件產(chǎn)品時，只需要更改所 述線程中涉及訪問讀寫的相關代碼，確保流式處理拓撲裝置的其余部分與消息中間件裝置 處于松親合狀態(tài)。
[0061] 具體的，計算線程負責讀取并解析接收隊列的原始數(shù)據(jù)，轉(zhuǎn)化為系統(tǒng)可識別的消 息對象，寫入發(fā)送隊列。同時，計算線程根據(jù)路由表找到所有下游模型組件，并在系統(tǒng)框架 日志中記錄當前工作狀態(tài)。本系統(tǒng)的流式處理拓撲裝置104內(nèi)部采用MessageObject對象格 式進行一致性處理，屏蔽了上游應用系統(tǒng)101的不同數(shù)據(jù)格式。對于不同的上游應用系統(tǒng) 101采用不同的數(shù)據(jù)格式，只需在本線程更改相關的解析代碼，確保流式處理拓撲裝置104 的其余部分與消息中間件裝置3處于松耦合狀態(tài)。
[0062]具體的，發(fā)送線程負責按照用戶指定的選擇策略(隨機方式、輪詢方式或者哈希方 式)選定下游組件的某個模型工作節(jié)點，將數(shù)據(jù)記錄轉(zhuǎn)發(fā)至該模型工作節(jié)點，并在系統(tǒng)框架 日志中記錄當前工作狀態(tài)。
[0063]模型組件1042:在本系統(tǒng)中，一條數(shù)據(jù)處理鏈路中可串行存在一個或多個模型組 件，每個模型組件負責將數(shù)據(jù)記錄按上層應用指定的業(yè)務邏輯進行處理，轉(zhuǎn)發(fā)至下游模型 組件或轉(zhuǎn)發(fā)組件。如此，一條鏈路若有多個模型組件，則按序依次對數(shù)據(jù)進行處理。在實施 例一中，模型組件包括多種類型，以上述路徑中模型組件2-模型組件3為例，模型組件2和 模型組件3內(nèi)部具有一套各自不同的數(shù)據(jù)處理邏輯，數(shù)據(jù)處理邏輯由上層應用通過業(yè)務處 理接口進行指定和注入。模型組件2的工作節(jié)點將數(shù)據(jù)處理完畢后，將中間數(shù)據(jù)轉(zhuǎn)發(fā)給模型 組件3的工作節(jié)點，模型組件3的工作節(jié)點將數(shù)據(jù)處理完畢后，將最終結(jié)果轉(zhuǎn)發(fā)給下游轉(zhuǎn)發(fā) 組件。
[0064]同采集組件類似，一個模型組件對應多個模型工作節(jié)點。在每個模型工作節(jié)點內(nèi) 部，接收線程負責接收來自上游組件發(fā)送的MessageObject消息對象格式的數(shù)據(jù)記錄，并記 錄框架日志;計算線程負責按照既定的數(shù)據(jù)處理邏輯處理數(shù)據(jù)記錄，處理后，數(shù)據(jù)記錄內(nèi)容 發(fā)生變化;發(fā)送線程負責按既定策略將新的數(shù)據(jù)記錄轉(zhuǎn)發(fā)至下游組件的工作節(jié)點，并在框 架日志中記錄當前運行信息。
[0065]轉(zhuǎn)發(fā)組件1043,用于將處理完畢的數(shù)據(jù)轉(zhuǎn)發(fā)至對應的下游應用系統(tǒng)105。所述轉(zhuǎn)發(fā) 組件接收線程和計算線程的工作模式同模型組件類似，但其作為流式處理拓撲裝置的最后 一環(huán)，發(fā)送線程根據(jù)下游應用系統(tǒng)105的IP端口，將數(shù)據(jù)記錄的處理結(jié)果轉(zhuǎn)發(fā)至系統(tǒng)外部的 下游應用系統(tǒng)105,并在框架日志中記錄當前運行信息。
[0066] 圖5為本發(fā)明另一實施例的流式處理拓撲裝置的結(jié)構示意圖。如圖5所示，與前一 實施例不同之處在于，本實施例中，采集組件1041同時連接多個模型組件1042, 即，一條數(shù) 據(jù)可以匹配一個或多個計算模型。在默認情況下，采集組件可將數(shù)據(jù)發(fā)送給所關聯(lián)的全部 下游模型組件，模型組件A和模型組件B能夠處理同一筆數(shù)據(jù);在特定情況下，采集組件通過 數(shù)據(jù)映射表可根據(jù)數(shù)據(jù)類型將數(shù)據(jù)發(fā)送給所關聯(lián)的下游模型組件。其現(xiàn)實意義在于，本系 統(tǒng)支持將同一筆數(shù)據(jù)進行不同的業(yè)務處理。
[0067] 為了實現(xiàn)一條數(shù)據(jù)匹配任意計算模型，系統(tǒng)信息持久化裝置108的工作組件轉(zhuǎn)發(fā) 路路由表可設計多條轉(zhuǎn)發(fā)路徑，以表3為例，可推得兩條轉(zhuǎn)發(fā)路徑：
[0068]轉(zhuǎn)發(fā)路徑1:采集組件1-模型組件2-轉(zhuǎn)發(fā)組件4 [0069]轉(zhuǎn)發(fā)路徑2:采集組件1-模型組件3-轉(zhuǎn)發(fā)組件5 [0070] 表3:工作組件轉(zhuǎn)發(fā)路由表示例二
[0073]在此實施例中，上游應用系統(tǒng)101在產(chǎn)生數(shù)據(jù)記錄時，需額外添加數(shù)據(jù)記錄類型的 字段。相應的，也必須在本系統(tǒng)的系統(tǒng)信息持久化裝置108中，建立一張映射表，補充記錄數(shù) 據(jù)類型與下游模型組件ID的匹配信息。數(shù)據(jù)映射表如表4所示：
[0074]表4:數(shù)據(jù)映射表
[0076]采集工作節(jié)點轉(zhuǎn)發(fā)數(shù)據(jù)時需選擇下游組件，采集工作節(jié)點提取獲得數(shù)據(jù)記錄的類 型，同數(shù)據(jù)映射表比對，找到該類型匹配的下游模型組件ID列表。例如數(shù)據(jù)類型為A的數(shù)據(jù) 記錄匹配的下游模型組件ID列表為2和3,可匹配轉(zhuǎn)發(fā)路徑1和轉(zhuǎn)發(fā)路徑2。而數(shù)據(jù)類型為B的 數(shù)據(jù)記錄只匹配下游模型組件2,因此采集組件在收到該類型數(shù)據(jù)后沿著轉(zhuǎn)發(fā)路徑1進行傳 遞。
[0077]需要說明的是，相同數(shù)據(jù)類型的數(shù)據(jù)多條轉(zhuǎn)發(fā)路徑只有采集組件重復，后續(xù)模型 組件、轉(zhuǎn)發(fā)組件均不相同，即可用轉(zhuǎn)發(fā)組件的ID定位特定數(shù)據(jù)類型的唯一一條轉(zhuǎn)發(fā)路徑。 [0078]圖6為本發(fā)明一實施例的系統(tǒng)守衛(wèi)裝置的結(jié)構示意圖。如圖6所示，系統(tǒng)守衛(wèi)裝置 107包括:監(jiān)控管理單元1071、故障恢復單元1072、數(shù)據(jù)恢復單元1073。其中，
[0079]監(jiān)控管理單元1071，用于監(jiān)測系統(tǒng)中各個組件的工作節(jié)點的運行狀態(tài)，周期性地 接收來自心跳探測裝置的消息，消息內(nèi)容包括在本周期內(nèi)已成功發(fā)送心跳的工作節(jié)點列 表，監(jiān)控管理單元將該工作節(jié)點列表寫入系統(tǒng)信息持久化裝置中；
[0080] 故障恢復單元1072,用于周期性地將系統(tǒng)信息持久化裝置中記錄的成功發(fā)送心跳 的工作節(jié)點列表與流式處理拓撲裝置的全體工作節(jié)點進行比對，尋找沒有發(fā)送心跳的工作 節(jié)點，對于預設的時間區(qū)間內(nèi)沒有及時發(fā)送心跳的工作節(jié)點，故障恢復單元判斷該工作節(jié) 點發(fā)生故障，將故障工作節(jié)點信息寫入系統(tǒng)信息持久化裝置，并從系統(tǒng)信息持久化裝置中 找到該故障節(jié)點的服務器IP端口信息和配置信息，在目的地服務器進行遠程重啟；
[0081] 數(shù)據(jù)恢復單元1073,用于定期從系統(tǒng)信息持久化裝置中讀取系統(tǒng)運行過程中丟失 的數(shù)據(jù)記錄，并進行逐條細粒度恢復;具體的，首先讀取系統(tǒng)信息持久化裝置中數(shù)據(jù)丟失時 的組件ID，并按既定策略確定數(shù)據(jù)重新發(fā)送給該組件的某個工作節(jié)點ID，找到該工作節(jié)點 的服務器IP和端口；接著，當所述數(shù)據(jù)恢復單元讀取到丟失的數(shù)據(jù)記錄，將其由文本重新封 裝成消息對象，根據(jù)發(fā)送目的地服務器IP和端口重新發(fā)送至流式處理拓撲裝置的對應組件 工作節(jié)點。
[0082]圖7為本發(fā)明一實施例的高可用的流式處理方法流程圖。如圖7所示，該方法包括： [0083]步驟S1，上游應用系統(tǒng)實時產(chǎn)生原始數(shù)據(jù)，逐條發(fā)送至接收裝置；
[0084]步驟S2，接收裝置將原始數(shù)據(jù)轉(zhuǎn)發(fā)至消息中間件裝置的消息隊列，消息中間件裝 置以消息隊列的形式為流式處理拓撲裝置緩存數(shù)據(jù)；
[0085]步驟S3,流式處理拓撲裝置啟動，采集組件、模型組件、轉(zhuǎn)發(fā)組件的工作節(jié)點進行 初始化工作，在內(nèi)存中加載工作組件轉(zhuǎn)發(fā)路由信息和數(shù)據(jù)映射信息公共數(shù)據(jù)；
[0086] 步驟S4,心跳探測裝置、系統(tǒng)守衛(wèi)裝置進行實時保衛(wèi)系統(tǒng)正常運行，心跳探測裝置 監(jiān)控系統(tǒng)所有工作節(jié)點，當系統(tǒng)守衛(wèi)裝置監(jiān)測到工作節(jié)點發(fā)生故障，進行遠程重啟；
[0087]步驟S5,流式處理拓撲裝置的采集組件從消息中間件裝置的消息隊列中讀取并處 理原始數(shù)據(jù)轉(zhuǎn)變?yōu)橄ο?，在流式處理拓撲裝置中根據(jù)工作組件轉(zhuǎn)發(fā)路由信息和數(shù)據(jù)映 射信息傳遞至下游的一個或多個模型組件；
[0088]步驟S6,每條數(shù)據(jù)處理鏈路分支的模型組件以上層應用系統(tǒng)指定的業(yè)務邏輯對數(shù) 據(jù)記錄進行處理，根據(jù)工作組件轉(zhuǎn)發(fā)路由信息和數(shù)據(jù)映射信息轉(zhuǎn)發(fā)至下游模型組件或轉(zhuǎn)發(fā) 組件;每條數(shù)據(jù)處理鏈路分支存在一個或多個模型組件，最后一個模型組件將數(shù)據(jù)轉(zhuǎn)發(fā)到 轉(zhuǎn)發(fā)組件；
[0089] 步驟S7，轉(zhuǎn)發(fā)組件將數(shù)據(jù)轉(zhuǎn)發(fā)到下游應用系統(tǒng)；
[0090] 在步驟S5、S6、S7中所有組件的工作節(jié)點會實時地在工作日志中記錄當前的處理 狀態(tài)，用于后續(xù)數(shù)據(jù)恢復組件查找丟失的數(shù)據(jù)記錄；
[0091] 步驟S8,日志對賬裝置定期查找在步驟S5、S6、S7中轉(zhuǎn)發(fā)失敗的數(shù)據(jù)記錄信息，由 系統(tǒng)守衛(wèi)裝置進行數(shù)據(jù)記錄恢復發(fā)送。
[0092] 相比于圖5所示實施例，圖2所示實施例的單條數(shù)據(jù)鏈路的設計較為簡單，無法突 出數(shù)據(jù)多分支傳輸?shù)奶匦?，故上述步驟以圖5所示實施例的情況進行說明。
[0093]圖8為本發(fā)明一實施例的步驟S4的系統(tǒng)保衛(wèi)流程示意圖。該流程是一種高可用的 流式處方法的故障恢復。由于分布式系統(tǒng)結(jié)構復雜的特性，分布式工作節(jié)點在工作時難免 發(fā)生故障。所以，為了保障系統(tǒng)穩(wěn)定持久運行，對于發(fā)生故障的工作節(jié)點，及時響應和迅速 恢復尤其重要。具體的，本系統(tǒng)設計對此設計實現(xiàn)了心跳探測裝置、監(jiān)控管理單元和故障恢 復單元，它們各司其職，分工合作，能夠監(jiān)控收集流式處理拓撲裝置工作節(jié)點的心跳，并查 找故障節(jié)點并恢復其運行。
[0094] 如圖8所示，在步驟S4中，還包括：
[0095]步驟S401，流式處理拓撲裝置的工作節(jié)點在正常工作時，定期向心跳探測裝置發(fā) 送心跳，心跳探測裝置定期將已收到心跳的工作節(jié)點收集成列表，轉(zhuǎn)發(fā)至監(jiān)控管理單元。 [0096]步驟S402,監(jiān)控管理單元收集成功發(fā)送心跳的工作節(jié)點列表，將該工作節(jié)點列表 寫入系統(tǒng)信息持久化裝置中。
[0097]具體的，監(jiān)控管理單元會收到來自心跳探測裝置的消息，消息內(nèi)容包括在本周期 內(nèi)已成功發(fā)送心跳的工作節(jié)點列表。所述單元則將該列表寫入系統(tǒng)信息持久化裝置108中。 [0098]步驟S403,故障恢復單元查找故障節(jié)點，并遠程重啟故障節(jié)點。
[0099]具體的，故障恢復單元將系統(tǒng)信息持久化裝置中記錄的成功發(fā)送心跳的工作節(jié)點 列表與全體工作節(jié)點進行比對，尋找沒有發(fā)送心跳的工作節(jié)點，對于預設的時間區(qū)間內(nèi)沒 有及時發(fā)送心跳的工作節(jié)點，故障恢復單元判斷該工作節(jié)點發(fā)生故障；
[0100] 故障恢復單元將故障工作節(jié)點信息寫入系統(tǒng)信息持久化裝置，并從系統(tǒng)信息持久 化裝置中找到該故障節(jié)點的服務器IP端口信息和配置信息，采用SSH協(xié)議在目的地服務器 進行遠程重啟。
[0101] 圖9為本發(fā)明一實施例的步驟S5、S6中采集組件和模型組件工作節(jié)點的數(shù)據(jù)轉(zhuǎn)發(fā) 流程示意圖。上游組件的工作節(jié)點將數(shù)據(jù)轉(zhuǎn)發(fā)給下游組件時，會采取一定的策略選擇下游 組件中可正常工作的工作節(jié)點，對發(fā)生故障的下游工作節(jié)點進行及時隔離。
[0102] 如圖9所示，具體步驟包括：
[0103]步驟S501，上游工作節(jié)點維護著數(shù)據(jù)轉(zhuǎn)發(fā)相關的公共信息。
[0104] 每個上游工作節(jié)點的內(nèi)存維護著本節(jié)點的路由轉(zhuǎn)發(fā)信息、下游組件節(jié)點IP端口信 息以及數(shù)據(jù)映射信息，這些信息在工作節(jié)點初始化時通過讀取系統(tǒng)信息持久化裝置108獲 得。其中，路由轉(zhuǎn)發(fā)信息記錄了本工作節(jié)點所在的組件可轉(zhuǎn)發(fā)的下游組件集合，數(shù)據(jù)映射信 息記錄了不同數(shù)據(jù)類型匹配的下游組件，這些信息作為公共信息，可供內(nèi)部線程訪問。
[0105] 步驟S502,工作節(jié)點基于公共信息按照既定策略發(fā)送數(shù)據(jù)至下游工作節(jié)點。
[0106] 轉(zhuǎn)發(fā)數(shù)據(jù)時，為了確保下游工作節(jié)點負載均衡，上游工作節(jié)點轉(zhuǎn)發(fā)數(shù)據(jù)時會采取 既定策略從下游正常節(jié)點集合選擇一個節(jié)點，支持的轉(zhuǎn)發(fā)策略包括隨機方式、輪詢方式以 及哈希方式。隨機方式即隨機選擇下游工作節(jié)點；輪詢方式基于Round-Robin法則選擇下游 工作節(jié)點；哈希方式是根據(jù)當前數(shù)據(jù)記錄的哈希值確定工作節(jié)點。工作節(jié)點轉(zhuǎn)發(fā)數(shù)據(jù)后，可 能遇到兩種情況，若發(fā)送成功，則處理下一條數(shù)據(jù)，若得到數(shù)據(jù)發(fā)送失敗的反饋，則轉(zhuǎn)向步 驟S503。
[0107]步驟S503,上游工作節(jié)點標識故障節(jié)點，將其排除于下游正常節(jié)點集合。
[0108] 若下游某個工作節(jié)點發(fā)生故障，上游工作節(jié)點在正常往該故障節(jié)點發(fā)送數(shù)據(jù)時收 到發(fā)送失敗的反饋，獲取下游節(jié)點故障信息。上游節(jié)點將該故障節(jié)點進行特殊標示，在隨后 策略選擇設定的下游正常節(jié)點集合里隔離該節(jié)點。
[0109] 步驟S504,上游工作節(jié)點定期探測下游故障節(jié)點是否恢復運行。
[0110]上游節(jié)點開啟一個線程定期向被隔離的節(jié)點獲取心跳信息，確認其是否恢復工 作。若某一時刻被隔離的節(jié)點向上游節(jié)點反饋心跳，上游節(jié)點則認為該節(jié)點恢復連接，在策 略選擇設定的下游正常節(jié)點集合加入該節(jié)點。
[0111]圖10為本發(fā)明一實施例的步驟S8的數(shù)據(jù)恢復流程示意圖。已知數(shù)據(jù)因網(wǎng)絡傳輸故 障、工作節(jié)點故障等異常而丟失。對于傳輸時丟失的數(shù)據(jù)，本系統(tǒng)引入了數(shù)據(jù)中間結(jié)果持久 化、日志對賬等機制進行精確定位查找并恢復。
[0112] 如圖10所示，具體步驟包括：
[0113] 步驟S801，各個環(huán)節(jié)工作節(jié)點實時地在日志中記錄處理數(shù)據(jù)記錄時的中間結(jié)果。
[0114] 系統(tǒng)內(nèi)部各個工作節(jié)點實時地記錄數(shù)據(jù)處理的中間結(jié)果，按按照分鐘長度切分管 理日志劃分成一個個框架日志，存儲在海量日志管理裝置中。為進一步防止日志數(shù)據(jù)因異 常丟失而無法追回，本系統(tǒng)還對框架日志進行多重備份存儲，詳述見后述圖14的步驟說明。 此外，本發(fā)明設計了一套規(guī)則實時記錄數(shù)據(jù)在組件中的中間結(jié)果。如圖11的工作節(jié)點正常 運行時日志記錄規(guī)則圖所示，本發(fā)明使用了標識H(Head)、S(Sender)、R(Receiver)和T (tail)記錄工作節(jié)點正常處理時數(shù)據(jù)的實時狀態(tài)。
[0115] H表示采集工作節(jié)點計算線程解析二進制流的數(shù)據(jù)記錄時所記錄的日志信息。H日 志信息包括:標識H、數(shù)據(jù)記錄主鍵、所在采集組件ID、所在采集工作節(jié)點ID、轉(zhuǎn)發(fā)到下游的 模型組件ID列表、數(shù)據(jù)記錄內(nèi)容和當前處理時間戳；
[0116] S表示采集工作節(jié)點、模型工作節(jié)點發(fā)送線程轉(zhuǎn)發(fā)數(shù)據(jù)記錄時所記錄的日志信息。 S日志信息包括:標識S、數(shù)據(jù)記錄主鍵、所在節(jié)點ID、轉(zhuǎn)發(fā)到下游的組件ID、數(shù)據(jù)記錄內(nèi)容和 當前處理時間戳；
[0117] R表示模型工作節(jié)點、轉(zhuǎn)發(fā)工作節(jié)點接收線程接收數(shù)據(jù)記錄時所記錄的日志信息。 R日志信息包括:標識R、數(shù)據(jù)記錄主鍵、所在組件ID、所在節(jié)點ID、當前處理時間戳；
[0118] T表示轉(zhuǎn)發(fā)工作節(jié)點發(fā)送線程最后將數(shù)據(jù)記錄轉(zhuǎn)發(fā)到下游應用系統(tǒng)時記錄的日志 信息。T日志信息包括:標識T、數(shù)據(jù)記錄主鍵、所在轉(zhuǎn)發(fā)組件ID、所在轉(zhuǎn)發(fā)工作節(jié)點ID、當前 處理時間戳。
[0119] 需要說明的是，每一條數(shù)據(jù)記錄在流式數(shù)據(jù)拓撲裝置4成功流轉(zhuǎn)后，其生成的日志 記錄中必定各有一條H標識和T標識的日志條目。因此，在后續(xù)日志挖掘分析，只要發(fā)現(xiàn)某數(shù) 據(jù)記錄的H標識和T標識，則可確定該數(shù)據(jù)記錄已經(jīng)成功轉(zhuǎn)發(fā)到下游應用系統(tǒng)。這也是日志 對賬裝置的工作核心之一。
[0120] 此外，組件也會對運行時的一些異常情況進行記錄，如圖12的工作節(jié)點異常運行 時日志記錄規(guī)則圖所示，本發(fā)明使用了異常標識〇R(Overflow Receiver)和0S(0verflow Sender)記錄工作節(jié)點的非正常工作狀態(tài)。已知在工作節(jié)點內(nèi)部，設有接收隊列和發(fā)送隊列 緩存數(shù)據(jù)記錄。如圖4的工作節(jié)點的內(nèi)部示意圖所示，接收線程、計算線程分別會對隊列產(chǎn) 生數(shù)據(jù)寫入的操作。若隊列已滿，繼續(xù)向隊列寫入數(shù)據(jù)則會發(fā)生內(nèi)存溢出。為避免溢出，工 作線程發(fā)現(xiàn)隊列已滿則停止向隊列插入數(shù)據(jù)，直接將數(shù)據(jù)中間結(jié)果狀態(tài)寫入框架日志后不 再處理該數(shù)據(jù)。
[0121] 0R表示工作節(jié)點的接收線程將數(shù)據(jù)寫入接收隊列時發(fā)現(xiàn)接收隊列已滿。0R日志信 息包括:標識0R、數(shù)據(jù)記錄主鍵、所在轉(zhuǎn)發(fā)組件ID、所在轉(zhuǎn)發(fā)工作節(jié)點ID、當前處理時間戳。
[0122] 0S表示工作節(jié)點的計算線程將數(shù)據(jù)寫入發(fā)送隊列時發(fā)現(xiàn)發(fā)送隊列已滿。0R日志信 息包括:標識0S、數(shù)據(jù)記錄主鍵、轉(zhuǎn)發(fā)到下游的組件ID、所在轉(zhuǎn)發(fā)工作節(jié)點ID、當前處理時間 戳。
[0123] 步驟S802,日志對賬裝置周期性地查找丟失的數(shù)據(jù)。
[0124] 本發(fā)明設計的日志規(guī)則詳細記錄了日志的處理狀態(tài)以及中間結(jié)果，根據(jù)每條日志 記錄的標識、組件ID、節(jié)點ID以及時間戳信息，可勾畫出一條數(shù)據(jù)記錄在流式處理拓撲裝置 中的傳輸路徑。對于丟失的數(shù)據(jù)記錄，傳輸路徑在某個工作節(jié)點發(fā)生中斷。為此，本系統(tǒng)引 入了會計對賬的思想，設計日志配對的算法來查找待恢復數(shù)據(jù)內(nèi)容以及組件ID。具體算法 流程在后述圖13實施例中展開，在此不做闡述。日志對賬裝置找到丟失的數(shù)據(jù)后，將丟失時 的數(shù)據(jù)記錄信息轉(zhuǎn)化為文本內(nèi)容，隨丟失時所在組件ID等信息一起寫入系統(tǒng)信息持久化裝 置。
[0125] 進一步的，日志對賬裝置采用了Spark技術實現(xiàn)日志配對算法，Spark作為一種通 用的并行計算框架，基于分布式內(nèi)存并引入了內(nèi)存計算的工作流程，同時具備MapReduce的 計算特性以及快捷的數(shù)據(jù)處理效率。日志對賬裝置找到丟失的數(shù)據(jù)信息后，將丟失的數(shù)據(jù) 記錄內(nèi)容以及丟失的組件ID寫入系統(tǒng)信息持久化裝置中。
[0126] 進一步的，對于在一個時間分鐘批次內(nèi)發(fā)現(xiàn)的丟失數(shù)據(jù)，本日志對賬裝置可設置 為從該時間批次后若干批次(批次數(shù)可預先設置)繼續(xù)查找該丟失數(shù)據(jù)對應的T標識信息， 若能找到，則認為該數(shù)據(jù)沒有丟失，取消數(shù)據(jù)恢復操作;若沒有找到，則轉(zhuǎn)向步驟S803。
[0127] 步驟S803,數(shù)據(jù)恢復單元周期性地恢復丟失的數(shù)據(jù)記錄。
[0128] 數(shù)據(jù)恢復單元定期訪問系統(tǒng)信息持久化裝置，若信息持久化裝置存儲了丟失的數(shù) 據(jù)記錄信息，數(shù)據(jù)恢復單元則對其進行逐條恢復。數(shù)據(jù)恢復單元在進行數(shù)據(jù)恢復時，將丟失 數(shù)據(jù)發(fā)送至丟失時工作節(jié)點所在的組件，由該處繼續(xù)向下發(fā)送，減少數(shù)據(jù)傳輸?shù)慕M件環(huán)節(jié)， 提升效率。具體做法如下:數(shù)據(jù)恢復單元首先獲取數(shù)據(jù)丟失時的所在組件ID，按照既定的策 略(隨機方式、輪詢方式或者哈希方式)選定該組件的工作節(jié)點ID，重新處理待恢復數(shù)據(jù)。根 據(jù)該工作節(jié)點ID，數(shù)據(jù)恢復單元獲取該工作節(jié)點的IP地址和端口。隨后，恢復單元讀取后丟 失時的數(shù)據(jù)內(nèi)容，封裝為消息對象后發(fā)送至目的地工作節(jié)點，同時在框架日志中記錄相關 發(fā)送信息。發(fā)送成功后，數(shù)據(jù)恢復單元刪除該條數(shù)據(jù)記錄在信息持久化裝置中的備份。目的 地工作節(jié)點在接收到該條數(shù)據(jù)后，會按照正常工作的流程將數(shù)據(jù)處理并轉(zhuǎn)發(fā)到下游節(jié)點， 由此丟失數(shù)據(jù)再一次進入流式拓撲裝置4中流轉(zhuǎn)處理。
[0129] 圖13為本發(fā)明一實施例的步驟S802查找并定位丟失數(shù)據(jù)記錄的算法流程圖。如圖 13所示，具體步驟包括：
[0130] 步驟S8021，將框架日志中相同主鍵數(shù)據(jù)記錄的日志信息匯聚一個集合，每個集合 在后續(xù)挖掘中可勾勒出同一主鍵數(shù)據(jù)記錄的轉(zhuǎn)發(fā)路徑，為本次數(shù)據(jù)分析來源。
[0131] 步驟S8022,分析相同主鍵數(shù)據(jù)記錄的日志信息集合，從集合中找到H標識和T標識 的日志信息，檢查數(shù)據(jù)丟失的情況。根據(jù)圖5所示的實施例可知，基于數(shù)據(jù)記錄類型從數(shù)據(jù) 映射表和路由表可獲取數(shù)據(jù)在本系統(tǒng)中的若干條轉(zhuǎn)發(fā)路徑，所有數(shù)據(jù)轉(zhuǎn)發(fā)路徑全集合用 PathSet表示。H日志信息記錄了數(shù)據(jù)在首節(jié)點的處理狀態(tài)，其中包括轉(zhuǎn)發(fā)到下游的模型組 件ID列表，該列表1D個數(shù)即表明轉(zhuǎn)發(fā)路徑的個數(shù)。而每一條轉(zhuǎn)發(fā)路徑對應一條T日志信息。 此時，又分為兩種可能:若列表1D個數(shù)與T日志個數(shù)相等，則認為該主鍵的數(shù)據(jù)記錄在傳輸 過程中全部成功發(fā)送;若不相等，則認為該主鍵的數(shù)據(jù)記錄在傳輸過程中丟數(shù)，需進一步定 位丟數(shù)的路徑和組件位置。
[0132] 步驟S8023,定位丟失的數(shù)據(jù)的在傳輸過程中丟失時的路徑。本步驟采用排除法策 略，假設該數(shù)據(jù)在所有的路徑都發(fā)生丟數(shù)，故障轉(zhuǎn)發(fā)路徑集合中包括所有該條數(shù)據(jù)涉及的 路徑。但若某條路徑的日志中發(fā)現(xiàn)有T日志信息，則說明該路徑其實并未發(fā)生丟數(shù)，則該T日 志對應的路徑從故障轉(zhuǎn)發(fā)路徑集合中排除。具體做法如下：設故障轉(zhuǎn)發(fā)路徑集合 FailedPathSet，初始化時其所包含路徑復制自步驟S8022生成的PathSet。由于數(shù)據(jù)轉(zhuǎn)發(fā)路 徑和T日志為一對一的關系，從T日志中可獲取所在轉(zhuǎn)發(fā)組件的ID，而Fai ledPathSet中出現(xiàn) 該ID的路徑應為成功轉(zhuǎn)發(fā)路徑，于是從FailedPathSet中刪除。利用上述方法，將已知的每 條T日志都進行分析后，F(xiàn)ailedPathSet中剩余的路徑集合皆為故障轉(zhuǎn)發(fā)路徑。
[0133] 步驟S8024,定位丟失的數(shù)據(jù)在故障轉(zhuǎn)發(fā)路徑發(fā)生數(shù)據(jù)丟失時所在組件位置。已知 故障轉(zhuǎn)發(fā)路徑，從框架日志中提取出該路徑組件相關的S或0S標識日志集合，以"轉(zhuǎn)發(fā)組件 4模型組件4…-采集組件"故障轉(zhuǎn)發(fā)路徑的反方向?qū)γ總€組件節(jié)點一一分析，從集合中 找到故障轉(zhuǎn)發(fā)路徑的正方向最后一個出現(xiàn)的組件。所述步驟S8024的目的是定位故障轉(zhuǎn)發(fā) 路徑的第一個故障組件，具體的，首先定位末尾轉(zhuǎn)發(fā)組件的上游模型組件，查看該組件是否 生成了 S或0S日志，若無，則說明該組件為故障組件;繼續(xù)查找該故障組件的上游組件，若該 故障組件的上游組件中找到S或OS日志，查找到此為止，若沒有發(fā)現(xiàn)S或OS日志，則進一步對 上游組件的上游組件按同樣的方法進行查找。以上述方法定位到故障轉(zhuǎn)發(fā)路徑中的最后一 個正常組件，其下游組件即第一個故障組件，也就是所述步驟S803(恢復丟失數(shù)據(jù)步驟）中 丟失數(shù)據(jù)的發(fā)送目的地。最后一個正常組件生成的S或0S日志所含的數(shù)據(jù)記錄內(nèi)容為丟失 數(shù)據(jù)，也就是待恢復的數(shù)據(jù)。
[0134] 圖14為本發(fā)明一實施例的高可用得流式處理系統(tǒng)的日志收集流程圖。由前述實施 例可知，本系統(tǒng)采取一些措施提高日志收集的效用性。為了不影響組件工作節(jié)點的正常工 作，組件工作節(jié)點向日志收集器傳輸非核心日志內(nèi)容時采取異步發(fā)送。進一步地，對于數(shù)據(jù) 異步發(fā)送導致的丟數(shù)情況，可以采取日志多重備份機制，即在多個不同服務器分別部署日 志收集器接收、生成組件工作節(jié)點的日志數(shù)據(jù)，在后續(xù)挖掘前先對多份日志內(nèi)容進行整合 去重，最大程度保證數(shù)據(jù)完整性。本發(fā)明按照分鐘長度切分管理日志，每滿60秒，日志收集 器將當前收集的日志數(shù)據(jù)寫入日志文件。當上一分鐘切換到下一分鐘時，由于不同服務器 本地物理時鐘不一致，不同日志收集器在處理同一條日志記錄時可能將其劃入不同的時間 批次。對此，在后續(xù)多重日志整合時，該條日志記錄出現(xiàn)在多個時間批次中，產(chǎn)生文件內(nèi)容 不一致的問題。
[0135] 為避免上述問題，本發(fā)明在時間批次內(nèi)進一步引入了奇偶隊列進行日志收集管 理，即，將當前的時間分鐘指定為奇或偶屬性，將當前時間生成的框架日志劃分到對應的奇 或偶隊列中。
[0136] 如圖14所示，具體步驟包括：
[0137] 步驟S1401:組件工作節(jié)點產(chǎn)生框架日志記錄時，將日志內(nèi)容和奇、偶標識分別發(fā) 送至兩個日志收集器。
[0138] 組件工作節(jié)點生成日志記錄內(nèi)容時，獲取當前框架統(tǒng)一時鐘，由該分鐘數(shù)的奇偶 性可判定日志記錄的奇偶性，并為該日志記錄用奇偶標識進行標記。組件工作節(jié)點在發(fā)送 日志記錄內(nèi)容的同時，發(fā)送該日志記錄的奇偶標識。日志收集器接收日志時，對核心日志和 非核心日志的收集會有一定的區(qū)別。所述核心日志記錄為H日志，H日志記錄表明該數(shù)據(jù)記 錄已經(jīng)進入流式拓撲裝置，采取同步方式記錄，工作節(jié)點需確保日志收集器接收并發(fā)送反 饋后繼續(xù)接下來的操作，此等待過程會耗費額外工作時間。所述非核心日志為除H日志外的 其余日志，為異步處理機制，即組件工作節(jié)點無需等待日志收集器的接收反饋，繼續(xù)進行下 一步的工作。
[0139]步驟S1402:日志收集器根據(jù)日志記錄的奇偶標識將其放入對應隊列。
[0140]由步驟S1401可知，工作節(jié)點記錄時已確定日志記錄的奇偶性。當日志收集器收到 日志記錄時，讀取該條日志記錄的奇偶標識，將其放入對應奇偶性的隊列中緩存。每個日志 收集器內(nèi)部維護著一個奇隊列和一個偶隊列，正常工作時，這兩個隊列一個為當前時間批 次"活動隊列"，用于接收當前時間批次的日志記錄，另一個為"停滯隊列"，用于將該隊列內(nèi) 部上一時間批次的日志記錄數(shù)據(jù)寫入框架日志中。日志收集器本地物理時間每滿60秒，日 志收集器將奇隊列、偶隊列的"活動"、"停滯"狀態(tài)進行切換。
[0141] 步驟S1403:設置緩沖時間，待當前時間切換一段時間后，日志收集器將隊列數(shù)據(jù) 寫入框架日志文件。
[0142] 在本系統(tǒng)中設置了4秒的緩沖時間，用于等待上一時間批次發(fā)送的日志記錄?？赡?存在一種情況是，上一時間批次最后幾秒內(nèi)，工作節(jié)點已經(jīng)發(fā)送了日志記錄數(shù)據(jù)，由于網(wǎng)絡 延遲等情況，待日志收集器收到時活動隊列已經(jīng)切換為另一隊列。該條日志記錄對應的隊 列已經(jīng)轉(zhuǎn)為停滯隊列，開始將隊列內(nèi)數(shù)據(jù)寫入該批次對應的框架日志。為此，日志收集器設 置了 4秒時長用于停滯隊列等待對應批次"遲到"的日志記錄。因此在每個切換時間的頭4秒 內(nèi)，停滯隊列接收遲到日志記錄的同時，活動隊列用于接收當前批次正常到達的日志記錄。 4秒后，日志收集器開始將停滯隊列數(shù)據(jù)寫入框架日志文件。
[0143] 綜上所述，利用奇偶隊列可保證同一條日志記錄出現(xiàn)在同一時間批次的多重備份 的日志文件中。已知經(jīng)上述方法獲得多份日志文件，每份日志文件記錄的在理想狀態(tài)下記 錄的是相同的內(nèi)容，但難以避免因網(wǎng)絡故障等情況出現(xiàn)部分日志數(shù)據(jù)在收集過程中發(fā)生丟 失的意外。因此，對多份日志內(nèi)容進行收集整合去重，最大程度保證數(shù)據(jù)完整性。
[0144] 進一步的，為了保證工作節(jié)點所部署的服務器集群的時鐘一致性，本系統(tǒng)中采用 創(chuàng)新的框架統(tǒng)一時鐘。具體的，由上文可知，在流式處理拓撲裝置中，一條數(shù)據(jù)記錄通過不 同的組件工作節(jié)點后，每個節(jié)點記錄時間戳，用于事后判斷數(shù)據(jù)丟失情況。因集群服務器的 本地物理時鐘無法保證絕對統(tǒng)一，有可能發(fā)生同一條數(shù)據(jù)記錄的H標識日志記錄出現(xiàn)時間 晚于T標識日志記錄。若服務器之間的物理時鐘誤差超過上述緩沖時間，同一條數(shù)據(jù)記錄的 T標識日志因"出現(xiàn)"時間早，被劃分入上一時間批次的日志文件，而同一條數(shù)據(jù)記錄的H標 識日志被劃分入下一個時間批次，由于日志劃分不準確可導致后續(xù)查找丟失數(shù)據(jù)不準確。 本發(fā)明提出一種用于通信網(wǎng)絡中的時鐘近似同步于物理時鐘的方法，在本系統(tǒng)中稱之為框 架統(tǒng)一時鐘。該方法包括：
[0145] 第一步，第一個工作節(jié)點在處理一條數(shù)據(jù)記錄的首尾分別記下本地服務器物理時 間tl、t2,獲得時間偏移量(Tl = t2-tl)，由此先確定兩個框架時鐘分別是tl、tl+Tl。
[0146] 第二步，第二個工作節(jié)點在處理同一條數(shù)據(jù)記錄的首尾分別記下本地服務器物理 時間t3、t4，獲得時間偏移量(T2 = t4-t3)，假設數(shù)據(jù)從第一個工作節(jié)點傳輸?shù)降诙€節(jié)點 花費的時間為〇,則第二個節(jié)點獲得的兩個框架時鐘分別是tl+Tl，tl+Tl+T2。
[0147] 以此類推，后一個節(jié)點獲得的框架時鐘總是晚于前一個節(jié)點。不論服務器本地物 理時鐘是否有誤差，采用框架同一時鐘可近似同步物理時鐘。在日志文件中記錄的時間戳 即為框架時鐘。
[0148] 本發(fā)明提出的一種高可用的流式處理系統(tǒng)及方法，可以應用于高性能數(shù)據(jù)處理平 臺，能在秒級水平對上游應用系統(tǒng)生成的數(shù)據(jù)進行處理，并采取多種措施提高系統(tǒng)的穩(wěn)定 性。具體包括以下優(yōu)點：
[0149] 1、本系統(tǒng)及方法將基礎框架模塊與具體業(yè)務邏輯模塊進行松耦合設計，可同時支 持多個高速實時的數(shù)據(jù)分析處理場景，對復雜多樣的業(yè)務模型提供堅實的底層支持，保證 數(shù)據(jù)得到快速有效的處理。
[0150] 2、本系統(tǒng)及方法提出的日志對賬方法可保障上游應用系統(tǒng)產(chǎn)生的每一條數(shù)據(jù)得 到處理，對于因異常丟失的數(shù)據(jù)，精確定位到具體位置和業(yè)務模型。
[0151] 3、本系統(tǒng)及方法對分布式集群的工作節(jié)點進行實時監(jiān)控，對發(fā)生故障的節(jié)點及時 響應并迅速恢復，確保系統(tǒng)持續(xù)對外正常服務。
[0152] 以上所述的具體實施例，對本發(fā)明的目的、技術方案和有益效果進行了進一步詳 細說明，所應理解的是，以上所述僅為本發(fā)明的具體實施例而已，并不用于限定本發(fā)明的保 護范圍，凡在本發(fā)明的精神和原則之內(nèi)，所做的任何修改、等同替換、改進等，均應包含在本 發(fā)明的保護范圍之內(nèi)。
【主權項】
1. 一種高可用的流式處理系統(tǒng)，其特征在于，該系統(tǒng)包括： 上游應用系統(tǒng)，用于根據(jù)上游業(yè)務應用的進程，實時產(chǎn)生原始數(shù)據(jù)，逐條發(fā)送至接收裝 置； 接收裝置，用于將原始數(shù)據(jù)轉(zhuǎn)發(fā)至消息中間件裝置的消息隊列； 消息中間件裝置，用于以消息隊列的形式為流式處理拓撲裝置緩存數(shù)據(jù)； 流式處理拓撲裝置，用于處理原始數(shù)據(jù)的數(shù)據(jù)流，生成數(shù)據(jù)結(jié)果； 下游應用系統(tǒng)，對應業(yè)務場景，用于根據(jù)對數(shù)據(jù)結(jié)果進行后續(xù)處理。2. 根據(jù)權利要求1所述的高可用的流式處理系統(tǒng)，其特征在于，所述流式處理拓撲裝置 包括:采集組件、模型組件、轉(zhuǎn)發(fā)組件，每個組件對應多個工作節(jié)點;其中， 所述采集組件，用于從所述消息中間件裝置的消息隊列中讀取上游應用系統(tǒng)的原始數(shù) 據(jù)記錄，將原始數(shù)據(jù)轉(zhuǎn)化為內(nèi)部組件的工作節(jié)點能操作的MessageOb ject消息對象格式，根 據(jù)路由表設定將轉(zhuǎn)化后的數(shù)據(jù)轉(zhuǎn)發(fā)給下游的模型組件； 模型組件，一條數(shù)據(jù)處理鏈路中串行存在一個或多個模型組件，每個模型組件用于將 轉(zhuǎn)化后的數(shù)據(jù)按上層應用系統(tǒng)指定的業(yè)務邏輯進行處理，生成數(shù)據(jù)結(jié)果，轉(zhuǎn)發(fā)至下游模型 組件或轉(zhuǎn)發(fā)組件，如果一條數(shù)據(jù)處理鏈路有多個模型組件，則按序依次對轉(zhuǎn)化后的數(shù)據(jù)進 行處理； 轉(zhuǎn)發(fā)組件，用于將數(shù)據(jù)結(jié)果轉(zhuǎn)發(fā)至對應的下游應用系統(tǒng)。3. 根據(jù)權利要求2所述的高可用的流式處理系統(tǒng)，其特征在于，該系統(tǒng)還包括： 心跳探測裝置，用于周期性的接收來自流式處理拓撲裝置的工作節(jié)點的心跳信息，將 已發(fā)送心跳的工作節(jié)點列表轉(zhuǎn)發(fā)至系統(tǒng)守衛(wèi)裝置； 系統(tǒng)守衛(wèi)裝置，用于接收心跳探測裝置的發(fā)送的列表信息，監(jiān)控流式處理拓撲裝置的 運行狀況;還用于重啟故障工作節(jié)點，恢復其正常工作;還用于以細粒度模式恢復系統(tǒng)運行 中丟失的數(shù)據(jù)。4. 根據(jù)權利要求3所述的高可用的流式處理系統(tǒng)，其特征在于，該系統(tǒng)還包括： 系統(tǒng)信息持久化裝置，用于管理維護系統(tǒng)中的相關組件和工作節(jié)點的信息，以及記錄 各個工作節(jié)點的運行狀態(tài)，以及緩存待恢復的數(shù)據(jù)記錄。5. 根據(jù)權利要求4所述的高可用的流式處理系統(tǒng)，其特征在于，該系統(tǒng)還包括： 海量日志管理裝置，用于收集、存儲框架日志，供后續(xù)挖掘使用； 日志對賬裝置，用于找到在處理過程中丟失的數(shù)據(jù)記錄，通過基于對賬機制的挖掘算 法，定期讀取海量日志管理裝置中框架日志，最終將將丟失的數(shù)據(jù)記錄信息寫入系統(tǒng)信息 持久化裝置用于恢復處理。6. 根據(jù)權利要求4所述的高可用的流式處理系統(tǒng)，其特征在于，所述系統(tǒng)守衛(wèi)裝置包括 監(jiān)控管理單元、故障恢復單元、數(shù)據(jù)恢復單元;其中， 監(jiān)控管理單元，用于監(jiān)測系統(tǒng)中各個組件的工作節(jié)點的運行狀態(tài)，周期性地接收來自 心跳探測裝置的消息，消息內(nèi)容包括在本周期內(nèi)已成功發(fā)送心跳的工作節(jié)點列表，監(jiān)控管 理單元將該工作節(jié)點列表寫入系統(tǒng)信息持久化裝置中； 故障恢復單元，用于周期性地將系統(tǒng)信息持久化裝置中記錄的成功發(fā)送心跳的工作節(jié) 點列表與流式處理拓撲裝置的全體工作節(jié)點進行比對，尋找沒有發(fā)送心跳的工作節(jié)點，對 于預設的時間區(qū)間內(nèi)沒有及時發(fā)送心跳的工作節(jié)點，故障恢復單元判斷該工作節(jié)點發(fā)生故 障，將故障工作節(jié)點信息寫入系統(tǒng)信息持久化裝置，并從系統(tǒng)信息持久化裝置中找到該故 障節(jié)點的服務器IP端口信息和配置信息，在目的地服務器進行遠程重啟； 數(shù)據(jù)恢復單元，用于定期從系統(tǒng)信息持久化裝置中讀取系統(tǒng)運行過程中丟失的數(shù)據(jù)記 錄，并進行逐條細粒度恢復。7. 根據(jù)權利要求6所述的高可用的流式處理系統(tǒng)，其特征在于，所述數(shù)據(jù)恢復單元，用 于讀取系統(tǒng)信息持久化裝置中數(shù)據(jù)丟失時的組件ID，并按既定策略確定數(shù)據(jù)重新發(fā)送給該 組件的某個工作節(jié)點ID，找到該工作節(jié)點的服務器IP和端口； 當所述數(shù)據(jù)恢復單元讀取到丟失的數(shù)據(jù)記錄，將其由文本重新封裝成消息對象，根據(jù) 發(fā)送目的地服務器IP和端口重新發(fā)送至流式處理拓撲裝置的對應組件工作節(jié)點。8. -種高可用的流式處理方法，其特征在于，該方法包括： 步驟Sl，上游應用系統(tǒng)實時產(chǎn)生原始數(shù)據(jù)，逐條發(fā)送至接收裝置； 步驟S2,接收裝置將原始數(shù)據(jù)轉(zhuǎn)發(fā)至消息中間件裝置的消息隊列，消息中間件裝置以 消息隊列的形式為流式處理拓撲裝置緩存數(shù)據(jù)； 步驟S3,流式處理拓撲裝置啟動，采集組件、模型組件、轉(zhuǎn)發(fā)組件的工作節(jié)點進行初始 化工作，在內(nèi)存中加載工作組件轉(zhuǎn)發(fā)路由信息和數(shù)據(jù)映射信息公共數(shù)據(jù)； 步驟S4,心跳探測裝置、系統(tǒng)守衛(wèi)裝置進行實時保衛(wèi)系統(tǒng)正常運行，心跳探測裝置監(jiān)控 系統(tǒng)所有工作節(jié)點，當系統(tǒng)守衛(wèi)裝置監(jiān)測到工作節(jié)點發(fā)生故障，進行遠程重啟； 步驟S5,流式處理拓撲裝置的采集組件從消息中間件裝置的消息隊列中讀取并處理原 始數(shù)據(jù)轉(zhuǎn)變?yōu)橄ο?，在流式處理拓撲裝置中根據(jù)工作組件轉(zhuǎn)發(fā)路由信息和數(shù)據(jù)映射信 息傳遞至下游的一個或多個模型組件； 步驟S6,每條數(shù)據(jù)處理鏈路分支的模型組件以上層應用系統(tǒng)指定的業(yè)務邏輯對數(shù)據(jù)記 錄進行處理，根據(jù)工作組件轉(zhuǎn)發(fā)路由信息和數(shù)據(jù)映射信息轉(zhuǎn)發(fā)至下游模型組件或轉(zhuǎn)發(fā)組 件;每條數(shù)據(jù)處理鏈路分支存在一個或多個模型組件，最后一個模型組件將數(shù)據(jù)轉(zhuǎn)發(fā)到轉(zhuǎn) 發(fā)組件； 步驟S7，轉(zhuǎn)發(fā)組件將數(shù)據(jù)轉(zhuǎn)發(fā)到下游應用系統(tǒng)； 在步驟S5、S6、S7中所有組件的工作節(jié)點會實時地在工作日志中記錄當前的處理狀態(tài)， 用于后續(xù)數(shù)據(jù)恢復組件查找丟失的數(shù)據(jù)記錄； 步驟S8,日志對賬裝置定期查找在步驟S5、S6、S7中轉(zhuǎn)發(fā)失敗的數(shù)據(jù)記錄信息，由系統(tǒng) 守衛(wèi)裝置進行數(shù)據(jù)記錄恢復發(fā)送。9. 根據(jù)權利要求8所述的高可用的流式處理方法，其特征在于，在步驟S4中，還包括： 步驟S401，流式處理拓撲裝置的工作節(jié)點在正常工作時，定期向心跳探測裝置發(fā)送心 跳，心跳探測裝置定期將已收到心跳的工作節(jié)點收集成列表，轉(zhuǎn)發(fā)至監(jiān)控管理單元； 步驟S402,監(jiān)控管理單元收集成功發(fā)送心跳的工作節(jié)點列表，將該工作節(jié)點列表寫入 系統(tǒng)信息持久化裝置中； 步驟S403,故障恢復單元查找故障節(jié)點，并遠程重啟故障節(jié)點。10. 根據(jù)權利要求9所述的高可用的流式處理方法，其特征在于，在步驟S403中，還包 括:故障恢復單元將系統(tǒng)信息持久化裝置中記錄的成功發(fā)送心跳的工作節(jié)點列表與全體工 作節(jié)點進行比對，尋找沒有發(fā)送心跳的工作節(jié)點，對于預設的時間區(qū)間內(nèi)沒有及時發(fā)送心 跳的工作節(jié)點，故障恢復單元判斷該工作節(jié)點發(fā)生故障； 故障恢復單元將故障工作節(jié)點信息寫入系統(tǒng)信息持久化裝置，并從系統(tǒng)信息持久化裝 置中找到該故障節(jié)點的服務器IP端口信息和配置信息，采用SSH協(xié)議在目的地服務器進行 遠程重啟。11. 根據(jù)權利要求9所述的高可用的流式處理方法，其特征在于，在步驟S8中，還包括： 步驟S801，各個環(huán)節(jié)工作節(jié)點實時地在日志中記錄處理數(shù)據(jù)記錄時的中間結(jié)果； 步驟S802，日志對賬裝置周期性地查找丟失的數(shù)據(jù)； 步驟S803,數(shù)據(jù)恢復單元周期性地恢復丟失的數(shù)據(jù)記錄。12. 根據(jù)權利要求11所述的高可用的流式處理方法，其特征在于，在步驟S802中，還包 括： 步驟S8021，將框架日志中相同主鍵數(shù)據(jù)記錄的日志信息匯聚一個集合； 步驟S8022,分析相同主鍵數(shù)據(jù)記錄的日志信息集合，從集合中找到H標識和T標識的日 志信息，檢查數(shù)據(jù)丟失的情況； 步驟S8023，定位丟失的數(shù)據(jù)的在傳輸過程中丟失時的路徑； 步驟S8024，定位丟失的數(shù)據(jù)在故障轉(zhuǎn)發(fā)路徑發(fā)生數(shù)據(jù)丟失時所在組件位置。
【文檔編號】H04L12/24GK105959151SQ201610458184
【公開日】2016年9月21日
【申請日】2016年6月22日
【發(fā)明人】袁, 袁一, 沈贇, 陶瑋, 張學舟
【申請人】中國工商銀行股份有限公司