第一篇：分布式OA系統(tǒng)的數(shù)據(jù)庫同步復(fù)制技術(shù)

分布式OA系統(tǒng)的數(shù)據(jù)庫同步復(fù)制技術(shù)

一、背景概述

隨著政府上網(wǎng)、電子政務(wù)的不斷普及和深入，IBM公司的Lotus Domino系統(tǒng)在國內(nèi)得到廣泛的應(yīng)用。其中不乏大型的、跨地域的企事業(yè)單位或集團公司應(yīng)用案例。這些案例一般采用分布式系統(tǒng)結(jié)構(gòu)，即分布在全國各地的分支機構(gòu)分別設(shè)有獨立的數(shù)據(jù)庫服務(wù)器，各地數(shù)據(jù)庫服務(wù)器采用數(shù)據(jù)庫同步復(fù)制的方式更新本地數(shù)據(jù)庫復(fù)本內(nèi)容。從而使得各地終端用戶及時、快捷、可靠地訪問到最新公告、新聞等。

本文結(jié)合呼和浩特鐵路局客運公司辦公自動化系統(tǒng)案例討論基于IBM公司的Lotus Domino技術(shù)構(gòu)建的分布式OA系統(tǒng)中數(shù)據(jù)庫之間的同步復(fù)制技術(shù)。

二、幾個概念

IBM公司的Lotus產(chǎn)品包含Lotus Domino Server，Lotus Notes，Lotus Domino Administrator和Lotus Domino Designer。Lotus Domino Server為后臺數(shù)據(jù)庫平臺，Lotus Notes為客戶端，Lotus Domino Administrator為系統(tǒng)管理平臺，Lotus Domino Designer設(shè)計開發(fā)工具。先介紹幾個Domino中和同步復(fù)制有關(guān)的概念。

1、復(fù)制

Notes允許在多個服務(wù)器或工作站上保存數(shù)據(jù)庫的多個拷貝，這些拷貝稱做“復(fù)本”。它們使各個地方的不同網(wǎng)絡(luò)上的用戶共享相同的信息。復(fù)本與文件的拷貝不同之處在于在復(fù)制時源文件與其復(fù)本具有相同的復(fù)本標識符。

復(fù)制是在復(fù)本之間共享更改信息的過程。復(fù)制時，Notes通過把更改信息從一個復(fù)本拷貝到另一個復(fù)本來更新復(fù)本。最終，Notes 使所有復(fù)本保持一致?？梢赃x擇在復(fù)本拷貝之間進行復(fù)制，這時兩個復(fù)本都發(fā)送并接收更新信息，或者選擇僅從一個復(fù)本復(fù)制到另一個復(fù)本。

也可以定期安排復(fù)制，或者根據(jù)需要手動進行復(fù)制。復(fù)制可以在兩臺服務(wù)器之間或者在服務(wù)器和工作站之間進行。如果設(shè)定為定期進行完整復(fù)制，那么 Notes會根據(jù)時間使所有復(fù)本保持同步。

2、復(fù)本標識符

復(fù)本與源文件或數(shù)據(jù)庫有相同的復(fù)本標識符。這是數(shù)據(jù)庫的復(fù)本與拷貝的區(qū)別所在，因為有共同的標識符才能使復(fù)本與源數(shù)據(jù)庫之間可以復(fù)制更改信息。如果數(shù)據(jù)庫的兩個拷貝具有不同的復(fù)本標識符，則不能在它們之間進行復(fù)制。

3、復(fù)制沖突和保存沖突

在復(fù)制之間，如果有兩個或多個用戶對相同文檔的不同復(fù)本進行了編輯，就會導(dǎo)致復(fù)制沖突。而保存沖突則是在兩個或多個用戶同時編輯服務(wù)器上同一個數(shù)據(jù)庫的同一個文檔時發(fā)生。當發(fā)生復(fù)制沖突或保存沖突時，Notes 將在視圖頁面左邊把發(fā)生沖突的文檔標注出來。

Notes對復(fù)制沖突的處理是這樣的，在兩個或多個用戶編輯并保存同一個文檔之后，下次進行復(fù)制時，Notes 將編輯和保存最頻繁的文檔指定為主文檔，而將其他文檔顯示為主文檔的答復(fù)文檔，并在視圖頁面左邊用一個菱形符號標注出來。如果用戶在一個復(fù)本中編輯并保存了某文檔，然后另一個用戶將該文檔刪除，則認為該文檔是被刪除的。然而，如果文檔被編輯和保存了多次，或者在該文檔被刪除之后又被另一個用戶編輯和保存過，則把編輯過的文檔作為主文檔。

Note對保存沖突的處理如下，當多個用戶同時打開相同的文檔進行編輯時，Notes指定最先保存的文檔為主文檔。當另一個用戶試圖保存同一文檔時，Notes 就會提示該用戶把它作為“保存沖突”文檔來保存。如果用戶這樣做了，那么 Notes 將它顯示為主文檔的答復(fù)文檔，并在視圖頁面左邊用一個菱形符號標注出來。

根據(jù)筆者的經(jīng)驗，在實際開發(fā)過程中，我們應(yīng)該通過設(shè)計控制保存沖突，避免文檔產(chǎn)生“保存沖突”的答復(fù)文檔。對于復(fù)制沖突可以設(shè)置數(shù)據(jù)庫合并復(fù)制沖突，這樣如果產(chǎn)生增量改動，服務(wù)器在復(fù)制過程中會自動合并沖突。需要說明的是，Notes在進行復(fù)制時，并不是傳統(tǒng)意義上的完全拷貝，而是一系列的規(guī)則進行增量的合并。

4、復(fù)制類型

Domino中支持四種不同的復(fù)制方式

拉入推出：是一個雙向過程。此過程進行時，呼叫服務(wù)器從響應(yīng)服務(wù)器拉入更新，然后向響應(yīng)服務(wù)器推出自己的更新。使用“拉入推出”時，呼叫服務(wù)器上的 Replicator 任務(wù)執(zhí)行所有的工作。拉入推出是系統(tǒng)缺省的復(fù)制方式。

分別拉入：是兩個服務(wù)器交換更新的雙向過程。使用“分別拉入”時，兩個復(fù)制器（一個在呼叫服務(wù)器上，另一個在響應(yīng)服務(wù)器上）共同進行復(fù)制工作。

只推出：是呼叫服務(wù)器向響應(yīng)服務(wù)器推出更新的單向過程。單向復(fù)制總是比雙向復(fù)制耗時少。只拉入：是呼叫服務(wù)器從響應(yīng)服務(wù)器拉入更新的單向過程。單向復(fù)制總是比雙向復(fù)制耗時少。

三、案例

