運(yùn)營商IT支撐系統(tǒng)“去IOE”思路探討

周龍，陳喜珠，彭江強(qiáng)

（湖南省郵電規(guī)劃設(shè)計(jì)院有限公司，長沙 410001）

“IOE”是指以IBM小型機(jī)、Oracle數(shù)據(jù)庫、EMC存儲(chǔ)設(shè)備為代表所組成的IT架構(gòu)，三者構(gòu)成了一個(gè)從軟件到硬件的企業(yè)數(shù)據(jù)庫系統(tǒng)。這類數(shù)據(jù)庫系統(tǒng)幾乎占領(lǐng)了全球大部分商用數(shù)據(jù)庫系統(tǒng)市場份額。除阿里巴巴這樣需要大量數(shù)據(jù)運(yùn)算的電商企業(yè)外，其他如電信行業(yè)也廣泛地使用這套系統(tǒng)。

“去IOE”最初由阿里巴巴提出，阿里去“IOE”背后的原因主要有4個(gè)。

（1）集中式強(qiáng)大單點(diǎn)遠(yuǎn)遠(yuǎn)不能滿足爆炸式業(yè)務(wù)增長應(yīng)用模式的出現(xiàn)，導(dǎo)致系統(tǒng)不能滿足業(yè)務(wù)需求。

（2）“IOE”的技術(shù)限制了其它技術(shù)潛力的發(fā)揮。有很多底層細(xì)節(jié)企業(yè)根本無法掌控。

（3）“IOE”設(shè)備對(duì)機(jī)架、電力、網(wǎng)絡(luò)有特殊要求，要單獨(dú)為它設(shè)計(jì)，成本偏高。

（4）數(shù)據(jù)庫安全問題。包括數(shù)據(jù)的路由、數(shù)據(jù)安全、規(guī)模化運(yùn)維、異步數(shù)據(jù)同構(gòu)等問題。

“IOE”所代表的IT架構(gòu)一方面約束了互聯(lián)網(wǎng)巨頭在業(yè)務(wù)靈活配置等方面的企業(yè)長遠(yuǎn)發(fā)展，另一方面也帶來極高的擴(kuò)展壓力以及天價(jià)的包括部署、維護(hù)在內(nèi)的總成本，所以需要采用新的互聯(lián)網(wǎng)技術(shù)和架構(gòu)取代傳統(tǒng)“IOE”架構(gòu)。

1 運(yùn)營商“去IOE”驅(qū)動(dòng)力

基于“IOE”設(shè)備的體系架構(gòu)被廣泛地運(yùn)用到運(yùn)營商包括營業(yè)、計(jì)費(fèi)、客服等各類IT系統(tǒng)之中。以小型機(jī)為基礎(chǔ)搭建起一套集中式的IT支撐系統(tǒng)，在UNIX的開放性系統(tǒng)上開發(fā)應(yīng)用軟件，滿足相應(yīng)的數(shù)據(jù)處理能力。據(jù)業(yè)內(nèi)人士估算，“IOE”設(shè)備的比例一度占到70%～80%。這可以說是同類產(chǎn)品中的最佳組合，是電信級(jí)運(yùn)營系統(tǒng)穩(wěn)定、可靠的典型代表。

近年來，移動(dòng)互聯(lián)網(wǎng)環(huán)境同樣給運(yùn)營商支撐系統(tǒng)帶來了數(shù)據(jù)量爆發(fā)性增長。海量數(shù)據(jù)與高并發(fā)對(duì)運(yùn)營商現(xiàn)有支撐系統(tǒng)架構(gòu)已經(jīng)形成沖擊?？蛻舾兄?、成本投入、運(yùn)營效率成為運(yùn)營商支撐系統(tǒng)建設(shè)需要考慮的突出問題。

運(yùn)營商流量經(jīng)營過程中，業(yè)務(wù)量快速增長、業(yè)務(wù)峰值問題突出（如表1所示），首先是查詢請(qǐng)求成倍增加。特別是移動(dòng)互聯(lián)網(wǎng)的發(fā)展帶來的話單查詢的方便性，導(dǎo)致用戶查詢需求增加；其次是查詢接入方式的擴(kuò)展迅速，越來越多的外部系統(tǒng)接入請(qǐng)求，CRM、網(wǎng)廳、掌廳、客服、自助終端、營銷查詢等；再次是數(shù)據(jù)導(dǎo)入越來越慢，數(shù)據(jù)量增加明顯。對(duì)外提供原始清單數(shù)據(jù)的傳遞壓力，大批量的數(shù)據(jù)導(dǎo)出。

