基于Sync Framework的礦用防爆手機數據同步技術研究與應用

李 明 建

(瓦斯災害監控與應急技術國家重點實驗室　重慶 400037)(中煤科工集團重慶研究院有限公司　重慶 400037)

0　引　言

隨著煤礦信息化、自動化水平的提高，特別是煤礦井下無線通信系統的推廣應用，以智能手機為核心的礦用防爆手機在井下數據采集領域得到迅猛發展。當前，礦用防爆手機的硬件技術已經比較成熟，基于礦用防爆手機開發的應用程序因其具體應用場景不同而在功能需求上千差萬別，但都面臨一個共性問題：防爆手機應用程序怎么與部署于地面的安全監控系統、業務管理系統進行數據交換，既能在井下查詢地面存儲管理的已有信息，也能在井下采集上傳新信息。研發適用于以偶爾連接為特征的礦用防爆手機數據同步組件，降低專業應用程序開發技術難度、減少開發工作量，因而具有較高的工程研究和應用價值。

基于防爆手機的數據同步組件，至少應滿足兩個基本要求：適應偶爾連接的網絡環境；適應受限本機硬件資源環境。筆者所在單位研發的瓦斯災害監控預警系統(以下簡稱監控預警系統)中多類信息通過礦用防爆手機采集。監控預警系統以安全監控系統提供的在線監測信息、檢測裝備測定的離線檢測信息、防爆手機在井下采集的日常預測及觀測信息為基礎，以預警指標和預警模型為核心，計算分析井下特定區域瓦斯災害危險度，進而實現瓦斯災害超前預警[1]。其中基于防爆手機的各類應用程序，一般設計為偶爾連接網絡，因為在煤礦井下采掘工作面很少能有無線信號覆蓋，僅在主要大巷、變電所、井底車場等位置可以連接到井下通信環網，進而訪問位于地面的監控預警服務器。近年來隨著無線通信技術的飛速發展，防爆手機雖然在存儲、計算、網絡帶寬及系統可靠性等方面有了長足的發展，但與臺式電腦、筆記本甚至普通智能手機相比，仍然有較大的差距。同時由于防爆檢測、安標檢測費用較高、周期較長，防爆手機一旦定型后硬件升級改進成本較高，導致其硬件配置水平遠低于主流普通智能手機，因此在設計基于防爆手機的數據同步組件時，必須充分考慮其存儲能力、計算能力、網絡傳輸速率等關鍵指標。

1　數據同步概述

1.1　數據同步原理及方法

數據同步在理論上比較簡單: 它是在適當時間在兩個或更多參與者之間復制正確的數據集的過程[1]。但在軟件實現過程中仍然存在眾多技術難點，特別是分布式異構數據同步場景，包括：集成不同類型的數據；與能力不盡相同或者要求數據的不同子集的參與者合作；適應不可靠網絡等。數據同步首先需要解決數據變化捕獲問題，目前常用的數據變化捕獲有快照法、觸發器法、日志法、API法、影子表法、時間戳法、變更軌跡法。這些變化捕獲方法雖各有優點，但都有一定的局限性[2]。

分布式數據庫是利用計算機網絡、分布式計算、同步技術等將物理上分散的多個數據庫連接起來組成一個邏輯上統一的數據庫。其基本特點包括：物理分散性、邏輯整體性、節點自治性、數據透明性等[3]。當前實現分布式異構數據庫同步的方法主要有三種：(1) 內置同步法，使用數據庫內置同步功能，部署簡單，可靠性高，但一般不支持不同類型和不同版本數據庫之間的同步，不能二次開發，個性化定制需求難以實現；(2) 中心同步法，中心數據庫存儲所有分布數據庫的數據總和，各分布數據庫通過中心數據庫中轉同步，但中心數據庫龐大，邏輯復雜，效率較低；(3) 對等同步法，任意數據庫之間是對等關系，通過使用SOAP、XML或者一些成熟的數據同步框架進行數據交互，實現異構數據庫之間同步[4]。本文重點研究偶爾連接環境下防爆手機與地面SQL Server數據同步，采用基于數據同步框架的中心同步法是合適的。

1.2　典型數據同步框架

(1) SyncML(Synchronization Markup Language)是一種基于XML、平臺無關的數據同步協議，最早由SyncML initiative發布，后來該組織融入到開放移動聯盟OMA(Open Mobile Alliance)，成為其下設的數據同步工作組(Data Synchronization Working Group)，繼續負責SyncML數據同步的標準化工作。2011年OMA發布OMA Data Synchronization V2.0標準。