筆者曾經(jīng)參與呼和浩特鐵路局客運公司辦公自動化系統(tǒng)的設(shè)計、開發(fā)和實施工作。呼和浩特鐵路局客運公司包括三個信息中心，分別在呼和浩特市、包頭市和東河區(qū)三個地方，三地之間通過64K的DDN專線連接。因為帶寬的限制，用戶遠程訪問速度成為本系統(tǒng)的瓶頸，經(jīng)過再三論證，我們決定構(gòu)建分布式數(shù)據(jù)庫存儲架構(gòu)，采用后臺數(shù)據(jù)庫實時同步復(fù)制技術(shù)使三個異地服務(wù)器內(nèi)容一致，將遠程訪問轉(zhuǎn)化為本地訪問，從而提高終端用戶訪問速度。

詳細步驟如下。

1、安裝服務(wù)器

在三地信息中心分別安裝Domino服務(wù)器，服務(wù)器的詳細配置并不復(fù)雜，讀者可以參閱相關(guān)資料，一般情況下按照安裝配置向?qū)牟骄涂梢钥旖菖渲猛戤?。注意三臺Domino服務(wù)器不要同名，其簡單拓撲結(jié)構(gòu)如下：

圖中呼市處于相對中心的位置，所以呼市和包頭之間，呼市和東河之間分別建立了互推復(fù)制機制，為了降低網(wǎng)絡(luò)負擔(dān)和流通環(huán)節(jié)，沒有建立包頭和東河之間的復(fù)制，各地直接通過與呼市同步來保持三地數(shù)據(jù)的一致。一般而言，如果各分支機構(gòu)處于平等位置，互相之間的數(shù)據(jù)流量相當，也可以兩兩之間建立復(fù)制機制。

2、建立服務(wù)器之間的連接

對于兩個服務(wù)器之間進行的復(fù)制，應(yīng)創(chuàng)建一個“連接”文檔來指定進行信息交換的方式和時間?！斑B接”文檔存儲在“Domino 目錄”中。一次僅使用一個“連接”文檔來處理每對服務(wù)器之間的所有復(fù)制。創(chuàng)建不必要的“連接”文檔會增加網(wǎng)絡(luò)傳輸量和阻塞。

缺省情況下，郵件路由和復(fù)制都已被啟用，但是可以更改此設(shè)置并使用單獨的“連接”文檔來安排每項任務(wù)。這樣，就可以分別控制復(fù)制和郵件路由的特定時間、時間范圍或重復(fù)間隔，并根據(jù)需要增加或減小這些設(shè)置。

怎么保證服務(wù)器之間的連接能順利的連通？實際上對于物理連接形式Domino并不關(guān)心，也就是說物理上無論通過什么連接方式，專線、光纖、X.25、電話撥號等，只要TCP/IP通，簡單說只要能Ping通，就能夠保證服務(wù)器之間順利連接。

下面給出了建立服務(wù)器之間連接的操作步驟和主要參數(shù)的設(shè)置說明：

A）在 Domino Administrator 中單擊“配置”附簽。

B）在“使用目錄”域中選擇連接服務(wù)器的“Domino 目錄”。

C）單擊“服務(wù)器”，然后單擊“連接”。

D）單擊“添加連接”。

F）關(guān)鍵域配置描述：

域輸入

源服務(wù)器連接服務(wù)器的名稱

使用以下端口連接服務(wù)器或源服務(wù)器使用的網(wǎng)絡(luò)端口（或協(xié)議）名稱

使用優(yōu)先級選擇一個：“一般”（缺?。暗汀?/p>

目標服務(wù)器響應(yīng)服務(wù)器的名稱

可選網(wǎng)絡(luò)地址與所選協(xié)議相適應(yīng)的目標服務(wù)器的地址。對于 TCP/IP，應(yīng)使用完全有效的網(wǎng)絡(luò)域名稱（首選）或 IP 地址（例如：HR-E.Acme.com 或者 192.22.256.36）。

對 TCP/IP 或其他需要特定網(wǎng)絡(luò)地址的協(xié)議，建議填寫此域。

復(fù)制類型缺省情況下，Domino 的復(fù)制方向為“拉入推出”。但根據(jù)實際情況，為了平衡服務(wù)器之間的負載，充分發(fā)揮每個服務(wù)器的性能，我們可以設(shè)定雙方互推或者互拉，本例中我們采用服務(wù)器雙方互推的方式，即每個服務(wù)器上的連接復(fù)制類型都是由源服務(wù)器向目標服務(wù)器推出。

復(fù)制文件/目錄如果為空，則服務(wù)器將DATA目錄下的所有存在復(fù)本的數(shù)據(jù)庫全部進行復(fù)制，否則填寫哪個庫系統(tǒng)就復(fù)制哪個庫。

安排在安排中可以設(shè)置連接時間、重復(fù)間隔、每周復(fù)制日期等參數(shù)?？筛鶕?jù)實際情況設(shè)定，本例設(shè)置為每日8：00到晚上10：00連接，連接期間每一小時進行同步復(fù)制或服務(wù)器依據(jù)增量自動復(fù)制，非連接時間服務(wù)器處理其他性能調(diào)優(yōu)動作，如更新數(shù)據(jù)庫索引等。

H）保存文檔。

3、建立數(shù)據(jù)庫復(fù)本

連接建立成功以后，保證服務(wù)器之間可以進行通訊了，下一步就是對要進行同步的數(shù)據(jù)庫建立復(fù)本，當建立了復(fù)本以后，通過連接設(shè)定就能保證異地各個復(fù)本之間的數(shù)據(jù)完全一致。

這里需要說明的是，我們在第一臺服務(wù)器上建立了一套數(shù)據(jù)庫系統(tǒng)，對于需要同步復(fù)制的所有數(shù)據(jù)庫，在其他服務(wù)器上只需要產(chǎn)生他們的復(fù)本，而不能再在每臺服務(wù)器上分別創(chuàng)建相同的數(shù)據(jù)庫。在本例中我們在呼市客運公司信息中心安裝配置好第一臺服務(wù)器后，在包頭信息中心和東河信息中心的Domino服務(wù)器上則通過呼市信息中心服務(wù)器建立各自本地所有需要的數(shù)據(jù)庫復(fù)本。

