IBM 數(shù)據(jù)庫復制產(chǎn)品 Infosphere Replication Server 中的多向 SQL 復制既能捕獲源表也能捕獲目標表的數(shù)據(jù)變化，因此能很好地保持數(shù)據(jù)在各方的一致。
但數(shù)據(jù)沖突的現(xiàn)象仍是無法完全杜絕。因此我們需要盡可能地改進方案，以期接近完美效果。本文在這樣的背景下，介紹了 ibm 相關產(chǎn)品 infosphere replication server 和 infosphere federation server 通過合作提出的一個基于 cache table 的數(shù)據(jù)復制方案。
計算機、網(wǎng)絡、傳感技術(shù)等各項信息技術(shù)的發(fā)展，使得我們生活的環(huán)境變成了今天這個由數(shù)據(jù)統(tǒng)治的世界，每天都有大量紛繁復雜的數(shù)據(jù)、信息充斥耳邊。據(jù)稱現(xiàn)在只需兩天就能創(chuàng)造出自文明誕生以來到 2003 年所產(chǎn)生的數(shù)據(jù)總量。而企業(yè)數(shù)據(jù)也以 55% 的速率逐年增長。這些大量的交易數(shù)據(jù)、交互數(shù)據(jù)中并不是 100% 都是有意義的，但我們又不得不去接收它們。這是因為數(shù)據(jù)當中隱含著有價值的信息，并且這些信息都是有時效的，需要及時進行整合、分析、再創(chuàng)造，然后才能更好地與用戶交互，實現(xiàn)在合適的時間、通過合適的途徑、銷售合適的產(chǎn)品，最終實現(xiàn)企業(yè)利潤增長。數(shù)據(jù)復制產(chǎn)品正是這一數(shù)據(jù)處理過程中最關鍵的一環(huán)，它能夠?qū)⒔邮盏降臄?shù)據(jù)分發(fā)到各個場所，用于及時整合數(shù)據(jù)，產(chǎn)生實時報表，或者為實時統(tǒng)計提供輸入。
數(shù)據(jù)集中 / 分發(fā)經(jīng)典場景
對于集團型企業(yè)，例如銀行、電信、保險等，通常包含多個子系統(tǒng)，每個系統(tǒng)對應一項或多項業(yè)務，而業(yè)務終端也往往部署在各個省市地區(qū)。某個地區(qū)的某個子系統(tǒng)里數(shù)據(jù)在一定時間內(nèi)只能代表該地區(qū)的業(yè)務特征。因此，業(yè)務的廣泛性和區(qū)域性使得企業(yè)不能對內(nèi)部的數(shù)據(jù)進行全盤規(guī)劃和統(tǒng)一，這大大影響了企業(yè)對業(yè)務的分析決策。具體影響有：
- 關鍵數(shù)據(jù)不唯一，集團無法判斷數(shù)據(jù)的準確性，需要花費更多的人工和資源驗證并糾正數(shù)據(jù)，因此不能對分公司或子公司的數(shù)據(jù)進行及時分析，從而進行全盤分析和規(guī)劃；
- 分公司或子公司間數(shù)據(jù)無交互或交互較少，各自為政，數(shù)據(jù)無共享，造成各分公司或子公司間不能有效借鑒或沿用有價值或有代表性的決策和方案，集團范圍內(nèi)數(shù)據(jù)管理困難，數(shù)據(jù)丟失的風險性較高。
沒有統(tǒng)一的關鍵數(shù)據(jù)管理會造成集團范圍內(nèi)不能實時監(jiān)控并及時分配關鍵資源，不能及時獲取各地數(shù)據(jù)掌握全局趨勢，也往往會造成決策失誤。這些問題嚴重的話會造成企業(yè)無法彌補的損失。因此企業(yè)通常會建立數(shù)據(jù)中心、部署一套數(shù)據(jù)集中 / 分發(fā)方案以保證各地各項業(yè)務數(shù)據(jù)的統(tǒng)一。典型場景如圖 1 所示，在集團所在地或附近建立中心，在各分公司或子公司部署分級。中心服務器與分級服務器間通過網(wǎng)絡實時通信，分發(fā)或集中數(shù)據(jù)。各分級服務期間根據(jù)需要也可進行通信。
圖 1. 數(shù)據(jù)集中 / 分發(fā)場景
數(shù)據(jù)集中 / 分發(fā)對數(shù)據(jù)沖突和負載均衡的要求
數(shù)據(jù)的集中和分發(fā)根據(jù)實際情況要求和設計考慮的角度的不同，具體實現(xiàn)起來方案有很多。有些由中心服務器承擔主要業(yè)務輸入，有些反之，有些根據(jù)具體情況不同，對不同的業(yè)務指定不同的主承受服務器。但究其本質(zhì)是如何保證事務的原子性和數(shù)據(jù)在各個副本中的一致性。這方面從技術(shù)發(fā)展歷程來看，早期主要通過兩階段提交協(xié)議實現(xiàn)原子性，通過兩階段鎖或時間戳模型實現(xiàn)副本的一致性。這種模式即為通常所說的同步復制過程，涉及到各副本與提交事務的節(jié)點間的互相確認過程，因此具有一定的性能影響。后來為提高吞吐率，縮短響應時間，對一致性級別進行了放松，出現(xiàn)了異步復制，面對不同的目的，出現(xiàn)了不同的異步復制協(xié)議。目前企業(yè)中使用的復制產(chǎn)品大多為異步復制。這種方案不能像同步復制那樣實現(xiàn)完全實時復制，必然會出現(xiàn)一定的延時，雖然這種延時通過各種技術(shù)手段可以控制在秒級，甚至更小，但對于在每個副本都能操作數(shù)據(jù)的系統(tǒng)中，還是有可能出現(xiàn)數(shù)據(jù)沖突。
數(shù)據(jù)沖突簡單地說，是因為某一行數(shù)據(jù)在不同地點被不同的應用同時進行了修改。這種修改具體表現(xiàn)有插入、更新、刪除。舉例來說，有表（列 1，列 2，列 3），其中列 1 是表的主鍵，該表同時部署在兩地的 Server A 和 Server B 中。最普遍的沖突情況是，A 和 B 同時有應用對該表插入了具有相關關鍵字的數(shù)據(jù)，該事務在本地服務器上能執(zhí)行成功，但當數(shù)據(jù)變化傳遞到對方時，會發(fā)現(xiàn)以這個關鍵字值標記的行已存在，沖突發(fā)生；另一種普遍的沖突是，A 和 B 同時修改了相同關鍵字行的非關鍵字列，這樣當變化傳遞到對方時，沖突發(fā)生。無論具體沖突是什么情況，在異步復制中都無法完全避免，因此在設計方案時必須要有在發(fā)生數(shù)據(jù)沖突時，一些有效的沖突解決方案，這樣才能最終保證數(shù)據(jù)的一致。
由于業(yè)務的多樣性，由單個服務器承受所有的業(yè)務具有很高的風險性，當出現(xiàn)斷電等意外，或者更大的自然災害時，損失是無法挽回的。因此設計數(shù)據(jù)集中 / 分發(fā)方案時需要考慮如何實現(xiàn)負載均衡。從全局來看，需要合理分配各項業(yè)務的連接；從具體業(yè)務來看，需要合理均衡讀連接和寫連接，特別對于具有大用戶量的業(yè)務，用戶對系統(tǒng)響應一般都具有較高的期望，用戶量也往往跟系統(tǒng)響應時間負相關，而受限于服務器以及數(shù)據(jù)庫系統(tǒng)的處理能力，單個表是很難滿足大量同時的讀寫連接的。
多向 SQL 復制實現(xiàn)數(shù)據(jù)集中 / 分發(fā)
IBM InfoSphere Replication Server 產(chǎn)品中的 SQL 復制框架最早可以追溯到 1994 年 IBM DB2 發(fā)布的 DataPropagator Relational（DPropR）的第一個版本。因此，相較于 2004 年推出的 Q 復制框架，SQL 復制功能的客戶基礎較深厚，事實證明它在實現(xiàn)數(shù)據(jù)集中 / 分發(fā)方面具有較好的優(yōu)勢和穩(wěn)定性。本節(jié)將帶領讀者簡單回顧一下多向 SQL 復制的實現(xiàn)。
