系統架構師論文-論分布式數據庫的集成
2022-03-06 18:09:01

論分布式數據庫的集成

[摘要]

本文討論了某公司發貨系統的分布式數據庫集成解決方案。該公司由于業務的發展，要在另三個城市設立貨倉進行發貨。為此，需要増加原先的MIS系統實現這一功能。公司委任我作為項目經理完成系統的設計和開發的工作。我經過分析，使用了 Sybase的分布式數據庫技術。我設計的這個系統是采用典型的C/S結構，但客戶端連接服務器的網絡采用電話線撥號，速度有限，傳統Windows界面的客戶端應用程序相應速度比較慢。于是我采用了優化數

據庫結構的方法，把數據分兩部份存放，基礎數據放客戶機，銷售資料主要采用鍵碼放服務器，應用程序再現數據時從服務器取鍵碼，到客戶機取対應的解釋。由于鍵碼的數據量少，網絡傳輸便快。在構建這個公布式數據庫系統的過程中，我著重研究并解決了數據同歩和事務協調的問題，到得了良好的應用效果。

[正文]

2004年3月，由于公司業務的發展，要求在其它三個城市設立貨倉，處理發貨業務。公司本部運行用Sybase數據庫的MIS系統可以實現發貨，該系統用的是C/S結構。由于客戶端連接服務器的網絡采用電話撥導，所以直接把客戶端軟件直接安裝在外地訪問本部數據庫,速度很慢。于是，公司成立了一個項目，專門解決這個問題。在這個項目中，我擔任項目經理。經過対現有系統的分析，我們決定利用Sybase提供的技術，采用分布式數據庫集成的方

法來改造目前的系統使之能適應新的需要。項目分三個階段進行，一是進行需求分析，確定要増加的功能。二是進行系統設計，改變后數據分布如何，系統架構如何。最后是實現和測試，上線。整個項目歷時從分析到實現歷時三個月，最后于2004年6月份系統成功上線。

在分析階段時我發現由于客戶端地域的分散，遍及三個省境內，連接服務器數據庫的網絡采用電話撥導方式，速度有限，在使用客戶端應用程序時感覺界面速度很慢。我經過分析,認識到許多操作都要從服務器中取數據，速度慢就慢在數據訪問上。服務器是沒有瓶頸的，問題出在網絡速度上。出于成本和業務重方面的考慮，公司不會用專線連接，只能是電話撥號。這時只能改變目前軟件的實現方法，來適應這種低速網絡的使用模式。

經和項目組的人員一起探討，結合關系數據庫的知識，我認識到，應用程序的每一次數據庫操作，都要訪問多個相聯的表，其中，有銷售訂單表和物料基礎數據表唇戶資料表/貨倉的基礎數據等。銷售訂單表中存放著出銷售的訂單編號，成品編號等，數據量少。而基礎數據表就則放著成品的相關信息，有大量的數據。如果考慮把銷售訂單放在服務器，基礎數據放在客戶端，當應用程序中訪問數據時，總是從服務器上存取銷售訂單，從客戶端提取成

品/訂單的詳細信息。由于訂單的數據量少，便減少了網絡上傳送的數據量，從而提高了界面的響應速度。

把數據分散存放只是工作的第一歩，接下來要考慮應用程序怎樣訪問這種分布式數據。開發應用時，如果每一功能都針対兩個數據庫進行，就帶來了很多麻煩。所以，我通過研究Sybase的分布式數據庫技術，決定采用CIS （組件集成服務）部件，來合并兩個數據庫成一個統一的分布式數據庫。應用程序只要連接一個數據庫，就可以透明統一訪問到兩個數據庫中的數據。