如果要在本地Domino服務(wù)器上創(chuàng)建源Domino服務(wù)器的復(fù)本數(shù)據(jù)庫，需要本地服務(wù)器的系統(tǒng)管理員具有對源服務(wù)器訪問和創(chuàng)建復(fù)本的權(quán)限，因為Domino對權(quán)限控制很嚴格，尤其是多域用戶之間的訪問，其目的就是為了充分保證系統(tǒng)的安全性。那么怎樣才能具有這樣的創(chuàng)建復(fù)本的權(quán)限呢？需要具有兩個基本的存取權(quán)限就可以在本服務(wù)器上創(chuàng)建源服務(wù)器的數(shù)據(jù)庫復(fù)本，一是源服務(wù)器配置中允許本地服務(wù)器的系統(tǒng)管理員訪問，二是允許本地服務(wù)器的系統(tǒng)管理員創(chuàng)建數(shù)據(jù)庫復(fù)本，這兩個權(quán)限由源數(shù)據(jù)庫的系統(tǒng)管理員設(shè)置給目標數(shù)據(jù)庫的系統(tǒng)管理員。結(jié)合本例，需要在包頭信息中心的服務(wù)器上建立呼市信息中心的數(shù)據(jù)庫復(fù)本，則首先在呼市信息中心的服務(wù)器上配置“當前服務(wù)器”文檔。

A）在 Domino Administrator 中單擊“當前服務(wù)器”文檔。

B）單擊“編輯服務(wù)器”

C）選擇“安全”標簽頁，填寫以下兩項：

域輸入

訪問服務(wù)器本例為包頭信息中心系統(tǒng)服務(wù)器名稱及管理員的用戶名稱

創(chuàng)建數(shù)據(jù)庫復(fù)本同樣是包頭信息中心系統(tǒng)管理員的用戶名稱

D保存后退出。

接下來就可以在包頭信息中心的服務(wù)器上創(chuàng)建源數(shù)據(jù)庫的復(fù)本了，這步動作比較簡單，選擇源數(shù)據(jù)庫，從菜單中執(zhí)行創(chuàng)建復(fù)本功能即可，這里不在詳細描述。

同樣的處理在東河的服務(wù)器上如法炮制一遍，則所有數(shù)據(jù)庫復(fù)本成功建立完畢。

4、復(fù)制測試

完成以上三步，配置就全部完成，接下來就要測試一下配置是否完全成功以及配置是否生效。我們測試主要包括兩個內(nèi)容：一是測試連接是否成功，能否進行復(fù)制動作。二是測試設(shè)置的復(fù)制安排是否按照預(yù)定生效。

A）進行第一項測試的辦法是在Domino的控制臺上，使用Domino的系統(tǒng)命令，進行數(shù)據(jù)庫的推、拉測試，檢查復(fù)制是否能成功進行，命令格式如下：

拉入復(fù)制

語法：Pull servername [databasename]

描述：強制從指定服務(wù)器到本地服務(wù)器進行單向復(fù)制。通過在命令行中包括單個數(shù)據(jù)庫名稱，將其從特定服務(wù)器單向復(fù)制到本地服務(wù)器。發(fā)起復(fù)制的服務(wù)器從指定的服務(wù)器接受數(shù)據(jù)，但不能申請將自己的數(shù)據(jù)復(fù)制到其他服務(wù)器上。該命令重設(shè)在“Domino 目錄”中預(yù)定的任何復(fù)制，而強制一臺服務(wù)器與發(fā)起復(fù)制的服務(wù)器立即進行復(fù)制。如果可能，請輸入服務(wù)器完整的層次結(jié)構(gòu)名稱。

推出復(fù)制

語法：Push servername [databasename]

描述：強制進行從本地服務(wù)器到指定服務(wù)器的單向復(fù)制。也可以通過在命令行中包括要復(fù)制的單個數(shù)據(jù)庫名稱，來將其從本地服務(wù)器單向復(fù)制到特定服務(wù)器。發(fā)起復(fù)制的服務(wù)器將數(shù)據(jù)發(fā)送到指定的服務(wù)器，但不申請獲得數(shù)據(jù)。該命令可以重設(shè)在“Domino 目錄”中預(yù)定的任何復(fù)制，而強制一臺服務(wù)器立即與發(fā)起復(fù)制的服務(wù)器進行復(fù)制。如果可能的話，請指定服務(wù)器完整的層次結(jié)構(gòu)名稱。

B）第二項測試通過將連接文檔的安排時間設(shè)置為兩分鐘進行一次，同時觀察Domino的系統(tǒng)控制臺，查看服務(wù)器的動作，以確保安排設(shè)定生效。正確的結(jié)果是從控制臺上能看到系統(tǒng)報告復(fù)制過程。

按照以上實例說明進行，沒有任何問題。

四、結(jié)束語

我們同樣可以在客戶端利用復(fù)制技術(shù)，例如在本地客戶端建立郵件文件數(shù)據(jù)庫的復(fù)本，以便與我們在外出或者脫機狀態(tài)下還可以訪問郵件文件。本地復(fù)本要求沒有在服務(wù)器之間進行復(fù)制的要求那么高，本地復(fù)本的作用體現(xiàn)在通過本地復(fù)本，可以在沒有通過網(wǎng)絡(luò)連接服務(wù)器時對數(shù)據(jù)庫進行操作。當設(shè)置 Notes 為遠程工作站時，就可以通過調(diào)制解調(diào)器呼叫服務(wù)器并在本地復(fù)本和服務(wù)器數(shù)據(jù)庫之間交換更新信息。

第二篇：網(wǎng)絡(luò)數(shù)據(jù)庫講稿(復(fù)制)

網(wǎng)絡(luò)數(shù)據(jù)庫講稿

4/20/2013

一、復(fù)制的基本概念

SQL Server復(fù)制是在數(shù)據(jù)庫之間對數(shù)據(jù)和數(shù)據(jù)庫對象進行復(fù)制和分發(fā)并且對于數(shù)據(jù)的修改進行同步，以確保其一致性的一組技術(shù)。使用復(fù)制可以將數(shù)據(jù)分發(fā)到不同位置，通過局域網(wǎng)、Internet分發(fā)給多個遠程服務(wù)器站點；還可將多個用戶和站點的數(shù)據(jù)進行合并。

二、復(fù)制模型

復(fù)制技術(shù)采用發(fā)布(出版)——訂閱模型分發(fā)數(shù)據(jù)。

SQL Server復(fù)制模型由下列對象組成：發(fā)布服務(wù)器，分發(fā)服務(wù)器，訂閱服務(wù)器，發(fā)布，項目，訂閱。還有幾個負責(zé)在發(fā)布服務(wù)器和訂閱服務(wù)器之間復(fù)制和移動數(shù)據(jù)的復(fù)制進程：快照代理程序，分發(fā)代理程序，日志讀取器代理程序，隊列讀取器代理程序，合并代理程序。1.服務(wù)器角色

參與復(fù)制的服務(wù)器根據(jù)任務(wù)不同可劃分為以下角色： ①發(fā)布服務(wù)器：數(shù)據(jù)源所在的服務(wù)器。

