(完整版)數(shù)據(jù)架構(gòu)規(guī)劃

數(shù)據(jù)架構(gòu)規(guī)劃

一．當(dāng)前架構(gòu)

結(jié)合研發(fā)二部數(shù)據(jù)量最大的校訊通產(chǎn)品來描述，其他的產(chǎn)品在性能上出現(xiàn)瓶

頸，可以向校訊通靠攏。

數(shù) 據(jù)庫整體架構(gòu)：目前校訊通產(chǎn)品根據(jù)用戶量的多少以及數(shù)據(jù)庫服務(wù)資源的繁

忙程度，橫向采用了歷史庫+當(dāng)前庫的分庫架構(gòu)或者單一的當(dāng)前庫架構(gòu)，其中歷

史庫只作 為web平臺(tái)讀數(shù)據(jù)庫，縱向結(jié)合了applications的

memcache+Syba ASE12.5傳統(tǒng)永久磁盤化數(shù)據(jù)庫架構(gòu)。

數(shù)據(jù)模型架構(gòu)：原則上采用了一事一地的數(shù)據(jù)模型（3NF范式），為了性能考

慮，一些大數(shù)據(jù)量表適當(dāng)?shù)囊昧藬?shù)據(jù)冗余，根據(jù)業(yè)務(wù)再結(jié)合采用了當(dāng)前表+歷

史表的數(shù)據(jù)模型。

以下就用圖表來進(jìn)行當(dāng)前數(shù)據(jù)架構(gòu)的說明：

橫向分庫數(shù)據(jù)庫架構(gòu)圖：

縱向app layer+memcache layler+disk db layer圖：

其中web層指的是客戶端瀏覽器層，邏輯上：app層指的是應(yīng)用服務(wù)層，mc

層指的是memcache的客戶端層，ms層指的是memcache的服務(wù)層，db層

指的是目前永久磁盤化的數(shù)據(jù)庫層，當(dāng)然在物理機(jī)器上可能app層跟mc層，

ms層是重疊的部署在相同服務(wù)器上。

數(shù)據(jù)模型架構(gòu)圖：

其中以上數(shù)據(jù)模型中除了少數(shù)幾張表外其他的都有歷史表存在，當(dāng)然有很多

表是沒在這個(gè)模型圖中的，這部分是核心數(shù)據(jù)模型。這部分模型對(duì)象中也包括了

一些冗余 性的設(shè)計(jì)，比如用戶中有真實(shí)姓名，特別是不在這個(gè)模型內(nèi)，由模型

核心表產(chǎn)生的一些統(tǒng)計(jì)報(bào)表，為了查詢的性能冗余了合理一些學(xué)校名稱，地區(qū)名

稱等方面的設(shè) 計(jì)。

二．劣勢(shì)現(xiàn)象

1.流水表性能瓶頸

當(dāng)前架構(gòu)的性能瓶頸集中在流水表的訪問上，最大流水表的記錄量達(dá)到了超

5億級(jí)別，這是由于目前外網(wǎng)在用的syba數(shù)據(jù)庫系統(tǒng)版本，沒有采取很好的

關(guān)于 分區(qū)的技術(shù)。曾經(jīng)有過把流水表進(jìn)行物理水平分割，把不同月份的數(shù)據(jù)分

割放在不同的物理表上的模型改造設(shè)想，礙于產(chǎn)生的應(yīng)用程序修改工作量大，老

舊數(shù)據(jù)遷移 的麻煩，再加上進(jìn)行了從單庫架構(gòu)改造到分庫架構(gòu)后，數(shù)據(jù)庫性能

瓶頸就不是特別突出。所以模型改造這部分工作沒展開。

無 論是單庫或是分庫的模式，出現(xiàn)平臺(tái)訪問數(shù)據(jù)庫的性能瓶頸依然集中在大流

水表上，在訪問高峰高并發(fā)量情況下，短信的流水表進(jìn)程堵塞，數(shù)據(jù)庫服務(wù)

I/O ,CPU的資源耗費(fèi)達(dá)到頂點(diǎn)，在服務(wù)器硬件環(huán)境不是特別理想情況下，出現(xiàn)

了一定概率造成用戶訪問緩慢甚至覺得頁面無法響應(yīng)現(xiàn)象，造成了用戶體念不良

影響。

2. 運(yùn)營維護(hù)難點(diǎn)

1)歷史數(shù)據(jù)清理運(yùn)維工作