體現(xiàn)在日常運(yùn)營中的困難具體表現(xiàn)如下。

（1）客戶感知變差。月結(jié)清賬單提供延遲、實(shí)時(shí)查詢接口延遲、停復(fù)機(jī)不及時(shí)等。月底及促銷營業(yè)高峰業(yè)務(wù)辦理壓力巨大。

（2）投入成本縮減。高端小型機(jī)、存儲(chǔ)擴(kuò)容的成本很高，投入不足會(huì)影響運(yùn)營安全。數(shù)據(jù)庫及操作系統(tǒng)軟件成本壓力巨大。

（3）運(yùn)營效率不高。煙囪式系統(tǒng)架構(gòu)擴(kuò)展性差，資源無法共享。面對(duì)市場競爭，支撐系統(tǒng)快速擴(kuò)展響應(yīng)能力有限。

表1 某省級(jí)電信運(yùn)營商2013年業(yè)務(wù)增長數(shù)據(jù)指標(biāo)表

2 運(yùn)營商IT支撐系統(tǒng)“去IOE”思路

2.1 運(yùn)營商主要IT系統(tǒng)分類

運(yùn)營商內(nèi)部IT系統(tǒng)根據(jù)主要計(jì)算特點(diǎn)可分為3類。

（1)面向用戶的并發(fā)請(qǐng)求處理部分：訂單受理、資料查詢、訂單處理等請(qǐng)求處理型應(yīng)用，位于系統(tǒng)Web 及APP層。

（2)面向網(wǎng)絡(luò)的重復(fù)性任務(wù)處理部分：如話單采集、數(shù)據(jù)抽取及格式轉(zhuǎn)換等。

（3)核心是復(fù)雜關(guān)系型計(jì)算部分：如計(jì)費(fèi)應(yīng)用、各系統(tǒng)數(shù)據(jù)庫等。

2.2 常用“去IOE”解決方案分析

2.2.1 基于x86架構(gòu)的云資源池替代小型機(jī)

PC服務(wù)器虛擬化及資源池管理軟件基本成熟，云管理平臺(tái)具備基本管理能力，建立內(nèi)部IT系統(tǒng)云平臺(tái)技術(shù)條件具備。云平臺(tái)適合測試環(huán)境整合、各系統(tǒng)Web及應(yīng)用層的部署。開發(fā)測試環(huán)境整合場景，可有效提高測試環(huán)境利用效率；各系統(tǒng)Web層/應(yīng)用層適合基于PC服務(wù)器部署，同時(shí)借助應(yīng)用中間件對(duì)操作系統(tǒng)隔離的特性，現(xiàn)有應(yīng)用Web及應(yīng)用層從Unix小型機(jī)向基于PC服務(wù)器的Linux環(huán)境遷移技術(shù)可行。

通過服務(wù)器虛擬化方式實(shí)現(xiàn)多應(yīng)用共享部署；通過資源池管理及云管理平臺(tái)的自動(dòng)化調(diào)度（應(yīng)用啟停、伸縮、遷移等），實(shí)現(xiàn)更加靈活的多應(yīng)用共享部署，提高基礎(chǔ)設(shè)施利用效率及系統(tǒng)可靠性。系統(tǒng)部署架構(gòu)進(jìn)一步集中，發(fā)揮云計(jì)算規(guī)模優(yōu)勢，提升IT集約化運(yùn)營水平：進(jìn)一步提高系統(tǒng)部署物理集中度，發(fā)揮云計(jì)算的規(guī)模優(yōu)勢，提高基礎(chǔ)設(shè)施利用效率。

存在問題如下。

（1）由于云主機(jī)共享物理資源，一般在I/O性能上不如物理機(jī)，因此對(duì)于高I/O要求的可考慮物理機(jī)承載。

（2）由于虛擬化技術(shù)成熟性，在支持?jǐn)?shù)據(jù)庫Cluster/HA等方面尚不完善（如數(shù)據(jù)庫RAC支持存在一定問題），需要數(shù)據(jù)庫RAC的應(yīng)用可考慮用物理機(jī)承載。

（3）虛擬化技術(shù)本身支持HA技術(shù)，但由于虛擬化軟件無法感知應(yīng)用失效，因此不能依靠虛擬化HA解決應(yīng)用高可靠問題，需要在應(yīng)用層部署HA軟件。