②分發(fā)服務(wù)器：將出版物從發(fā)布服務(wù)器移動到訂閱服務(wù)器。③訂閱服務(wù)器 2.項目

3.發(fā)布(出版物)4.訂閱 5.復(fù)制的類型 ①快照復(fù)制 ②事務(wù)復(fù)制 ③合并復(fù)制 6.復(fù)制代理程序

①快照代理程序：與所有復(fù)制類型一起使用。

②分發(fā)代理程序：與快照復(fù)制和事務(wù)復(fù)制一起使用。③合并代理程序：與合并復(fù)制一起使用。

④日志讀取器代理程序：與事務(wù)復(fù)制一起使用。

⑤隊列讀取器代理程序：與快照復(fù)制或事務(wù)復(fù)制一起使用。

三、服務(wù)器的連接方式

1.發(fā)布服務(wù)器與分發(fā)服務(wù)器為同一物理服務(wù)器 2.發(fā)布服務(wù)器與分發(fā)服務(wù)器為不同物理服務(wù)器 3.發(fā)布者與再次發(fā)布者連接方式

4.多發(fā)布服務(wù)器單訂閱服務(wù)器連接方式

四、配置復(fù)制

復(fù)制一般包括以下幾個階段：配置發(fā)布和分發(fā)，生成和應(yīng)用初始快照，修改復(fù)制數(shù)據(jù)，同步和傳播數(shù)據(jù)。

復(fù)制過程中各代理程序的調(diào)度由SQL Server Agent服務(wù)管理，應(yīng)配置SQL Server Agent服務(wù)能夠在系統(tǒng)啟動的時候自動啟動，并且在意外停止時能夠自動重新啟動，由于復(fù)制操作跨越多個服務(wù)器傳輸數(shù)據(jù)，所以SQL Server Agent服務(wù)的啟動帳號應(yīng)使用域用戶帳號。1.配置分發(fā)服務(wù)器

網(wǎng)絡(luò)數(shù)據(jù)庫講稿

4/20/2013 分發(fā)服務(wù)器是快照復(fù)制和事務(wù)復(fù)制的首要組件。在企業(yè)管理器中運行向?qū)?，右擊【?fù)制】，單擊【配置發(fā)布、訂閱服務(wù)器和分發(fā)】啟動【配置發(fā)布和分發(fā)向?qū)А俊Ｈ缓蟀刺崾具M行。

配置完成后，系統(tǒng)在分發(fā)服務(wù)器上創(chuàng)建distribution系統(tǒng)數(shù)據(jù)庫、復(fù)制文件夾、復(fù)制監(jiān)視器。

2.配置發(fā)布服務(wù)器和創(chuàng)建出版物

出版物是準備發(fā)布的表、表中數(shù)據(jù)的子集或其它數(shù)據(jù)庫對象的集合。出版物是訂閱的單元。

在企業(yè)管理器中運行向?qū)В覔簟緩?fù)制】，單擊【新建/發(fā)布】啟動【創(chuàng)建發(fā)布向?qū)А?，然后按提示進行。

在“指定項目”步驟，單擊“項目默認值”或“對象”右端的省略號按鈕，可設(shè)置快照屬性。

可循環(huán)創(chuàng)建多個發(fā)布。

可查閱和修改已建發(fā)布的屬性。

3.訂閱

訂閱是對發(fā)布到指定訂閱服務(wù)器的數(shù)據(jù)或數(shù)據(jù)庫對象的請求。一個訂閱服務(wù)器可以向不同發(fā)布請求多個訂閱。

訂閱可在發(fā)布服務(wù)器上創(chuàng)建(強制訂閱)或在訂閱服務(wù)器上創(chuàng)建(請求訂閱)。(1)強制訂閱

在企業(yè)管理器中：工具/向?qū)В归_【復(fù)制】，啟動【創(chuàng)建強制訂閱向?qū)А浚缓蟀刺崾具M行。

(2)請求訂閱 在企業(yè)管理器中：工具/向?qū)В归_【復(fù)制】，啟動【創(chuàng)建請求訂閱向?qū)А浚缓蟀刺崾具M行。

也可按教材P175的例子，先創(chuàng)建發(fā)布，再配置發(fā)布和分發(fā)服務(wù)器，最后創(chuàng)建訂閱。

第三篇：OA辦公系統(tǒng)的產(chǎn)品和技術(shù)

和您一樣，內(nèi)行青睞萬戶OA

OA辦公系統(tǒng)的產(chǎn)品和技術(shù)

1.產(chǎn)品和技術(shù)是骨架

如今，技術(shù)發(fā)展日新月異，要求OA辦公系統(tǒng)選型必須跟得上技術(shù)和需求的潮流，才能讓先進的信息技術(shù)為我所用，提升管理效率。正所謂“產(chǎn)品和技術(shù)就好比一個骨架，如果這個骨架缺了胳膊，或者關(guān)節(jié)不靈活，那么就很難滿足企業(yè)的現(xiàn)實所需”。因此，企業(yè)在選型中首先要關(guān)注的就是產(chǎn)品和技術(shù)能否提供一個平衡且靈活的“骨架”。

2.php技術(shù)平臺以其成熟性、開放性和跨平臺性

從技術(shù)方面來說，java平臺的OA辦公系統(tǒng)以其拓展性、穩(wěn)定性等優(yōu)勢雄踞高端OA市場;php技術(shù)平臺以其成熟性、開放性和跨平臺性等優(yōu)勢成為中小企業(yè)試水協(xié)同辦公的首選產(chǎn)品。通過JAVA語言開發(fā)產(chǎn)品具有很強的優(yōu)勢，其基于“協(xié)同矩陣”模型和齒輪聯(lián)動模型打造的協(xié)同管理平臺，能將企業(yè)作為一個有機的整體來對待，將組織的七大要素：人的要素、流程的要素、知識的要素、客戶資源的要素、項目事件的要素、物的要素和財?shù)囊剡M行“立體多線程”的管理，并以人力資源和工作流程模塊作為整個系統(tǒng)的心臟和血脈，與其他功能模塊，如：知識文檔管理模塊、客戶關(guān)系管理模塊、項目管理模塊、財務(wù)管理模塊和資產(chǎn)管理模塊強相關(guān)聯(lián)，從而更好地發(fā)揮協(xié)同作用，讓組織運行更更為順暢。

3.產(chǎn)品是“骨架”服務(wù)填充“血肉”

目前，用戶在選擇OA辦公系統(tǒng)時已日趨理性，不僅會關(guān)注產(chǎn)品與自身需求的切合度，也會更加關(guān)注OA廠商的實施服務(wù)能力。所以，用戶將更關(guān)注OA廠商是否能夠在實施過程中幫助他們進行應(yīng)用推廣，在項目交付時就能夠初見成效。而要想做到這一點，OA廠商必須要有嚴格的實施過程控制機制和伸縮性足夠強大的實施服務(wù)力量。