為了存儲(chǔ)充分利用，為了性能的提升，需要定期進(jìn)行不再使用的歷史數(shù)據(jù)清

理，

由 于清理的數(shù)據(jù)量龐大，傳統(tǒng)的數(shù)據(jù)清理方法根本不可能保證一個(gè)晚上有效清

理完畢，確保平臺(tái)第二天正常的運(yùn)行。雖然目前已經(jīng)實(shí)行了比較高效且可行的數(shù)

據(jù)清理方 法，但是每次實(shí)行都需要晚上到通宵進(jìn)行處理，使得數(shù)據(jù)清理的運(yùn)維

工作特別勞累，影響到運(yùn)維人員第二天的正常出勤，間接就有可能影響到數(shù)據(jù)庫

的正常運(yùn)維監(jiān) 控，導(dǎo)致數(shù)據(jù)庫問題出現(xiàn)。

2)防止索引失效而進(jìn)行的統(tǒng)計(jì)量更新運(yùn)維工作

由于流水表數(shù)據(jù)變動(dòng)量大，容易導(dǎo)致流水表的索引失效，從而需要定期的進(jìn)

行索引甚至整表的統(tǒng)計(jì)量更新工作，統(tǒng)計(jì)量更新時(shí)間跟流水表的數(shù)據(jù)總量成正比

關(guān)系，所 以導(dǎo)致統(tǒng)計(jì)量更新速度比較慢，不能確保在計(jì)劃時(shí)間內(nèi)，統(tǒng)計(jì)量更新

的完全成功，而且目前外網(wǎng)安裝的syba12.5版本是最低一個(gè)的EBF版本，存

在較 多BUG,在索引統(tǒng)計(jì)量更新過程中可能導(dǎo)致數(shù)據(jù)庫出現(xiàn)病態(tài)，進(jìn)而影響第

二天數(shù)據(jù)庫的正常運(yùn)行。

3.運(yùn)維監(jiān)控紕漏（此部分非架構(gòu)原因引起）

當(dāng)前的數(shù)據(jù)庫監(jiān)控以及運(yùn)維維護(hù)還存在一些紕漏，出現(xiàn)了多次數(shù)據(jù)庫設(shè)備空

間使用完畢，沒有及時(shí)添加數(shù)據(jù)庫設(shè)備空間導(dǎo)致數(shù)據(jù)庫掛起問題，也多次出現(xiàn)了

數(shù)據(jù)庫日 志空間占滿導(dǎo)致數(shù)據(jù)庫掛起問題。此類問題還是比較明顯，還有一類

問題，不是整庫掛起，而是部分業(yè)務(wù)表訪問異常，運(yùn)維可能監(jiān)控不到，等用戶訪

問到了這部分業(yè) 務(wù)功能不正常，由用戶反饋到運(yùn)維這邊。

4.運(yùn)營統(tǒng)計(jì)報(bào)表在當(dāng)前數(shù)據(jù)模型架構(gòu)下重用性較低

由于用戶需求的漸進(jìn)性，導(dǎo)致數(shù)據(jù)庫統(tǒng)計(jì)報(bào)表在數(shù)據(jù)模型設(shè)計(jì)時(shí)沒有站在至

高點(diǎn)，隨著用戶需求的不斷積累，數(shù)據(jù)庫統(tǒng)計(jì)報(bào)表對(duì)象也跟著不斷積累，發(fā)現(xiàn)目

前存在比較大一部分的統(tǒng)計(jì)報(bào)表數(shù)據(jù)在不同數(shù)據(jù)庫對(duì)象之間重復(fù)統(tǒng)計(jì)，沒有充分

發(fā)揮統(tǒng)計(jì)數(shù)據(jù)的重用性。

5.沒利用集群技術(shù)

當(dāng)前的數(shù)據(jù)庫架構(gòu)還沒采用成熟的集群技術(shù)，集群技術(shù)并不單單指單一數(shù)據(jù)

庫系統(tǒng)的集群，可以混合集群，比如內(nèi)存數(shù)據(jù)庫跟傳統(tǒng)永久磁盤化數(shù)據(jù)庫系統(tǒng)集

群。

6.分庫架構(gòu)還可完善

當(dāng)前的分庫架構(gòu)還可以繼續(xù)完善，引用成熟的數(shù)據(jù)庫主從分離，讀寫分離技

術(shù)。

7.內(nèi)存數(shù)據(jù)庫技術(shù)還沒充分利用