(2) Microsoft Sync Framework(微軟同步框架，簡稱Sync Framework)是微軟公司研發的數據同步組件，用于SQL Server與SQL Server、SQL Server Express、SQL Server Compact、SQLite等數據庫同步，并可以開發自定義數據同步提供程序，以IIS或Windows 應用程序為宿主，通過數據同步服務接口與其他數據源進行同步。Sync Framework具有結構合理、配置靈活、適應能力強、可擴展性好、持續技術支持等特點，現已成為SQL Server內置數據同步組件的核心，得到廣泛應用。

Sync Framework可擴展性強，具有良好的程序接口，且可選擇使用二進制方式傳輸同步消息，傳輸效率較使用XML方式的SyncML高，通過ADO.NET可快速擴展至Windows客戶端SQLite、SQL Server Express與SQL Server數據同步，符合監控預警數據同步擴展需求，因此本文基于Sync Framework研發Android防爆手機數據同步組件。

2　數據同步框架簡介

2.1　SQL Server數據同步

微軟公司為以SQL Server為中心的數據同步提供了多種方案，如快照復制、合并復制、事務復制、對等事務復制[5]。其中適用于數據庫與數據庫間雙向同步的有兩種：(1) SQL Server對等事務復制同步，要求參與方必須為SQL Server企業版，而標準版、商業智能版及Web版均不具備此功能，同時要求參與方必須位于固定網絡環境，不適用于公網上一臺服務器與一臺運行于內網的不可尋址的服務器間數據庫同步；(2) SQL Server合并復制同步，對服務器端SQL Server版本沒有限制，客戶端也可以是SQL Server、SQL Server Compact，但對于Android這樣的非SQL Server客戶端則必須借助微軟公司開發的Sync Framework才能實現數據同步。

礦用防爆手機一般使用開源的Android操作系統，在此基礎上開發的數據采集應用程序普遍使用SQLite數據庫，且數據結構與SQL Server主數據庫也可能不盡相同。以不同平臺、不同結構為特征的異構數據庫同步，對具有較強計算能力、固定網絡環境的服務器而言不是問題，但對于計算及存儲能力有限、偶爾連接網絡且使用Android系統的防爆手機來說，確實是一個挑戰。

SQL Server自2008版本開始，引入了兩種變更數據捕獲方案：更改跟蹤CT(Change Tracking)和變更數據捕獲CDC(Changing Data Capture)。這兩種方案均不需要修改用戶表結構、自定義觸發器，也不需要增加影子表，即可記錄用戶對數據表的所有更改。雖然更改跟蹤只能記錄刪除行的主鍵而不是備份刪除行，但與變更數據捕獲相比，更改跟蹤并不限于SQL Server企業版，并能與Sync Framework結合，開發自定義同步提供程序，可以更高效地實現數據同步[6]。

2.2　Sync Framework實現原理與部署方式

Sync Framework最新版本為2.1，它既可以同步以SQL Server為中心的數據庫、同步文件系統，也可以自定義同步提供者實現非SQL Server數據庫間的數據同步，還可以通過Web數據服務方式實現Windows平臺Web數據同步。但上述同步模式需要服務器端和客戶端均有同步框架相應版本組件的支持，這對于Windows電腦客戶端甚至基于Windows Phone的智能手機來說是可行的，但對于當前占主流的Android、IOS操作系統移動設備來說，則因缺少相應同步客戶端組件支持而變得困難。為了解決Android、IOS系統客戶端的跨平臺數據同步問題，微軟公司在Sync Framework基礎上，研發了用以支持非對稱同步交換的Sync Framework Toolkit 4.0，將所有同步處理邏輯移至服務器端，客戶端通過簡單的HTTP調用即可實現數據同步。

Sync Framework數據同步實現過程為：首先由數據接收方發起同步會話請求，并建立起網絡連接；數據提供方接收到會話請求后，查找自身副本所儲存的元數據，然后將元數據傳送給數據接收方；數據接收方對比本地元數據和提供方元數據，確定需要更新的數據，并將其發送到數據提供方；提供方收到需要更新的數據后，將對應元數據信息發送給數據接收方進行比較是否有數據沖突；經沖突檢測后，數據接收方正式請求接收更新數據，數據提供方接收請求并發送數據至接收端，接收端接收到數據并更新至數據庫，從而完成同步會話[8]。