協(xié)同OA辦公系統(tǒng)要能夠煥發(fā)出管理的生命力，必須要有血有肉，如果說產(chǎn)品和技術(shù)是骨架，那么服務(wù)就是填充血肉的過程，這個過程也決定著最終的應(yīng)用效果，而要做好服務(wù)，則取決于廠商的本地化服務(wù)能力、實施體系控制等。

第四篇：OA辦公系統(tǒng)的主要技術(shù)架構(gòu)

和您一樣，內(nèi)行青睞萬戶OA

OA辦公系統(tǒng)的主要技術(shù)架構(gòu)

OA辦公系統(tǒng)是一種重要的應(yīng)用軟件，目前各類應(yīng)用軟件已經(jīng)傾向于組件化的設(shè)計思想，以降低各邏輯組件間的耦合性。設(shè)計思想中最為流行的、為絕大部分現(xiàn)有應(yīng)用系統(tǒng)所采用的是：“MVC”（Model View Controller）設(shè)計思想。OA辦公系統(tǒng)實現(xiàn)此思想時根據(jù)所采用的具體開發(fā)技術(shù)又分為三種架構(gòu)：Domino架構(gòu)、J2EE架構(gòu)、Net架構(gòu)。MVC設(shè)計思想

MVC英文即Model View Controller。即把一個應(yīng)用的輸入輸出、處理、存儲流程按照Model、View、Controller的方式進行分離，這樣一個應(yīng)用被分成三個層——模型層、視圖層、控制層。

MVC是構(gòu)筑軟件優(yōu)秀的設(shè)計思想，將業(yè)務(wù)處理與顯示分離。各層之間松耦合，日后當進行擴展或者整合的時候，可以用搭積木一樣的方式來進行。Domina架構(gòu)

Domino屬于IBM陣營的技術(shù)，最初由Lotus公司開發(fā)。后被IBM收購而更加發(fā)揚光大，是OA領(lǐng)域最成熟的技術(shù)。目前基于Domino技術(shù)開發(fā)的OA辦公系統(tǒng)，通常是將Domino作為Model。不需另行開發(fā)，再在Domino之上通過其提供的工具開發(fā)Controller和View，其中的View目前大部分是Web頁面形式。這種架構(gòu)其實就是在Domino精華之上加了一層殼，實質(zhì)還是原來的Domino系統(tǒng)。J2EE架構(gòu)

J2EE全稱為Java 2 Enterprise Edition，后改名為：Java EE，即Java Platform Enterprise Edition。J2EE原屬于SUN陣營，去年SUN為Oracle公司所收購。Java語言的流行、開源應(yīng)用的蓬勃發(fā)展，使得J2EE是目前最流行的應(yīng)用開發(fā)架構(gòu)，也是將MVC思想實現(xiàn)地最徹底的新技術(shù)。J2EE提供了一系列的規(guī)范，可以與多種產(chǎn)品和技術(shù)無縫集成。Net架構(gòu)

Net屬于Microsoft陣營，在應(yīng)用開發(fā)領(lǐng)域，是J2EE架構(gòu)近年來的競爭對手。兩者的設(shè)計思想很多地方相互學(xué)習(xí)，十分類似。最大的不同在于：。Net架構(gòu)用Microsoft的技術(shù)實現(xiàn)，只能運行于Windows平臺之上，而J2EE架構(gòu)用Java語言實現(xiàn)?？梢赃\行于任何平臺之上，能和任何符合其規(guī)范的產(chǎn)品或技術(shù)“搭積木”。

第五篇：從Google Spanner漫談分布式存儲與數(shù)據(jù)庫技術(shù)

從Google Spanner漫談分布式存儲與數(shù)據(jù)庫技術(shù)

文/曹偉

Spanner 的設(shè)計反映了 Google 多年來在分布式存儲系統(tǒng)領(lǐng)域上經(jīng)驗的積累和沉淀，它采用了 Megastore 的數(shù)據(jù)模型，Chubby 的數(shù)據(jù)復(fù)制和一致性算法，而在數(shù)據(jù)的可擴展性上使用了 BigTable 中的技術(shù)。新穎之處在于，它使用高精度和可觀測誤差的本地時鐘來判斷分布式系統(tǒng)中事件的先后順序。Spanner 代表了分布式數(shù)據(jù)庫領(lǐng)域的新趨勢——NewSQL。

Spanner 是 Google 最近公開的新一代分布式數(shù)據(jù)庫，它既具有 NoSQL 系統(tǒng)的可擴展性，也具有關(guān)系數(shù)據(jù)庫的功能。例如，它支持類似 SQL 的查詢語言、支持表連接、支持事務(wù)（包括分布式事務(wù)）。Spanner 可以將一份數(shù)據(jù)復(fù)制到全球范圍的多個數(shù)據(jù)中心，并保證數(shù)據(jù)的一致性。一套 Spanner 集群可以擴展到上百個數(shù)據(jù)中心、百萬臺服務(wù)器和上T條數(shù)據(jù)庫記錄的規(guī)模。目前，Google 廣告業(yè)務(wù)的后臺（F1）已從 MySQL 分庫分表方案遷移到了 Spanner 上。

數(shù)據(jù)模型

傳統(tǒng)的 RDBMS（例如 MySQL）采用關(guān)系模型，有豐富的功能，支持 SQL 查詢語句。而 NoSQL 數(shù)據(jù)庫多是在 key-value 存儲之上增加有限的功能，如列索引、范圍查詢等，但具有良好的可擴展性。Spanner 繼承了 Megastore 的設(shè)計，數(shù)據(jù)模型介于 RDBMS 和 NoSQL 之間，提供樹形、層次化的數(shù)據(jù)庫 schema，一方面支持類 SQL 的查詢語言，提供表連接等關(guān)系數(shù)據(jù)庫的特性，功能上類似于 RDBMS；另一方面整個數(shù)據(jù)庫中的所有記錄都存儲在同一個 key-value 大表中，實現(xiàn)上類似于 BigTable，具有 NoSQL 系統(tǒng)的可擴展性。

在 Spanner 中，應(yīng)用可以在一個數(shù)據(jù)庫里創(chuàng)建多個表，同時需要指定這些表之間的層次關(guān)系。例如，圖 1 中創(chuàng)建的兩個表——用戶表（Users）和相冊表（Albums），并且指定用戶表是相冊表的父節(jié)點。父節(jié)點和子節(jié)點間存在著一對多的關(guān)系，用戶表中的一條記錄（一個用戶）對應(yīng)著相冊表中的多條記錄（多個相冊）。此外，要求子節(jié)點的主鍵必須以父節(jié)點的主鍵作為前綴。例如，用戶表的主鍵（用戶 ID）就是相冊表主鍵（用戶 ID+ 相冊 ID）的前綴。