（4）目前服務(wù)器虛擬化主要是一虛多，再加上虛擬化軟件本身消耗一定的系統(tǒng)資源，因此并非所有應(yīng)用都適合于遷移到虛擬機(jī)上，對(duì)于物理機(jī)CPU利用率大于50%的應(yīng)用不建議部署到虛擬機(jī)上。

2.2.2 開源數(shù)據(jù)庫軟件替代Oracle

通過部分場景替換Oracle方式進(jìn)行拆分實(shí)現(xiàn)。

2.2.3 分布式存儲(chǔ)替代集中式存儲(chǔ)

集中式存儲(chǔ)是目前資源池的主要存儲(chǔ)提供方式，主要通過硬件保障性能和可靠性，主流技術(shù)包括FC-SAN、 IP-SAN、NAS等，技術(shù)較為成熟，但部署成本較高，擴(kuò)容不靈活，應(yīng)盡量選擇1～2 種技術(shù)方案，以便于存儲(chǔ)資源共享。

分布式存儲(chǔ)是基于x86服務(wù)器的新興存儲(chǔ)技術(shù)，主要通過軟件保障性能和可靠性，主流技術(shù)包括分布式對(duì)象存儲(chǔ)、分布式塊存儲(chǔ)、分布式文件存儲(chǔ)等，具備低成本、靈活擴(kuò)容、高并發(fā)訪問等優(yōu)勢。其中對(duì)象存儲(chǔ)可用性高、適應(yīng)度好（可存儲(chǔ)各種大小數(shù)據(jù)）、存儲(chǔ)數(shù)量大；分布式塊存儲(chǔ)可滿足塊存儲(chǔ)和卷管理需求；分布式共享文件存儲(chǔ)滿足大容量文件共享存儲(chǔ)訪問需求；大數(shù)據(jù)文件系統(tǒng)主要存儲(chǔ)大數(shù)據(jù)文件。隨著大數(shù)據(jù)等應(yīng)用的不斷發(fā)展，分布式存儲(chǔ)需求正在不斷增加，應(yīng)統(tǒng)籌根據(jù)不同存儲(chǔ)需求提供分級(jí)存儲(chǔ)手段，降低存儲(chǔ)資源部署成本。

2.3 運(yùn)營商IT支撐系統(tǒng)去IOE解決方案

綜合考慮客戶感知、成本、實(shí)施能力、后續(xù)運(yùn)維等因素，選擇合適的場景、成熟的方案解決面臨的迫切問題，重點(diǎn)選擇海量數(shù)據(jù)查詢與處理、接入型、大并發(fā)、大數(shù)據(jù)分析等場景，按照 “互聯(lián)網(wǎng)化”的指導(dǎo)思想，全面借鑒、吸收互聯(lián)網(wǎng)企業(yè)先進(jìn)的技術(shù)架構(gòu)，硬件上采用x86平臺(tái)和本地盤，軟件上全面采用以LAMP（Linux+Apache+MySQL+ PHP）為代表的開源軟件嘗試“去IOE”。

本文2.1部分所提到的第（1）、（2）類系統(tǒng)由小型機(jī)向PC服務(wù)器遷移技術(shù)成熟，應(yīng)用改造量小，適合x86云化資源池部署，結(jié)合搭建大數(shù)據(jù)平臺(tái)部署數(shù)據(jù)挖掘等海量計(jì)算應(yīng)用。第（3）類數(shù)據(jù)庫及計(jì)費(fèi)核心應(yīng)用涉及業(yè)務(wù)維度多、關(guān)聯(lián)關(guān)系及規(guī)則復(fù)雜，而且數(shù)據(jù)庫及計(jì)費(fèi)應(yīng)用受當(dāng)前技術(shù)限制，仍需部署在小型機(jī)上，暫不適合遷移至云平臺(tái)。

2.3.1 核心系統(tǒng)輕量化與分布式重構(gòu)

借鑒互聯(lián)網(wǎng)IT的“拆分”、讀寫分離思路，混合架構(gòu)實(shí)現(xiàn)核心系統(tǒng)“部分去IOE”。

CRM域的查詢功能、計(jì)費(fèi)域所有的采集預(yù)處理功能橫向整合到單一系統(tǒng)完成，簡化處理流程，節(jié)省運(yùn)維人員投入。

（1）CRM核心輕量化：核心在線數(shù)據(jù)（“IOE”架構(gòu)）與歷史存檔數(shù)據(jù)（Hadoop架構(gòu)）分離，核心生產(chǎn)應(yīng)用與存檔歷史應(yīng)用分離。

