[發明專利]一種跨進程的數據采集處理方法

有效

• 申請號: 201811072813.6
• 申請日: 2018-09-14
• 公開（公告）號: CN109359005B
• 公開（公告）日: 2022-04-19
• 發明（設計）人: 涂高元;邱志斌;郭永興;陸云燕;時宜
• 申請（專利權）人: 廈門天銳科技股份有限公司
• 主分類號: G06F11/30
• 分類號: G06F11/30;G06F9/54
• 代理公司: 暫無信息
• 代理人: 暫無信息

本發明公開一種跨進程的數據采集處理方法，用于實現數據采集進程與數據處理進程之間數據的存儲；數據采集進程與數據處理進程共享磁盤存儲，方法包括如下步驟：將數據采集進程輸出的數據保存于共享磁盤的文件夾中，若輸出的數據大小高于限值，則分為多個任務內容文件進行保存，所有文件的路徑和文件名信息均根據時間先后記錄在待處理任務列表文件todo.list中；將待處理任務列表文件todo.list改名為doing.list，數據采集進程繼續輸出的任務內容文件，記錄在新的待處理任務列表文件todo.list中；數據處理進程逐行處理任務列表doing.list對應的文件，并在處理完畢后刪除該對應的文件。此種方法既可保障數據的可靠存儲轉移使用，同時也避免了數據庫復雜數據存儲方式和索引建立的性能丟失。

技術領域

本發明涉及一種跨進程的數據采集處理方法。

背景技術

在軟件開發中，出于模塊化目的，不但常常將一個應用程序分解為多個靜態庫/動態庫模塊，有時也會基于穩定性和多實例運行的考慮，將一個應用軟件拆解為多個應用程序模塊，采用多進程協作運行的方式實現特定的軟件功能。

對于32位進程而言，將一個軟件拆解為多個進程，可以更加充分地應用64位操作系統的內存資源；對于一個軟件中較為復雜、不夠穩定的部分代碼，拆解獨立為一個進程，再加上進程故障守護重啟機制，可以有效避免不穩定的功能代碼引起的進程崩潰問題影響其他進程中關鍵代碼的運行。

總而言之，軟件采用多進程協作運行的方式設計是一個非常自然的設計。但是，引入的一個新問題是，多進程設計的軟件中，一個進程往往以另一個進程的輸出作為輸入，這對進程間數據處理任務的轉交、傳遞提出了要求。

在主流操作系統中，兩個進程之間交換較多的數據，較為常用的兩個方法，一是共享內存，二是管道。由于基于計算機的內存完成進程間數據傳遞，性能較高，因此，這在大部分場合下，是極佳的選擇。

上面提到的共享內存或者管道技術，用于兩個進程間傳遞數據，在大部分場合下，是極佳的選擇。但在一些特殊的場合下，也存在失效的問題。

假設有兩個進程，進程A和進程B，進程A位于前端收集原始數據，并做預處理，將預處理后的數據遞交給進程B；進程B位于后端，專門用于對進程A傳遞而來的數據進行更為復雜的后續處理。

由于進程B主要負責對進程A預處理過的數據進行更復雜的后續處理，那么意味著進程B涉及的算法代碼通常更加復雜，也更加容易出錯和不穩定，同時復雜的處理也基本意味著對單筆數據處理的時間周期也更長。

上面的分析，主要說明進程B相對于進程A而言不穩定異常退出的概率更大，并且處理數據的效率更低，進程A可能在某些高峰時期以1000次/每秒的速率采集和預處理數據，進程B則有可能以最快10次/每秒的速率進行復雜處理。帶來的問題是，進程B內可能會堆積大量的待處理數據在內存中，在大量內存數據未處理完畢的時候，如果進程B故障崩潰，將會發生大量的數據丟失。

考慮到上述復雜處理的耗時性以及可能的不穩定性，如果要實現可靠的數據處理，必須考慮引入磁盤存儲。如果進程A將預處理后的數據，直接寫入磁盤文件中，那么進程B將可以按自己的處理性能逐個處理，而不必擔心進程A有突發大量的預處理數據任務推送導致在短時間內發生大量的內存資源占用。

總而言之，不引入磁盤存儲，僅僅基于內存進行跨進程的數據任務傳遞，將會面臨兩個威脅：一是大量的內存資源占用；二是，關鍵處理進程的崩潰將會引起大量的數據丟失。

對于在多個進程之間共享的磁盤存儲，有一個潛在的可能選項，是類似MSSQLServer、Oracle、MySQL這樣的關系數據庫。從功能角度而言，是可行的，但是關系數據庫的主要優勢在于提供二維平面化數據的索引查詢，其復雜的數據存儲格式和索引功能，在單純實現先進先出任務隊列的功能需求下，顯得多余且性能低下，往往難以達到理想的速度性能。