從部署角度來說，Sync Framework支持脫機模式和協作模式，如圖1所示。中心同步方案：在客戶端-服務器拓撲中，多個客戶端連接到一個中心服務器，以便在連接可用時同步數據。對等同步方案：多個數據庫可以通過對等方式進行同步，而無需通過中心服務器，前提條件是所有參與方必須處于固定網絡環境。

圖1　Sync Framework兩種部署模式

3　數據同步設計與實現

3.1　數據同步總體方案

監控預警系統由多個子系統組成，其中防突動態管理是其中采集離線數據較多的子系統。防突動態管理子系統主要通過防爆手機采集防突工作面執行防突措施、局部預測、效果檢驗過程中所能人工觀測、儀器測量的各種信息，在井下或地面有WIFI信號時與監控預警服務器進行數據同步；同時防突動態管理電腦客戶端也會修改數據庫信息，例如：防突工作面基礎信息、區域措施效果檢驗信息、局部措施設計信息等。因此防爆手機上的防突信息采集數據庫與服務器數據庫間存在雙向同步的需求。

根據上述業務場景分析，防突動態信息數據同步總體方案如下：在服務器端數據庫中，啟用SQL Server 2012的更改跟蹤以記錄服務器數據更改；在防爆手機SQLite數據庫中，使用觸發器及影子表記錄客戶端所有數據更改，在網絡可用時通過無線基站發起同步請求；同步服務器端使用WCF開發數據同步服務，接收來自防突信息采集App的數據同步請求，并與服務器端數據庫進行同步，返回防突信息采集App。數據同步總體流程如圖2所示。

圖2　防爆手機數據同步總體流程圖

3.2　服務器端變更數據捕獲方案

根據前面對SQL Server更改跟蹤和變更數據捕獲兩種技術比較，結合瓦斯災害監控預警系統中離線數據采集環境特征，本文選用更改跟蹤來記錄SQL Ser-ver主數據庫的增量數據更改。雖然更改跟蹤只能記錄哪些數據行已被修改，而不能記錄修改過程軌跡，但對于防爆手機這樣的偶爾連接參與者的同步要求已經足夠。對用戶表啟用更改跟蹤主要腳本如下：首先對數據庫啟用更改跟蹤；其次對需要同步的數據表，啟用更改跟蹤；在需要查詢更改行時，使用更改跟蹤函數獲取更改。

現以防突動態信息數據庫OIMSJMYM2015及其中的工作面信息表MOBI_WorkFace為例(其結構如表1所示)說明使用更改跟蹤獲取變更數據的過程。

表1　MOBI_WorkFace表結構

(1) 啟動并配置更改跟蹤

?對數據庫啟用更改跟蹤，開啟自動清理，數據保存期為兩天。

ALTER DATABASE OIMSJMYM2015 SET CHANGE_TRACKING = ON

(AUTO_CLEANUP = ON, CHANGE_RETENTION = 2 DAYS);

?對表啟用更改跟蹤，跟蹤列更新。

USE OIMSJMYM2015;

ALTER TABLE dbo. MOBI_WorkFace ENABLE CHANGE_TRACKING

WITH (TRACK_COLUMNS_UPDATED = ON);

(2) 獲取變更數據行

?通過SQL Server內置的CHANGETABLE函數獲取更改數據記錄表，從中查詢本表自上次同步以來的所有更改數據行。

DECLARE @last_sync_version BIGINT;

SET @last_sync_version = CHANGE_TRACKING_MIN_VALID_VERSION (OBJECT_ID (′dbo.MOBI_WorkFace′));

SELECT CT.UID,WF.FaceName,WF.FaceType,

CHANGE_TRACKING_IS_COLUMN_IN_MASK (

COLUMNPROPERTY (OBJECT_ID (′dbo.MOBI_WorkFace′),′FaceName′,′ColumnId′),

CT.SYS_CHANGE_COLUMNS

) AS NameIsChanged,

CHANGE_TRACKING_IS_COLUMN_IN_MASK (

COLUMNPROPERTY (OBJECT_ID (′dbo.MOBI_WorkFace′),′FaceType′,′ColumnId′),

CT.SYS_CHANGE_COLUMNS

) AS TypeIsChanged,

CT.SYS_CHANGE_VERSION,

CT.SYS_CHANGE_OPERATION,

CT.SYS_CHANGE_COLUMNS

FROM dbo.MOBI_WorkFace AS WF, CHANGETABLE (CHANGES dbo.MOBI_WorkFace, @last_sync_version) AS CT

WHERE WF.UID = CT.UID