該技術具體實施方法是：在客戶端數據庫中建立一個対服務器數據庫的遠程訪問服務名，包含訪問地址，登錄用戶名，登錄密碼等關鍵的連接信息；前且対服務器中銷售訂單建立一個本地代理表。結構和服務器中遠程表完全一樣，它是訪問服務器中會員資料的中轉和代理?？蛻舳藨贸绦蛟L問本地代理銷售資料表時，實際上是通過預先定義的遠程訪問服務名中包含的連接信息到服務器中対應的實際銷售資料表中訪問數據。這種訪問対于客戶端完全透明，感覺不到是從物理上獨立的兩個服務器中存服數據。所以，這種數據庫結構是典型的分布式數據庫。部署這種分布式數據庫不是難事，只要在客戶端和服務器上安裝12.0版本以上的數據庫服務器，在客戶端服務器上建立遠程服務名和代理表即可。由于Sybase數據庫的安裝支持腳本方式，在客戶端應用程序的標準安裝過程中，嵌入Sybase數據庫的安裝和配置腳本，就自動化地完成了所有工作。

在實際使用該分布式數據庫系統的過程中，遇到了幾個問題，第一，數據同歩?？蛻舳嘶A數據不是絕対靜態的，也有變化，因此在服務器要設貫一個統一的基準，稱為主點數據?？蛻舳丝偸且獜椭剖褂?，稱為復制點數據。如何及時感知到服務器端主點數據的變化，有效率地復制到客戶端，是個難題。Sybase針対這種應用場合，提供了復制服務器技術，但為了避免過于復雜，我們采用實際應用程序來管理同歩。當服務器端主點數據有了更改時，保存一個相應的標識和時間戳，客戶端應用在登錄服務器時，檢資這些標識，一檢測到了數據有更新，就首先下載,然后再進入系統正常使用。這種方法實現起來，増加了額外的開發量，且不能判別繞過應用程序対數據的直接修改，但是，是最簡單和有效的方法。

第二個問題是事務協調問題。物理上獨立的兩個數據庫，在協同操作時，如果服務器正好停機或者網絡故障，完整的一個事務沒能完成，就會事務崩潰,雖然Sybase CIS內嵌了兩階段提交技術，能夠自動恢復。但是應用程序在這種情況下，敏感性不夠，操作界面會無端凝固，影響了使用的方便性。我針対PB対勁于連接的判斷和感知，用了一個小小編程技巧，使應用程序能夠及時感知到數據庫連接故障，及時停止和恢復事務，使操作界面表現友好靈活。

在具體的應用中,我們在三個城市安裝了増強的客戶端應用程序，同時安裝了 Sybase數據庫。初始化時，把基礎數據放從公司本部的數據庫導入客戶端的數據庫中。用戶在外地進行發貨時，先撥號上網，然后啟動客戶端程序。在登錄過程中，客戶端程序會檢查服務器上的標識和時間戳檢查這些主數據是否有更新，如果有就先下載，下載完成后再進入系統正常使用。在服務器更新的數據比較多的情況下，下載的時間會比較長，這時如果遇到急需發貨,則會影響到貨物不能及時發出去。為了解決這個問題，我設置了在每天凌晨的某個時刻自動登錄和啟動客戶端程序，在下載更新數據完成后自動關閉。這樣可以把一部份數據更新的內容放在非工作時間里完成，減少了發貨登錄的時間。用戶登錄后開始進行發貨操作。輸入銷售訂單，通過本地代理表系統自動到服務器獲取該銷售訂單的數據，如發貨的數量，客戶編號等。而一些基礎數據則可以直接從本地的數據庫中得到，如銷售產品的描述，客戶的地址/電話/傳真，發貨的庫位等。完成出貨動作后，會自動更新服務器的庫存。而這一更新通過提交事務在后臺進行，不影響前臺的操作。所以，対用戶來講，能夠進行正常的操作，不會因為速度慢而進行不下去。

在當今的信息社會里，互聯網帶來了相互連通的方便，而且知識爆炸，數據的分布式訪問是個必然的趨勢。目前新起的XML技術，提供了各種平臺數據庫之間的一個公共數據訪問標準，可以用來構建更加靈活，適應性更強的分布數據庫技術。將XML用在分布式數據庫中，將是未來的一個趨勢。