當(dāng)前的數(shù)據(jù)庫架構(gòu)雖然在前端使用了memcache技術(shù)，但是還可以繼續(xù)完

善使用內(nèi)存數(shù)據(jù)庫技術(shù)再結(jié)合異步寫技術(shù)，使得架構(gòu)相得益彰。

8.適合海量數(shù)據(jù)高并發(fā)讀寫，高效率存儲(chǔ)的非關(guān)系型數(shù)據(jù)庫沒充分利用

當(dāng)前的數(shù)據(jù)庫架構(gòu)還沒采用正在興起的NoSql，NewSql技術(shù)（目前部分外

圍系統(tǒng)采用了mongodb來做試驗(yàn)品，而這部分系統(tǒng)的數(shù)據(jù)量并不大，非關(guān) 系

型數(shù)據(jù)庫海量數(shù)據(jù)高并發(fā)訪問的高效性優(yōu)勢(shì)沒有體現(xiàn)出來，從而也沒掌握真正的

使用經(jīng)驗(yàn)），當(dāng)然這種數(shù)據(jù)庫也有缺點(diǎn)，就是數(shù)據(jù)庫事務(wù)一致性，數(shù)據(jù)庫的寫實(shí)

時(shí) 性和讀實(shí)時(shí)性，復(fù)雜的SQL查詢，特別是多表關(guān)聯(lián)查詢是無法滿足的。

三．改進(jìn)思路

在第二部分的劣勢(shì)現(xiàn)象中，總結(jié)了當(dāng)前數(shù)據(jù)庫架構(gòu)以及數(shù)據(jù)模型架構(gòu)的缺陷，

缺陷還比較多，從另外一個(gè)角度也反映了公司產(chǎn)品數(shù)據(jù)庫架構(gòu)改進(jìn)和提升的空間

還比較大，將來隨著不斷的迭代改進(jìn)，可以承受的業(yè)務(wù)量提升的空間也相應(yīng)的比

較大。

下面就根據(jù)劣勢(shì)現(xiàn)象進(jìn)行針對(duì)性的闡述改進(jìn)思路：

1.流水表性能瓶頸改進(jìn)

Syba12.5沒有很好的解決大數(shù)據(jù)量表的性能問題，但是通過數(shù)據(jù)庫轉(zhuǎn)到

Oracle后，充分利用Oracle分區(qū)表，分區(qū)索引的特性來提升流水表 的訪問性

能，邏輯上表仍然是一張完整的表，只是將表中的數(shù)據(jù)在物理上存放到多個(gè)表空

間(物理文件上，這樣查詢數(shù)據(jù)時(shí)，不至于每次都掃描整張表。由于邏輯上 仍舊

一表，使得應(yīng)用程序不需要修改，也避免了這個(gè)劣勢(shì)點(diǎn)描述的帶來額外許多開發(fā)

工作量的問題，但是效果幾乎等同水平分割數(shù)據(jù)模型。

2.大流水表運(yùn)維難的改進(jìn)

1)歷史數(shù)據(jù)清理運(yùn)維工作

在Oracel數(shù)庫系統(tǒng)中，針對(duì)對(duì)大流水表每個(gè)月的數(shù)據(jù)進(jìn)行分區(qū)，這樣運(yùn)維

人員在清理歷史月份的數(shù)據(jù)時(shí)候，只要通過TRUNCATE PARTITION、 DROP

PARTITION的Oracle本身的分區(qū)維護(hù)命令輕松快速清理掉分區(qū)的數(shù)據(jù)（既指

定月份的流水?dāng)?shù)據(jù)）

2)防止索引失效而進(jìn)行的統(tǒng)計(jì)量更新運(yùn)維工作

同樣Oracle也有等同于syba的統(tǒng)計(jì)量更新工作，在Oracle中通過對(duì)大

流水表的分區(qū)工作后，進(jìn)行統(tǒng)計(jì)量的更新工作同樣就快捷簡易，可以通過

ANALYZE PARTITION的統(tǒng)計(jì)量分析維護(hù)命令可以輕松快速對(duì)指定分區(qū)的統(tǒng)計(jì)

量進(jìn)行更新。

3.運(yùn)維監(jiān)控紕漏的改進(jìn)

主要分兩個(gè)方面：a)數(shù)據(jù)庫剩余空間方面的監(jiān)控；b)數(shù)據(jù)庫出錯(cuò)日志的監(jiān)控。

這兩個(gè)監(jiān)控雖然通過人為主動(dòng)性的查看數(shù)據(jù)庫相關(guān)信息可以監(jiān)控到，但是總歸還

