[發明專利]數據文件寫入方法及系統、數據文件讀取方法及系統

有效

• 申請號: 201310484997.8
• 申請日: 2013-10-16
• 公開（公告）號: CN103605479A
• 公開（公告）日: 2014-02-26
• 發明（設計）人: 代兵;朱超;王超
• 申請（專利權）人: 北京奇虎科技有限公司;奇智軟件（北京）有限公司
• 主分類號: G06F3/06
• 分類號: G06F3/06
• 代理公司: 北京鼎佳達知識產權代理事務所(普通合伙) 11348
• 代理人: 王偉鋒;劉鐵生

技術領域

本發明涉及計算機數據處理領域，具體涉及一種數據文件寫入方法及系統、數據文件讀取方法及系統。

背景技術

在計算機系統中，例如存儲系統，經常出現多個進程讀寫數據文件的場景。例如一個進程按照一定協議格式將數據寫到一個文件中，然后另一個進程讀取這個文件，并按這個協議格式解析這個文件的內容。

在絕大部分情況下，這樣做沒有問題。但如果計算機意外宕機，導致進程在寫某個數據時，只寫了一半而終止，就會導致數據文件損壞，讀取進程按照之前約定的協議進行解析其內容就會出現問題，從而導致后面所有的數據都無法讀取。

例如，在一個消息隊列系統中，有這樣一個異步發送消息的功能。消息生產者（producer）發送消息時，調用異步發送接口來發送，異步發送接口直接將消息寫到本地文件中，形成消息文件。同時，消息生產者所在的機器會啟動一個守護進程，實時讀取這個消息文件，將里面的內容轉發給服務端（broker），架構圖如圖1所示。

消息生產者寫消息文件格式為：依次將每條消息追加到文件尾部，每條消息包含4個字節的消息長度，后面跟上消息內容（消息內容的長度與4個字長的消息長度一致）。當消息生產者發送了3條消息后，消息文件格式如圖2所示，3條消息中的內容分別為長度68字節的消息內容1、長度20字節的消息內容2和長度53字節的消息內容3。

如果在消息生產者發送第三條消息時，消息內容3只寫了一半，機器就突然宕機，那么數據寫入就不完整。當機器啟動后，如果消息生產者繼續發送消息，那么發送完第四條消息后，消息文件的格式如圖3所示。

因為消息內容3不完整，當寫入第四條消息后，另外的進程讀取這個文件內容然后進行解析時，會誤將第四條消息的一部分當作第三條消息的內容，然后第四條消息的4個字節的頭部（消息長度）也會不準確，也進而導致后面的內容都將無法正確解析。

為防止出現前文所說的問題，有一種解決辦法是增加一個索引文件，索引文件中指明每條消息的在消息文件中的起始位置，以及消息長度。每次消息生產者發送消息時，先從索引文件中查詢當前消息應該寫入的位置，然后更新消息文件，最后再更新索引文件。

相應地，讀進程每次從讀取消息時，先查詢索引文件中的消息位置以及長度，然后再定位到消息文件相應的位置進行查詢。

如果在更新消息文件時突然宕機，那么索引文件就不會得到更新，從而這條消息對讀取進程是不可見的，也就不會引起消息文件的錯亂了。

采用索引文件的方案存在的缺陷在于：

1、增加了復雜性。

因為讀、寫進程都需要同時涉及兩個文件的操作，這樣比較麻煩。寫進程每次要先讀索引文件，再寫數據文件，再繼續更新索引文件……；讀進程需要先讀索引文件，然后讀數據文件，再繼續讀取索引文件……。

2、降低了性能。

因為同時操作兩個文件，這樣對性能有一定損失。一是讀寫的內容比以前多了，二是涉及到多個文件的讀寫時，就不是嚴格的順序讀寫磁盤，對性能也有一定影響。

所以，本發明需要解決的技術問題在于，當數據文件的部分數據損壞后，如何完成對整個文件的未損壞數據的正確讀取，且讀寫數據文件的過程不涉及到數據文件外的其他文件，以減少不必要的復雜度和性能損耗。

發明內容

鑒于上述問題，提出了本發明以便提供一種克服上述問題或者至少部分地解決上述問題的數據文件寫入方法及系統、數據文件讀取方法及系統。

依據本發明的一個方面，提供了一種數據文件寫入方法，用于將待寫數據寫入數據文件中，其包括：取得一條或多條待寫數據；設置第一字符串；將每條待寫數據作為一個單元，并在每個單元中加入第一字符串，且第一字符串位于每個單元的前端，用于標識每個單元；將每個單元寫入數據文件中。

可選地，設置第一字符串的步驟包括：從一條或多條待寫數據中提取出多個字符組成第一字符串。

可選地，多個字符為一條或多條待寫數據中出現概率最低的多個字符。

可選地，在將每個單元寫入數據文件中的步驟之前，還包括：設置一個或多個第二字符串，以分別表示一條或多條待寫數據的長度；在每個單元中加入一個第二字符串，且第二字符串連接在每個單元中的第一字符串與待寫數據之間，用于表示每個單元中的待寫數據的長度。