1. 程式人生 > >分散式站點資料同步機制的設計與實現[出自別處]

分散式站點資料同步機制的設計與實現[出自別處]

摘要:在網際網路蓬勃發展的今天,把集團公司下的各個水電站的資料同步起來,統一管理的需求日益突顯。本公司首先採用了oracle公司自身提供的解決方案高階複製技術,但限於本國網速緩慢網路時常斷線的不穩定的狀態的特殊國情,實施效果不盡如人意。針對我國苛刻的網路條件,本公司努力研發,自主地設計了一套低網速資料同步系統比較妥當地解決了資料同步的相關問題,取得了較好的經濟效益與社會效益。

正文: 水電的集團公司為了提高公司的資訊化水平,為了能夠及時獲得準確的施工與生產的相關資訊,為公司的科學決策提供依據,決定統一管理集團旗下的各個水電站的資料。具體任務則交給了本公司來具體實施。實施的結果得到了業主和終端使用者的認可,並認為該技術與經驗值得普及與推廣。
  下面針對低網速資料同步系統的開發,簡要介紹一下;
一問題分析。
在與業主充分地溝通,調研了業主的實際業務需求之後,結合目前的網路現狀,經過了與業主的多次的討論與確認,雙方一致確認一天同步一次為妥。確保公司總部能夠了解到前一天各電站的施工或者是生產現狀。需要解決的主要的技術問題有如下幾個:
1。如實地,一絲不苟地記錄每個電站的一天內資料的增加,修改,刪除等改變的資訊。
2。各電站的資料都是由兩部分組成的。包括系統資料和業務資料。系統資料是各個電站共同使用的資料,業務資料是由各個電站單獨使用。需要解決的是各個電站同一天內修改了相同的系統資料的衝突問題。
3。如何把大量的日誌資訊,精確無誤地從各個電站站點傳輸到公司總部的中心站點,因為網速很慢及網路不穩定的現狀,這一問題成為系統成敗的關鍵所在。
4。在同步執行進,遇到了無法解決的衝突時,如何處理,如何提示系統的實施人員來處理問題。

二系統設計

針對上述問題,低網速資料同步系統可以劃分為相互關聯,又彼此比較獨立的五個子系統。它們是日誌記錄子系統,衝突解決的配置子系統,日誌上傳子系統,同步執行子系統,同步排程子系統。下面逐一介紹各個子系統。

1。日誌記錄子系統

在業務系統執行時,由該子系統自動地記錄資料庫的資料的改變的日誌資訊。在一天結束時,與資料庫自身的日誌記錄進行對比,驗證。如果驗證通過,則接下來的任務,由上傳子系統來完成。如果沒有通過驗證,則通過資料庫現有的狀態與昨天的此時的資料庫的快照狀態進行計算糾錯。

2。衝突解決的配置子系統

該子系統會產生資料量很大的,十分詳盡的配置項,結果以XML格式的檔案的形式儲存在中心站點供同步執行子系統查詢和應用。

3。日誌上傳的子系統。
在日誌上傳前先壓縮,上傳後解壓縮,採用FTP協議上傳並配置上斷點續傳的功能,解壓縮後,進行MD5的計算與驗證保證檔案上傳前後的檔案完整性與一致性。該檔案供同步執行子系統使用。

4。同步執行子系統。

該子系統在中心站點重現各電站子站點一天以來的各種資料庫的操作。有了衝突,則讀取配置檔案中的配置項,按照預選配置好的衝突解決策略,進行處理衝突,如以某個站點的資料為準。以最新的操作時間的為準,以令牌環的方式哪個電站持有鎖則以哪個電站的資料修改為有效。對於衝突的解決情況及未能找到適合的配置項而不能處理的情況,一律記錄下來,以郵件的形式發給系統的實施人員進行分析及後續的處理。

5。同步排程的子系統。

由該子系統來總體控制同步的程序。

三系統實現

公司對該系統的開發十分重視,從各個部門抽調了技術骨幹力量組成了專案開發小組,其中專案經理一人,系統分析師二人,系統構架師一人,程式設計師十人,測試員三人,實施員二人,文員一人。

該系統歷時半年的開發上線。試運行了三個月,解決了一些技術問題後,通過了初驗,又穩定地運行了半年後,系統通過了終審驗收。

該系統的實現涉及的技術複雜而且廣泛,如JAVA程式設計技術,oracle資料庫的管理技術,FTP協議等網路技術,壓縮與解壓縮等數學演算法技術等,在公司領導的親切關懷與正確領導下,在專案組全體成員的共同努力下,在相關部門的密切地協作與配合下,在業主的大力支援下,最終取得了令人比較滿意的成果。

作者:gggwfn1982
來源:CSDN
原文:https://blog.csdn.net/gggwfn1982/article/details/81675509