圖 1 schema 示例，表之間的層次關(guān)系，記錄排序后交錯的存儲

顯然所有表的主鍵都將根節(jié)點的主鍵作為前綴，Spanner 將根節(jié)點表中的一條記錄，和以其主鍵作為前綴的其他表中的所有記錄的集合稱作一個 Directory。例如，一個用戶的記錄及該用戶所有相冊的記錄組成了一個 Directory。Directory 是 Spanner 中對數(shù)據(jù)進行分區(qū)、復(fù)制和遷移的基本單位，應(yīng)用可以指定一個 Directory 有多少個副本，分別存放在哪些機房中，例如把用戶的 Directory 存放在這個用戶所在地區(qū)附近的幾個機房中。

這樣的數(shù)據(jù)模型具有以下好處。

? 一個 Directory 中所有記錄的主鍵都具有相同前綴。在存儲到底層 key-value 大表時，會被分配到相鄰的位置。如果數(shù)據(jù)量不是非常大，會位于同一個節(jié)點上，這不僅提高了數(shù)據(jù)訪問的局部性，也保證了在一個 Directory 中發(fā)生的事務(wù)都是單機的。

? Directory 還實現(xiàn)了從細粒度上對數(shù)據(jù)進行分區(qū)。整個數(shù)據(jù)庫被劃分為百萬個甚至更多個 Directory，每個 Directory 可以定義自己的復(fù)制策略。這種 Directory-based 的數(shù)據(jù)分區(qū)方式比 MySQL 分庫分表時 Table-based 的粒度要細，而比 Yahoo!的 PNUTS 系統(tǒng)中 Row-based 的粒度要粗。

? Directory 提供了高效的表連接運算方式。在一個 Directory 中，多張表上的記錄按主鍵排序，交錯（interleaved）地存儲在一起，因此進行表連接運算時無需排序即可在表間直接進行歸并。

復(fù)制和一致性

Spanner 使用 Paxos 協(xié)議在多個副本間同步 redo 日志，從而保證數(shù)據(jù)在多個副本上是一致的。Google 的工程師鐘情于 Paxos 協(xié)議，Chubby、Megastore 和 Spanner 等一系列產(chǎn)品都是在 Paxos 協(xié)議的基礎(chǔ)上實現(xiàn)一致性的。

Paxos 的基本協(xié)議很簡單。協(xié)議中有三個角色：Proposer、Acceptor 和 Learner，Learner 和 Proposer 分別是讀者和寫者，Acceptor 相當于存儲節(jié)點。整個協(xié)議描述的是，當系統(tǒng)中有多個 Proposer 和 Acceptor 時，每次 Proposer 寫一個變量就會啟動一輪決議過程（Paxos instance），如圖 2 所示。決議過程可以保證即使多個 Proposer 同時寫，結(jié)果也不會在 Acceptor 節(jié)點上不一致。確切地說，一旦某個 Proposer 提交的值被大多數(shù) Acceptor 接受，那么這個值就被選中，在整輪決議的過程中該變量就不會再被修改為其他值。如果另一個 Proposer 要寫入其他值，必須啟動下一輪決議過程，而決議過程之間是串行（serializable）的。

圖 2 Paxos 協(xié)議正常執(zhí)行流程

一輪決議過程分為兩個階段，即 prepare 階段和 accept 階段。

? 第一階段A：Proposer 向所有 Acceptor 節(jié)點廣播 prepare 消息，消息中只包含一個序號——N。Proposer 需要保證這個序號在這輪決議過程中是全局唯一的（這很容易做到，假如系統(tǒng)中有兩個 Proposer，那么一個 Proposer 使用1，3，5，7，9，??，另一個 Proposer 則使用0，2，4，6，8，??）。

?

第一階段B：Acceptor 接收到 prepare 消息后，如果N是到目前為止見過的最大序號，就返回一個 promise 消息，承諾不會接受序號小于N的請求；如果已接受過其他 Proposer 提交的值，則會將這個值連同提交這個值的請求的序號一同返回。? 第二階段A：當 Proposer 從大多數(shù) Acceptor 節(jié)點收到了 promise 消息后，就可以選擇接下來要向 Acceptor 提交的值了。一般情況下，當然選原本打算寫入的值，但如果從收到的 promise 消息中發(fā)現(xiàn)已經(jīng)有其他值被 Acceptor 接受了，那么為了避免造成數(shù)據(jù)不一致的風(fēng)險，這時 Proposer 就必須“大義滅親”，放棄自己打算寫入的值，從其他 Proposer 提交的序號中選擇一個最大的值。接下來 Proposer 向所有的 Acceptor 節(jié)點發(fā)送 accept 包，其中包含在第一階段中挑選的序號N和剛才選擇的值V。

?

第二階段B：Acceptor 收到 accept 包之后，如果N的大小不違反對其他

Proposer 的承諾，就接受這個請求，記錄下值V和序號N，返回一個 ack 消息。反之，則返回一個 reject 消息。

如果 Proposer 從大多數(shù) Acceptor 節(jié)點收到了 ack 消息，說明寫操作成功。而如果在寫操作過程中失敗，Proposer 可以增大序號，重新執(zhí)行第一階段。

基本的 Paxos 協(xié)議可以保證值一旦被選出后就一定不會改變，但不能保證一定會選出值來。換句話說，這個投票算法不一定收斂。有兩個方法可以加速收斂的過程：一個是在出現(xiàn)沖突后通過隨機延遲把機會讓給其他 Proposer，另一個是盡量讓系統(tǒng)中只有一個 Proposer 去提交。在 Chubby 和 Spanner 系統(tǒng)中這兩種方法都用上了，先用隨機延遲的方法通過一輪 Paxos 協(xié)議，在多個 Proposer 中選舉出一個 leader 節(jié)點。接下來所有的寫操作都通過這個 leader 節(jié)點，而 leader 節(jié)點一般還是比較“長壽”的，在廣域網(wǎng)環(huán)境下平均“任期”可以達到一天以上。而 Megastore 系統(tǒng)中沒有很好地解決這個問題，所有的 Proposer 都可以發(fā)起寫操作，這是 Megastore 寫入性能不高的原因之一。