是 會(huì)有疏忽遺漏的時(shí)候，只是出問題幾率高低之分。所以這里再加一道監(jiān)控，

就是通過數(shù)據(jù)庫服務(wù)器端的監(jiān)控程序主動(dòng)發(fā)回有問題或者告警的信息給運(yùn)維人

員。這道監(jiān) 控程序可以通過shell程序以及數(shù)據(jù)庫程序，結(jié)合數(shù)據(jù)庫日志以及

剩余空間信息以短信或者郵件的方式發(fā)回給運(yùn)維人員。在數(shù)據(jù)庫剩余空間方面甚

至可以通過數(shù) 據(jù)庫本身閥值的設(shè)置，做到自動(dòng)截取日志，自動(dòng)添加設(shè)備。

4.運(yùn)營統(tǒng)計(jì)報(bào)表數(shù)據(jù)模型的改進(jìn)

由于原先一些報(bào)表模型存在著數(shù)據(jù)統(tǒng)計(jì)的重復(fù)性，在晚上定時(shí)task中既占用

了任務(wù)列表的總時(shí)間，也對(duì)其他并行的task運(yùn)行造成了一定的資源爭(zhēng)用，影響

了 數(shù)據(jù)庫性能。所以在這里提出了一種類似蒲公英性質(zhì)的模型，數(shù)據(jù)通過發(fā)散

模式，即插即用到不同的運(yùn)營統(tǒng)計(jì)報(bào)表中，勢(shì)必需要改進(jìn)當(dāng)前接近一事一地的3

范式模 型，把原先的數(shù)據(jù)模型拆散，從縱向和橫向都接近最小粒度需求的數(shù)據(jù)

模型。使得統(tǒng)計(jì)數(shù)據(jù)可以重復(fù)使用，不同的統(tǒng)計(jì)報(bào)表通過這些原子性的統(tǒng)計(jì)數(shù)據(jù)

再組合成報(bào)表 所需要的數(shù)據(jù)，當(dāng)然這里需要一個(gè)平衡，并不完全等同蒲公英模

型的統(tǒng)計(jì)粒度越細(xì)越好，因?yàn)樵郊?xì)也代表著原始的統(tǒng)計(jì)數(shù)據(jù)量越大，一會(huì)影響原

始統(tǒng)計(jì)的性能，二會(huì) 影響組合成報(bào)表的性能，三會(huì)占用更多的存儲(chǔ)空間。這個(gè)

平衡度需要掌控好。

5.利用集群技術(shù)

當(dāng)然通過了前面4點(diǎn)的改進(jìn)之后，數(shù)據(jù)庫性能會(huì)比目前的架構(gòu)提升一定的性

能，至于集群技術(shù)就可以作為前面4點(diǎn)改進(jìn)后的補(bǔ)充和擴(kuò)展，如果在改進(jìn)后，依

然還存在 較大性能瓶頸情況下可以采用Oracle RAC技術(shù)。甚至采用基于內(nèi)存

數(shù)據(jù)庫的分布式數(shù)據(jù)庫架構(gòu)的混合集群技術(shù)。比如在Oracle數(shù)據(jù)庫及Web服

務(wù)之間加一層 Ameoba 分布式數(shù)據(jù)庫代 理結(jié)合內(nèi)存數(shù)據(jù)庫的架構(gòu)，

6.分庫架構(gòu)完善改進(jìn)

目前的數(shù)據(jù)庫架構(gòu)采用了分庫方式，但是主庫（當(dāng)前庫）的讀寫卻是沒有分

離的，縱觀淘寶的數(shù)據(jù)庫架構(gòu)演進(jìn)歷程，確是在某個(gè)歷程碑點(diǎn)做到了很好的讀寫

分離，應(yīng) 用到DB的數(shù)據(jù)寫入與查詢從雙向通行變成了單向通行，通行效率更

高，大大避免了相互影響。“借道行駛”的情況不再出現(xiàn)。淘寶那個(gè)碑點(diǎn)做到了

以下幾點(diǎn)：

1)寫庫為集中式的oracle環(huán)境,提供數(shù)據(jù)安全性保障。

2)讀庫使用mysql, 采用數(shù)據(jù)分片，分庫分表，每臺(tái)mysql放少量的數(shù)據(jù),單個(gè)

數(shù)據(jù)分片內(nèi)部采用mysql復(fù)制機(jī)制。