上述SQL語句運行結果如圖3所示，其中：NameIsChanged記錄源表FaceName字段是否更新；TypeIsChanged記錄源表FaceType字段是否更新；SYS_CHANGE_VERSION記錄操作版本號；SYS_CHANGE_OPERATION有三種取值: I、U、D，對應的DML操作為INSERT、UPDATE和DELETE；SYS_CHANGE_COLUMNS為受UPDATE操作影響的字段編碼[9]。

圖3　MOBI_WorkFace更改行查詢結果

3.3　防爆手機端SQLite變更數據捕獲方案

SQLite是基于C語言開發的輕量級進程內嵌入式數據庫引擎，完全遵守ACID準則，具有開源免費、單一文件、零配置、資源占用率低、可移植性好、開發接口豐富等特點[10]。自2000年發布以來，在各類嵌入式設備中得到廣泛應用，現已發布SQLite 3版本。適用于SQLite數據庫的更改跟蹤方法有“觸發器+控制表”法和附加API法捕獲待提交事務，但后者實現均在應用程序內部，導致數據庫可移植性差，且無法捕獲不經過應用程序執行的數據更改，因此本文采用“觸發器+控制表”法捕獲SQLite數據更改，具體實現如下：

(1) 在SQLite數據庫新建一張ScopeInfoTable表，用以記錄同步域名稱、同步服務地址、最后同步時間以及需要同步的用戶表名稱。

(2) 為每張需要同步的用戶表創建三個觸發器，分別在After Insert、After Delete、After Update時點記錄對用戶表的所有更改操作，并保存于與用戶表對應的更改控制表中。但更改控制表并非記錄更改數據行的所有字段，而僅記錄更改數據行的主鍵、更改操作類型、最后修改時間等信息，其結構如表2所示。

表2　SQLite更改控制表結構

3.4　防爆手機端與服務器交換更改數據

防爆手機端與服務器交換更改數據有兩種模式。第一種慢同步方案：首先在同步服務器生成SQLite數據庫構架，后續同步過程中，通過Web Service傳遞更改數據集、通過Web Service傳遞壓縮后的SQLite數據庫(壓縮率可達90%以上，同時SQLite數據庫存儲密度非常高)至服務器執行同步，再將同步后的數據庫下載至防爆手機端覆蓋工作數據庫，從而實現同步。第二種增量同步方案：初始化SQLite數據庫構架在服務器端，防爆手機端從服務器下載數據庫以后，在同步時直接通過HTTP請求，以OData的JSON格式上傳更新、下載更新、協調沖突。第一種方案可以簡單有效對應質量較差的網絡環境，但同步效率有待不高，而第二種方案雖然實現復雜，但僅上傳下載增量數據，在地面局域網環境下可以提高同步效率。

考慮井下通過無線基站接入通信環網穩定性較差、SQLite數據庫存儲密度較高等因素，本文采用第一種慢同步方案，在完成SQLite數據庫初次下載以后，一次同步分為三個步驟：壓縮并通過Web Service上傳SQLite數據庫、在同步服務器上執行SQLite數據庫與SQL Server數據庫同步、下載SQLite數據庫并解壓還原至工作數據庫位置。同步服務器根據SQL Server主數據庫的同步配置，創建SQLite數據庫構架的流程如圖4所示。

圖4　同步服務器初始化SQLite數據庫構架流程

3.5　同步提供者及同步服務程序實現

Sync Framework同步框架自動生成對象關系模型實現需要同步數據表到實體類的映射，并由一個實體管理類KJEPOIMSDB_OfflineEntities進行整合，實體管理類以屬性字段方式記錄需要同步的數據表實體類。用戶自定義的數據同步服務類KJEPOIMSDB_SyncService 派生于抽象類Microsoft.Synchronization.Services.SyncService，并以實體管理類KJEPOIMSDB_OfflineEntities作為泛型模板參數，從而實現同步實體類的注入，并以靜態方法InitializeService初始化數據同步服務。在同步過程中通過OData生成REST風格Http響應，格式既可以選用JSON，也可以選用Atom。基于慢同步方案的防爆手機端App數據同步過程如圖5所示。其中初始化同步服務的主要代碼如下：

// 設置數據庫連接字符串，設置數據庫同步域及同步對象

//所有者

config.ServerConnectionString = ConfigurationManager.ConnectionStrings[″OIMSConn″].ConnectionString;

config.SetEnableScope(″DefaultScope″);

config.SetSyncObjectSchema(″dbo″);

// 設置沖突解決策略，是否允許跟蹤

config.SetConflictResolutionPolicy(ConflictResolutionPolicy.ServerWins);

config.EnableDiagnosticPage = true;