（2）計(jì)費(fèi)核心輕量化：云平臺(tái)分擔(dān)計(jì)費(fèi)系統(tǒng)的歷史資料存儲(chǔ)及查詢。賬單、積分等數(shù)據(jù)剝離到云平臺(tái)。

（3）CRM電子單據(jù)、實(shí)名制證件影像、報(bào)賬電子單據(jù)、應(yīng)用日志等大數(shù)據(jù)存儲(chǔ)。

2.3.2 部分非核心應(yīng)用遷移至云平臺(tái)

承載實(shí)時(shí)及離線批量處理業(yè)務(wù)，包括清單處理、離線數(shù)據(jù)云存儲(chǔ)、電子化單據(jù)、賬單等。平臺(tái)資源自助申請(qǐng)、統(tǒng)一分配、統(tǒng)一監(jiān)控（如圖1所示）。

通過建立統(tǒng)一的、集中化的業(yè)務(wù)承載平臺(tái)，集中的為客戶和內(nèi)部生產(chǎn)提供詳單、賬單、訂單、用戶回執(zhí)、系統(tǒng)日志等歷史數(shù)據(jù)的查詢服務(wù)，滿足現(xiàn)有CRM、網(wǎng)廳、掌廳、客服、自助服務(wù)系統(tǒng)、營銷分析等系統(tǒng)對(duì)歷史數(shù)據(jù)的壓縮存儲(chǔ)、查詢性能以及節(jié)省資源等方面的要求。

圖1 應(yīng)用云平臺(tái)框架（CRM為例）

同時(shí)，清單處理量大幅增加、7×24 h不間斷服務(wù)。減輕因日益增長的用戶數(shù)、查詢請(qǐng)求、資源消耗等給生產(chǎn)系統(tǒng)，如計(jì)費(fèi)、CRM等帶來的壓力。以CRM為例：

（1）歷史訂單：歷史訂單數(shù)量較大，保存在關(guān)系型數(shù)據(jù)庫中，對(duì)CRM系統(tǒng)的性能影響較大，可遷移到基于Hadoop的云存儲(chǔ)平臺(tái)，一方面減輕了CRM數(shù)據(jù)庫的壓力，另一方面提高了歷史訂單查詢體驗(yàn)的感知。

（2）電子回執(zhí)：電子回執(zhí)數(shù)據(jù)存儲(chǔ)在Apache Hadoop的HDFS分布式文件系統(tǒng)中，提供更高的讀寫性能，節(jié)省RDBMS存儲(chǔ)空間及處理能力。

（3）應(yīng)用日志：對(duì)抽取到的應(yīng)用日志數(shù)據(jù)，基于Hadoop的MapReduce對(duì)業(yè)務(wù)系統(tǒng)日志進(jìn)行分析，得到業(yè)務(wù)系統(tǒng)的實(shí)時(shí)運(yùn)行狀態(tài)數(shù)據(jù)，確保業(yè)務(wù)系統(tǒng)的穩(wěn)定運(yùn)行。

2.3.3 建立混搭型大數(shù)據(jù)平臺(tái)

選取基礎(chǔ)數(shù)據(jù)量較大，關(guān)聯(lián)、聚合計(jì)算量較大的專題，此類數(shù)據(jù)轉(zhuǎn)移到Hadoop大數(shù)據(jù)平臺(tái)中。如基于清單級(jí)的計(jì)算分析。

Hadoop平臺(tái)與傳統(tǒng)數(shù)據(jù)庫能力互補(bǔ)，Hadoop在海量、非結(jié)構(gòu)化數(shù)據(jù)運(yùn)算場景上具有優(yōu)勢（如表2所示），因此為了應(yīng)對(duì)越來越大的數(shù)據(jù)量，越來越豐富的數(shù)據(jù)類型，可逐步引進(jìn)Hadoop平臺(tái)，分擔(dān)傳統(tǒng)數(shù)據(jù)倉庫的壓力（如圖2所示）。

圖2 Hadoop與傳統(tǒng)數(shù)據(jù)庫混合平臺(tái)

但是目前基于Hadoop的數(shù)據(jù)挖掘工具和報(bào)表工具還比較少，所以建議將計(jì)算結(jié)果還是存放在傳統(tǒng)DB或者M(jìn)PP數(shù)據(jù)倉庫里，方便客戶端應(yīng)用訪問。

表2 主要數(shù)據(jù)庫軟件對(duì)比

2.3.4 選用成熟開源免費(fèi)軟件