3)讀庫的超大memory容量，起到了很好的cache作用，在內(nèi)存中的數(shù)據(jù)查詢

性能遠(yuǎn)遠(yuǎn)高于在硬盤上的性能

4)oracle到多臺(tái)mysql按規(guī)則復(fù)制

結(jié)合淘寶架構(gòu)的思考，校訊通大流水也可以做到垂直分割到不同的服務(wù)器，也可

以做到水品分割到不同的服務(wù)器，通過不同的服務(wù)器訪問不同的流水表或者是不

同范圍數(shù)據(jù)的流水表，那提升性能是肯定的。不過也要平衡考慮到應(yīng)用程序開發(fā)

的簡便性。

7.內(nèi)存數(shù)據(jù)庫技術(shù)利用

常見的內(nèi)存數(shù)據(jù)庫產(chǎn)品包括商業(yè)版和免費(fèi)版兩類。商業(yè)版如：Altiba，

Timesten，Berkley DB等。他們?cè)陔娦牛鹑冢C券等高性能計(jì)算應(yīng)用中運(yùn)用

較為廣泛。商業(yè)版功能強(qiáng)大，然而，價(jià)格比較昂貴，不適合目前“廉價(jià)PC+免

費(fèi)軟件”的架構(gòu)搭建思 想。

開源領(lǐng)域產(chǎn)品主要有H2，HsqlDB，Derby，BerkeleyDB 等。在混合集群架構(gòu)

中，內(nèi)存數(shù)據(jù)庫將承擔(dān)OLTP的職責(zé)，因此除了讀寫性能外，功能的完備，事務(wù)

等都需要作為優(yōu)先評(píng)估的因素。

盛傳H2是一個(gè)開源的高性能內(nèi)存數(shù)據(jù)庫，可以通過整合 Ameoba 與 H2，夾

在applications和傳統(tǒng)db層之間來達(dá)到內(nèi)存數(shù)據(jù)庫層的架構(gòu)部署。

Ameoba 是分布式數(shù)據(jù)庫代理，它與 MySQL 整合已經(jīng)在阿里巴巴核心業(yè)務(wù)中

成功運(yùn)用。如果僅將數(shù)據(jù)庫節(jié)點(diǎn)看作一個(gè)存儲(chǔ)，MySQL Node 和 H2 Node 并

無本質(zhì)區(qū)別。JDBC驅(qū)動(dòng)，DB切分，路由，皆由Ameoba 統(tǒng)一負(fù)責(zé)。

8.非關(guān)系型數(shù)據(jù)庫的使用

外圍的非核心數(shù)據(jù)，但是數(shù)據(jù)量又是比較大的的業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫可以采用非

關(guān)系型數(shù)據(jù)庫，這是由非關(guān)系型數(shù)據(jù)庫的一些基本特性決定的。

非關(guān)系型數(shù)據(jù)庫有滿足如下需求的優(yōu)點(diǎn)特性：

1)High performance - 對(duì)數(shù)據(jù)庫高并發(fā)讀寫的需求

2)Huge Storage - 對(duì)海量數(shù)據(jù)的高效率存儲(chǔ)和訪問的需求

3)High Scalability && High Availability- 對(duì)數(shù)據(jù)庫的高可擴(kuò)展性和高可用性

的需求

但同時(shí)伴隨不能滿足以下需求的缺點(diǎn)：

1)數(shù)據(jù)庫事務(wù)一致性需求

2)數(shù)據(jù)庫的寫實(shí)時(shí)性和讀實(shí)時(shí)性需求

3)對(duì)復(fù)雜的SQL查詢，特別是多表關(guān)聯(lián)查詢的需求

正 是由于以上的優(yōu)缺點(diǎn)也決定了，核心的需要保持一致性的數(shù)據(jù)，需要復(fù)雜關(guān)

聯(lián)的數(shù)據(jù)，需要實(shí)時(shí)訪問的數(shù)據(jù)不要采用關(guān)系型數(shù)據(jù)庫，如果通過ETL把關(guān)系

型數(shù)據(jù)庫 的流水?dāng)?shù)據(jù)冗余基本信息，組成可以直接查詢的業(yè)務(wù)信息數(shù)據(jù)，導(dǎo)入

到非關(guān)系型數(shù)據(jù)庫后，那對(duì)海量流水?dāng)?shù)據(jù)的查詢速度提升空間是很大的。其中代

表型的非關(guān)系型 數(shù)據(jù)有Redis，Tokyo Cabinet，Cassandra，Voldemort，