基本的 Paxos 協(xié)議還存在性能上的問題，一輪決議過程通常需要進行兩個回合通信，而一次跨機房通信的代價為幾十到一百毫秒不等，因此兩個回合的通信就有點開銷過高了。不過幸運的是，絕大多數(shù)情況下，Paxos 協(xié)議可以優(yōu)化到僅需一個回合通信。決議過程的第一階段是不需要指定值的，因此可以把 prepare/promise 的過程捎帶在上一輪決議中完成，或者更進一步，在執(zhí)行一輪決議的過程中隱式地涵蓋接下來一輪或者幾輪決議的第一階段。這樣，當一輪決議完成之后，其他決議的第一階段也已經(jīng)完成了。如此看來，只要 leader 不發(fā)生更替，Paxos 協(xié)議就可以在一個回合內(nèi)完成。為了支持實際的業(yè)務(wù)，Paxos 協(xié)議還需要支持并發(fā)，多輪決議過程可以并發(fā)執(zhí)行，而代價是故障恢復(fù)會更加復(fù)雜。

因為 leader 節(jié)點上有最新的數(shù)據(jù)，而在其他節(jié)點上為了獲取最新的數(shù)據(jù)來執(zhí)行 Paxos 協(xié)議的第一階段，需要一個回合的通信代價。因此，Chubby 中的讀寫操作，以及 Spanner 中的讀寫事務(wù)都僅在 leader 節(jié)點上執(zhí)行。而為了提高讀操作的性能，減輕 leader 節(jié)點的負載，Spanner 還提供了只讀事務(wù)和本地讀。只讀事務(wù)只在 leader 節(jié)點上獲取時間戳信息，再用這個時間戳在其他節(jié)點上執(zhí)行讀操作；而本地讀則讀取節(jié)點上最新版本的數(shù)據(jù)。

與 Chubby、Spanner 這種讀寫以 leader 節(jié)點為中心的設(shè)計相比，Megastore 體現(xiàn)了一定的“去中心化”設(shè)計。每個客戶端都可以發(fā)起 Paxos 寫操作，而讀操作則盡可能在本地執(zhí)行。如果客戶端發(fā)現(xiàn)本地數(shù)據(jù)不是最新的，會啟動 catchup 流程更新數(shù)據(jù)，再執(zhí)行本地讀操作返回給客戶端。

最后，對比下其他系統(tǒng)中 replication 的實現(xiàn)。在 BigTable 系統(tǒng)中每個 tablet 服務(wù)器是沒有副本的，完全依賴底層 GFS 把數(shù)據(jù)存到多臺機器上。數(shù)據(jù)的讀寫都通過單個 tablet 服務(wù)器，在 tablet 服務(wù)器出現(xiàn)故障的時需要 master 服務(wù)器將 tablet 指派到其他 tablet 服務(wù)器上才能恢復(fù)可用。Dynamo 系統(tǒng)則貫徹了“去中心化”的思想，將數(shù)據(jù)保存在多個副本上，每個副本都可以寫入（update everywhere）。而不同副本同時寫入的數(shù)據(jù)可能會存在不一致，則需要使用版本向量（version vector）記錄不同的值和時間戳，由應(yīng)用去解釋或合并不一致的數(shù)據(jù)。盡管 Dynamo 系統(tǒng)還提供了 NWR 的方式來支持有一致性保證的讀寫操作，但總的來說 Dynamo 為了高可用性犧牲了一致性。ZooKeeper、MongoDB 與 Chubby、Spanner 類似，通過 leader 選舉協(xié)議從多個副本中選擇一個 leader，所有寫操作都在經(jīng)過 leader 節(jié)點序列化后，同步到其他副本上。ZooKeeper 則是在寫入大多數(shù)節(jié)點后返回，而 MongoDB 主要采用異步的主從復(fù)制方式。

分布式事務(wù)

Spanner 系統(tǒng)中的分布式事務(wù)通過兩階段提交協(xié)議（2PC）實現(xiàn)。2PC 是一類特殊的一致性協(xié)議，假設(shè)一個分布式事務(wù)涉及了多個數(shù)據(jù)節(jié)點，2PC 可以保證在這些節(jié)點上的操作要么全部提交，要么全部失敗，從而保證了整個分布式事務(wù)的原子性（ACID 里的A）。協(xié)議中包含兩個角色：協(xié)調(diào)者（coordinator）和參與者（participant/cohort）。協(xié)調(diào)者是分布式事務(wù)的發(fā)起者，而參與者是參與了事務(wù)的數(shù)據(jù)節(jié)點。在協(xié)議最基本的形式中，系統(tǒng)中有一個協(xié)調(diào)者和多個參與者。

顧名思義，2PC 也包含兩個階段，即投票階段和提交階段（如圖 3 所示）。

圖 3 兩階段提交協(xié)議 ? 在第一階段，協(xié)調(diào)者向所有的參與者發(fā)送投票請求，每個參與者決定是否要提交事務(wù)。如果打算提交的話需要寫好 redo、undo 等日志，并向協(xié)調(diào)者回復(fù) yes 或 no。

? 在第二階段，協(xié)調(diào)者收到所有參與者的回復(fù)，如果都是 yes，那么決定提交這個事務(wù)，寫好日志后向所有參與者廣播提交事務(wù)的通知。反之，則中止事務(wù)并且通知所有參與者。參與者收到提交/中止事務(wù)的命令后，執(zhí)行相應(yīng)操作，如果提交的話還需要寫日志。

協(xié)議過程包括兩回合的通信，在協(xié)調(diào)者和參與者端需要多次寫日志，而且整個過程中所有參與者都占有讀鎖、寫鎖，可見 2PC 開銷不菲。

2PC 最令人詬病之處還不在于性能，而是在有些故障條件下，會造成所有參與者占有讀鎖、寫鎖堵塞在第二階段，需要人工干預(yù)才能繼續(xù)，存在嚴重的可用性隱患。假設(shè)故障發(fā)生在第二階段，協(xié)調(diào)者在做出決定后，通知完一個參與者就宕機了，更糟糕的是被通知的這位參與者在執(zhí)行完“上級指示”之后也宕機了，這時對其他參與者來說，就必須堵塞在那里等待結(jié)果。

Spanner 利用基于 Paxos 協(xié)議的復(fù)制技術(shù)，改善了 2PC 的可用性問題。2PC 協(xié)議過程中的協(xié)調(diào)者和參與者生成的日志都會利用 Paxos 協(xié)議復(fù)制到所有副本中，這樣無論是協(xié)調(diào)者或參與者宕機，都會有其他副本代替它們，完成 2PC 過程而不至于堵塞。在 Paxos 協(xié)議上實現(xiàn) 2PC 這一思路很巧妙，Paxos 協(xié)議保證了大多數(shù)節(jié)點在線情況下的可用性，而 2PC 保證了分布式協(xié)議的一致性。

事件的順序