推進(jìn)成熟開源免費(fèi)軟件替代部分商業(yè)軟件進(jìn)程（“去O”）。統(tǒng)一規(guī)劃、驗(yàn)證開源免費(fèi)軟件，包括CentOS、Hadoop、MySQL、Kettle、Ganglia、Xen、Luence。

PC集群+開源軟件+自主研發(fā)，顯著降低IOE軟硬件成本投入。

2.3.5 建立配套運(yùn)維機(jī)制

統(tǒng)一規(guī)劃硬件配置，通過IT服務(wù)管理實(shí)現(xiàn)池化管理。同時(shí)培養(yǎng)自有技術(shù)力量，進(jìn)行運(yùn)營式開發(fā)與集成。

3 運(yùn)營商“去IOE”成效

初期在投入同比基本持平（成本結(jié)構(gòu)發(fā)生變化）的情況下，能夠從容應(yīng)對(duì)數(shù)據(jù)及服務(wù)量高速增長的考驗(yàn)，響應(yīng)效率逐步提高。預(yù)計(jì)在技術(shù)、團(tuán)隊(duì)、應(yīng)用改造取得大規(guī)模進(jìn)展的情況下，IT系統(tǒng)建設(shè)成本會(huì)有明顯下降。

3.1 成本基本持平

某運(yùn)營商應(yīng)用實(shí)踐表明，以擁有60臺(tái)左右PC服務(wù)器的云計(jì)算資源池為例，可以部署950～1 250個(gè)虛擬機(jī)，CPU利用率由傳統(tǒng)架構(gòu)的小于10%上升到大于40%，網(wǎng)絡(luò)利用率由傳統(tǒng)架構(gòu)的小于1%上升到大于10%。

操作系統(tǒng)功耗由傳統(tǒng)架構(gòu)的大于350 W下降到小于100W。以上述資源池為例，服務(wù)器滿負(fù)荷運(yùn)行后，一年可節(jié)省電力約27×105～36×105kWh。

基礎(chǔ)設(shè)施投入顯著下降；云化釋放高端硬件；應(yīng)用改造大量投入。

3.2 感知顯著上升

以某運(yùn)營商清單系統(tǒng)性能對(duì)比為例，如表3所示。

表3 Hadoop與MPP架構(gòu)對(duì)比

主要性能指標(biāo)有一個(gè)數(shù)量級(jí)的提升，數(shù)據(jù)永久在線，無單點(diǎn)故障，線性橫向擴(kuò)展。清單云效果超越預(yù)期，系統(tǒng)平穩(wěn)運(yùn)行。

關(guān)鍵服務(wù)能力提升。數(shù)據(jù)永久在線。

3.3 效率持續(xù)提升

提升業(yè)務(wù)系統(tǒng)部署效率，可做到即需即用。系統(tǒng)平均部署時(shí)間由180天下降到5天；提高業(yè)務(wù)系統(tǒng)的靈活度。

通過平臺(tái)化機(jī)制來統(tǒng)一解決IT的安全保障問題，設(shè)備發(fā)生故障后，可以快速恢復(fù)；設(shè)備負(fù)載過重時(shí)，可以分擔(dān)負(fù)載，大大提高業(yè)務(wù)系統(tǒng)的可用性和可靠性。

“加PC就能”的線性擴(kuò)展架構(gòu)，預(yù)留充分?jǐn)U展能力。

運(yùn)營式集成快速交付。

4 運(yùn)營商“去IOE”風(fēng)險(xiǎn)分析

基于“去IOE”模式的IT系統(tǒng)設(shè)計(jì)、運(yùn)行維護(hù)、故障定位及處理和傳統(tǒng)模式有很大區(qū)別，同時(shí)應(yīng)用系統(tǒng)也要做大量改造，需要綜合考慮這些問題如何解決。

（1）人才技術(shù)稀缺。Oracle團(tuán)隊(duì)的經(jīng)驗(yàn)和技術(shù)積累將大量丟棄；開源數(shù)據(jù)庫經(jīng)驗(yàn)、技術(shù)和能力需要快速提高；開源業(yè)務(wù)中間如JBOSS的能力儲(chǔ)備。

（2）大量應(yīng)用改造?！叭OE”必然造成我們對(duì)同類產(chǎn)品的二次研發(fā)投入。在需要維持現(xiàn)有平臺(tái)對(duì)運(yùn)營商日常需求的正常承接的背景下，“去IOE”的研發(fā)人員如何保障。