// 設置同步序列化格式為JSON，同步過程中批量下載最

//大為2M

config.SetDefaultSyncSerializationFormat(

SyncSerializationFormat.ODataJson);

config.SetDownloadBatchSize(20 * 2048);

圖5　防突信息采集App數據同步實驗效果圖

4　現場應用

河南能化集團焦煤演馬莊礦使用鉆孔瓦斯涌出初速度q，鉆屑量S作為防突日常預測指標，并輔以噴孔、頂鉆、夾鉆等現場觀測信息。上述日常預測、觀測信息由防突技術員在井下工作面通過防爆手機錄入；執行突出危險性預測后，將防爆手機攜帶至采區變電所附近，通過其內的WIFI無線通信基站接入井下通信環網，執行防突信息采集App的數據同步，將日常預測和觀測信息上傳至地面的防突信息采集工作站，進入運行于監控預警服務器上的防突動態信息數據庫；運行于局域網上的防突動態信息管理系統讀取加載上述信息，生成日常預測表單，打印后供相關技術領導簽字存檔。

根據2015年4月演馬莊礦現場實驗，對防突信息采集App增量同步模式和慢同步模式進行了對比分析(數據見表3實驗中初始化構架階段使用的原始數據庫為635 KB，GZip壓縮后為72 KB)。結論如下：在初始化構架階段均采用GZip壓縮技術，下載數據量相同，因此不存在顯著效率差異；在后續同步階段，慢同步模式仍然可以采用GZip壓縮技術，雖然每次同步均需要將整個數據庫壓縮后上傳下載，在數據量增長受限前提下(同步服務器端在生成防爆手機端數據庫時，可過濾過期數據)，數據同步耗時比增量同步模式增加16.3%，但同步處理速度比增量同步模式高93.2%，分析原因得益于大粒度事務傳輸，開銷較低。演馬莊礦現場試實驗防突信息采集App運行效果如圖5所示。

5　結　語

本文基于Sync Framework設計開發了適用于Android防爆手機的數據同步組件，實現防突信息采集App與地面防突動態信息數據庫按需同步，與傳統直接編程實現數據上傳下載方式相比，具有以下優勢：首先，SQLite數據庫由同步服務器根據SQL Server主數據庫的同步配置自動生成，簡化了SQLite數據表輔助字段、輔助表設計和維護工作量；其次，本方案與直接編碼實現上傳下載方式相比，數據同步事務粒度更大，具有受網絡質量影響小、網絡異常后處理代價低等特點；最后，本方案將數據同步組件與業務數據庫解耦，實現數據同步組件復用，降低業務軟件開發工作量，符合軟件工程思想，可以推廣至基于防爆手機乃至普通Android手機數據采集App與SQL Server數據同步領域，具有比較廣泛的工程應用前景。當然，本文采用的慢同步方案會隨著SQLite數據庫容量增大而同步效率降低，如何提高同步效率尚有待進一步研究。

[1] 寧小亮. 煤與瓦斯突出災害監控預警技術[J]. 中國安全生產, 2016(9): 50-51.

[2] 者敬. 開放式異構數據庫復制框架的研究與實現[D].北京:中國科學院軟件研究所,2002:19-23.

[3] 申德榮,于戈. 分布式數據庫系統原理與應用[M].北京:機械工業出版社,2011.

[4] 林源，陳志泊. 分布式異構數據庫系統的研究與應用[J]. 計算機工程與設計，2010，31( 24) 5278-5281.

[5] SQL Server Replication [EB/OL]. Microsoft MSDN library,2011 [2011-02-11]. https://msdn.microsoft.com/zh-cn/library/ms151198(v=sql.110).aspx#.

[6] Tracking Data Changes [EB/OL]. Microsoft MSDN library,2016 [2016-08-26].https://msdn.microsoft.com/en-us/library/bb933994.aspx#.

[7] 王麗君,李萌,徐卓然,等. 變化數據捕獲研究及基于SQL SERVER的開發與應用[J]. 南華大學學報(自然科學版), 2011, 25(3): 78-82.

[8] 陳什,耿浩,朱巖. 基于MSF的數據庫同步技術在監控系統中的應用[J]. 微計算機應用, 2011, 32(8): 57-61.

[9] CHANGETABLE [EB/OL]. Microsoft MSDN library, 2016 [2016-08-26]. https://msdn.microsoft.com/en-us/library/bb934145.aspx#.

[10] About SQLite [EB/OL]. SQLite Home, [2016-12-20]. https://www.sqlite.org/about.html.