傳統(tǒng)上，在設(shè)計一個分布式系統(tǒng)時，都會假設(shè)每個節(jié)點的運行速度和時鐘的快慢各不相同的情況，并且在節(jié)點之間進行同步的唯一方法就是異步通信。系統(tǒng)中的每個節(jié)點都扮演著觀察者的角色，并從其他節(jié)點接收事件發(fā)生的通知。判斷系統(tǒng)中兩個事件的先后順序主要依靠分析它們的因果關(guān)系，包括 Lamport 時鐘、向量時鐘等算法，而這一切都存在通信開銷。

因此，Spanner 提出了一種新的思路，在不進行通信的情況下，利用高精度和可觀測誤差的本地時鐘（TrueTime API）給事件打上時間戳，并且以此比較分布式系統(tǒng)中兩個事件的先后順序。利用這個方法，Spanner 實現(xiàn)了事務(wù)之間的外部一致性（external consistency）（如圖 4 所示），也就是說，一個事務(wù)結(jié)束后另一個事務(wù)才開始，Spanner 可以保證第一個事務(wù)的時間戳比第二個事務(wù)的時間戳要早，從而兩個事務(wù)被串行化后也一定能保持正確的順序。

圖 4 事務(wù)外部一致性的實現(xiàn)

TrueTime API 是一個提供本地時間的接口，但與 Linux 上 gettimeofday 接口不一樣的是，它除了可以返回一個時間戳t，還會給出一個誤差ε。例如，返回的時間戳是 1 分 30 秒 350 毫秒，而誤差是 5 毫秒，那么真實的時間在 1 分 30 秒 345 毫秒到 355 毫秒之間。真實的系統(tǒng)中ε平均下來是 4 毫秒。

利用 TrueTime API，Spanner 可以保證給出的事務(wù)標記的時間戳介于事務(wù)開始的真實時間和事務(wù)結(jié)束的真實時間之間。假如事務(wù)開始時 TrueTime API 返回的時間是{t1, ε1}，此時真實時間在 t1-ε1到 t1+ε1之間；事務(wù)結(jié)束時 TrueTime API 返回的時間是{t2, ε2}，此時真實時間在 t2-ε2到 t2+ε2之間。Spanner 會在 t1+ε1和 t2-ε2之間選擇一個時間點作為事務(wù)的時間戳，但這需要保證 t1+ε1小于 t2-ε2，為了保證這點，Spanner 會在事務(wù)執(zhí)行過程中等待，直到 t2-ε2大于 t1+ε1時才提交事務(wù)。由此可以推導(dǎo)出，Spanner 中一個事務(wù)至少需要2ε的時間（平均 8 毫秒）才能完成。

由此可見，這種新方法雖然避免了通信開銷，卻引入了等待時間。為了保證外部一致性，寫延遲是不可避免的，這也印證了 CAP 定理所揭示的法則，一致性與延遲之間是需要權(quán)衡的。

最后介紹一下 TrueTime API 的實現(xiàn)。TrueTime API 的實現(xiàn)大體上類似于網(wǎng)絡(luò)時間協(xié)議（NTP），但只有兩個層次。第一層次，服務(wù)器是擁有高精度計時設(shè)備的，每個機房若干臺，大部分機器都裝備了 GPS 接收器，剩下少數(shù)機器是為 GPS 系統(tǒng)全部失效的情況而準備的，叫做“末日”服務(wù)器，裝備了原子鐘。所有的 Spanner 服務(wù)器都屬于第二層，定期向多個第一層的時間服務(wù)器獲取時間來校正本地時鐘，先減去通信時間，再去除異常值，最后求交集。

NewSQL

六年前，BigTable 展示了一個簡潔、優(yōu)美、具有高可擴展性的分布式數(shù)據(jù)庫系統(tǒng)，引起了 NoSQL 浪潮。然而 Spanner 的設(shè)計者們指出了 BigTable 在應(yīng)用中遇到的一些阻力。

? 缺少類似 SQL 的界面，缺少關(guān)系數(shù)據(jù)庫擁有的豐富的功能。? 只支持單行事務(wù)，缺少跨行事務(wù)。

?

需要在跨數(shù)據(jù)中心的多個副本間保證一致性。

這些來自應(yīng)用開發(fā)者的需求催生了 Spanner，一個既擁有 key-value 系統(tǒng)的高可擴展性，也擁有關(guān)系數(shù)據(jù)庫的豐富功能（包括事務(wù)、一致性等特性）的系統(tǒng)。這類兼顧可擴展性和關(guān)系數(shù)據(jù)庫功能的產(chǎn)品被稱為“NewSQL”，Spanner 的公開會不會開啟 NewSQL 的時代呢？我們拭目以待。

總結(jié)

最后從 CAP 定理的角度來分析下 Spanner。

CAP 定理是指在網(wǎng)絡(luò)可能出現(xiàn)分區(qū)故障的情況下，一致性和可用性不可得兼。形式化地說就是，P => 非(A與P)，可以更進一步地總結(jié)為，一致性和延遲之間必須進行權(quán)衡。Paxos 協(xié)議在C和A之間選擇了嚴格的一致性，而A則降級為大多數(shù)一致性（majority available）。

Spanner 還通過在事務(wù)中增加延遲的方法實現(xiàn)了外部一致性，每個事務(wù)需要至少兩倍的時鐘誤差才能完成。如果時鐘出現(xiàn)故障造成誤差增長，那么完成事務(wù)所需的時間也就隨之增長。在這里，時鐘故障也應(yīng)當認為是P的一種形式。在發(fā)生時鐘故障（P）的情況下，為了保證一致性（C），而必須增加延遲（A），這一點充分印證了 CAP 定理。

從 Spanner 系統(tǒng)中，我們可以學(xué)習(xí)到一些經(jīng)驗。

? MegaStore、Spanner 和 F1 系統(tǒng)所選擇的樹形、層次化的數(shù)據(jù)庫 schema 是很精妙的，它能支持高效的表連接，這既提供了類似關(guān)系模型的范式，也提供了一個合適的粒度進行數(shù)據(jù)分區(qū)，具有好的可擴展性，H-Store 也采用了這樣的 schema。

? 跨數(shù)據(jù)中心的多個副本間保持一致是可行的，Paxos 協(xié)議的性能可以優(yōu)化到一個可接受的范圍。

? 在 Paxos 協(xié)議的基礎(chǔ)之上實現(xiàn)的兩階段提交的可用性得到了提高。? 在一個分布式系統(tǒng)中，本地時鐘的作用可以比我們之前想象的大很多。

作者曹偉，淘寶核心系統(tǒng)數(shù)據(jù)庫組技術(shù)專家，從事高性能服務(wù)器、IM、P2P、微博等各類型分布式系統(tǒng)、海量存儲產(chǎn)品的開發(fā)，關(guān)注系統(tǒng)高可用性和一致性及分布式事務(wù)領(lǐng)域。