（3）架構(gòu)設(shè)計(jì)更綜合。小型機(jī)存儲(chǔ)的高冗余機(jī)制在PC和MySQL的組合中如何實(shí)現(xiàn)。Oracle物理級(jí)別一致性在MySQL語句模式中是否有問題。高端存儲(chǔ)的IO能力很強(qiáng)，PC能否替代。MySQL和Oracle對(duì)SQL的處理性能是否相同。分庫與分表按照什么維度分，需要去考慮后期二次拆分怎樣才方便。如何屏蔽分表給應(yīng)用帶來的復(fù)雜性，維度查詢問題，跨分表查詢問題這些需要提前考慮到。

（4）運(yùn)維模式差異大。傳統(tǒng)的分工界面、工作流程、應(yīng)急預(yù)案等，都會(huì)隨著系統(tǒng)云化程度的加強(qiáng)而逐步變化，尤其是對(duì)于軟件的維護(hù)，將面臨巨大的，甚至是顛覆性的考驗(yàn)。

（5）核心系統(tǒng)全面“去IOE”復(fù)雜度高：業(yè)務(wù)復(fù)雜、高度關(guān)聯(lián)；異常處理、數(shù)據(jù)一致性要求高。

（6）考核標(biāo)準(zhǔn)需要確立：故障責(zé)任如何劃分，源的運(yùn)營責(zé)任如何確定。

5 結(jié)論

“去IOE”關(guān)系到技術(shù)架構(gòu)、管控體系、思維模式甚至企業(yè)激勵(lì)機(jī)制等方方面面，實(shí)際上是在運(yùn)營商IT支撐體系中植入互聯(lián)網(wǎng)基因，推動(dòng)企業(yè)的互聯(lián)網(wǎng)化，是一個(gè)全新的、十分復(fù)雜的課題。

（1）業(yè)務(wù)驅(qū)動(dòng)的“去IOE”容易成功。以客戶感知、擴(kuò)展能力、成本等因素驅(qū)動(dòng)為主。穩(wěn)定運(yùn)行、無擴(kuò)容壓力的應(yīng)用不適合“去IOE”。

（2）互聯(lián)網(wǎng)思維是關(guān)鍵?；旌霞軜?gòu)可快速見效，是近期解決業(yè)務(wù)問題的有效、可靠途徑。微創(chuàng)新帶來大收益，在投入同比基本持平的情況下，能夠從容應(yīng)對(duì)數(shù)據(jù)及服務(wù)量高速增長的考驗(yàn)。

（3）“去IOE”適宜統(tǒng)一規(guī)劃與管控。技術(shù)資源稀缺。云規(guī)模效應(yīng)與大數(shù)據(jù)充分共享。

[1]SanjayGhemawat, HowardGobioff, andShun-TakLeung, Google, The Google File System.

[2]Borthakur D.Hadoop distributed file system.http://hadoop.apache.org/，2007.

[3]吳朱華.云計(jì)算核心技術(shù)剖析[M].北京：人民郵電出版社，2011.

[4]陳強(qiáng).“去IOE化”與“一去兩化”[N].江蘇郵電報(bào)，2013.

[5]淘寶分布式服務(wù)框架[EB/OL].[2014-3-11].http://alibaba.github.io/dubbo-doc-static/Home-zh.htm

[7]Eric Brewer.Towards Robust Distributed Systems[R].Keynote at the ACM Symposium on Principles of Distributed Computing （PODC), 2000.

[8]Leslie Lamport: Paxos Made Simple, Fast, and Byzantine[C].OPODIS 2002:7-9.

[9]Leslie Lamport: The Part-Time Parliament [J].ACM Trans.Comput.Syst.（TOCS) , 1998, 16（2):133-169.

[10]Todd Lipcon.Design Patterns for Distributed Non-relational Databases [R].2009.

[11]王珊，薩師煊.數(shù)據(jù)庫系統(tǒng)概論[M].北京: 高等教育出版社, 2007.

[12]Julian Browne.Brewer`s CAP Theorem [EB/OL].（2009-01-11)[2012-06-20].http://www.julianbrowne.com/article/viewer/brewers-cap-theorem.

[13]Guy Pardon.A CAP Solution （Proving Brewer Wrong) [EB/OL].（2008-09-07)[2012-06-20].http://guysblogspot.blogspot.com/2008/09/cap-solution-proving-brewer-wrong.html.

[14]Basho.Why Vector Clock are Easy [EB/OL].（2010-01-29)[2012-06-20].http://basho.com/blog/technical/2010/01/29/why-vector-clocks-are-easy/.