MongoDB，Dynomite，HBa，CouchDB，Hypertable， Riak，Tin， Flare，

Lightcloud， KiokuDB，Scalaris， Kai，ThruDB等等非常之多。

四．架構(gòu)計(jì)劃

通過以上當(dāng)前架構(gòu)劣勢(shì)以及改進(jìn)思路的總結(jié)，改善的架構(gòu)計(jì)劃就比較清晰了，

以下還是通過橫向的整體數(shù)據(jù)庫架構(gòu)，縱向的整體數(shù)據(jù)庫架構(gòu)，以及數(shù)據(jù)模型的

架構(gòu)改進(jìn)來做為新的架構(gòu)計(jì)劃。

風(fēng)險(xiǎn)最小，改動(dòng)工作量最小的架構(gòu)就是改進(jìn)思路中以第4點(diǎn)和第5點(diǎn)之間為分

割線。這條分割線前的數(shù)據(jù)架構(gòu)基本不需要變動(dòng)，主要變動(dòng)的就是數(shù)據(jù)模型架構(gòu)

中的流水表對(duì)象，以及數(shù)據(jù)庫服務(wù)器后臺(tái)添加監(jiān)控以及智能處理的運(yùn)維程序工具。

主要改進(jìn)的數(shù)據(jù)模型流水表對(duì)象如下圖：

同樣進(jìn)行分區(qū)的還有其他的一些大流水表，這里不一一詳述，這些流水表從

syba進(jìn)入oracle的分區(qū)表，在數(shù)據(jù)庫轉(zhuǎn)型升級(jí)過程中完成。

還有一點(diǎn)就是關(guān)于數(shù)據(jù)庫監(jiān)控工具在架構(gòu)中的部署，如下圖所示：

以上架構(gòu)改進(jìn)計(jì)劃可以在一期中先完成。看運(yùn)行效果狀態(tài)，第5點(diǎn)之后的改進(jìn)計(jì)

劃幾乎就是架構(gòu)的重構(gòu)了，所以涉及的工作量更大，如果在第1，2，3，4點(diǎn)改

進(jìn)后數(shù)據(jù)庫運(yùn)行穩(wěn)定，后續(xù)的改進(jìn)，可以通過實(shí)驗(yàn)和應(yīng)用結(jié)合逐步實(shí)施起來，作

為應(yīng)付更大型的業(yè)務(wù)應(yīng)用技術(shù)儲(chǔ)備。

下面結(jié)合5，6，7，8點(diǎn)的改進(jìn)思路做個(gè)架構(gòu)規(guī)劃，也就是分布式的內(nèi)存與

傳統(tǒng)數(shù)據(jù)庫結(jié)合的混合集群架構(gòu)模式，再加上外圍產(chǎn)品的非關(guān)系型數(shù)據(jù)庫，如下

圖所示（服務(wù)器和db合為同個(gè)節(jié)點(diǎn)說明，否則圖片篇幅占用過大）：

上面的架構(gòu)圖中，application（應(yīng)用服務(wù)層），data cache層，disk db layer

層已經(jīng)實(shí)現(xiàn)，但是disk db Layer層的多數(shù)據(jù)庫集群技術(shù)還沒不能說正式實(shí)現(xiàn)，

雖然分庫技術(shù)有類似集群嫌疑，async write（異步寫）聽開發(fā)人員也已經(jīng)涉及

使用。那么此新架構(gòu)圖針對(duì)原架構(gòu)的改進(jìn)就是Memory DB Layer層以及類似

Ameoba （可以使用其他的代理）分布式數(shù)據(jù)庫代理還沒實(shí)現(xiàn)。Memory DB

Layer集群加上每個(gè)邏輯分區(qū)有兩個(gè)內(nèi)存庫是為了其中一個(gè)內(nèi)存數(shù)據(jù)庫一旦崩

潰，同一邏輯分區(qū)中的替補(bǔ)節(jié)點(diǎn)立即頂替工作，做到健壯的容錯(cuò)和 Failover機(jī)

制。這個(gè)架構(gòu)明顯比校訊通當(dāng)前在使用的架構(gòu)要復(fù)雜很多，穩(wěn)定性以及性能的提

升都有待實(shí)際驗(yàn)證，雖然單單從架構(gòu)上來講融合了目前很多的技 術(shù)優(yōu)點(diǎn)（集群，

內(nèi)存數(shù)據(jù)庫等）。