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

1、數(shù)據(jù)架構(gòu)規(guī)劃一當(dāng)前架構(gòu) 結(jié)合研發(fā)二部數(shù)據(jù)量最大的校訊通產(chǎn)品來(lái)描述，其他的產(chǎn)品在性能上出現(xiàn)瓶頸，可以向校訊通靠攏。數(shù) 據(jù)庫(kù)整體架構(gòu)：目前校訊通產(chǎn)品根據(jù)用戶量的多少以及數(shù)據(jù)庫(kù)服務(wù)資源的繁忙程度，橫向采用了歷史庫(kù)+當(dāng)前庫(kù)的分庫(kù)架構(gòu)或者單一的當(dāng)前庫(kù)架構(gòu)，其中歷史庫(kù)只作 為web平臺(tái)讀數(shù)據(jù)庫(kù)，縱向結(jié)合了applications的memcache+Sybase ASE12.5傳統(tǒng)永久磁盤化數(shù)據(jù)庫(kù)架構(gòu)。數(shù)據(jù)模型架構(gòu)：原則上采用了一事一地的數(shù)據(jù)模型（3NF范式），為了性能考慮，一些大數(shù)據(jù)量表適當(dāng)?shù)囊昧藬?shù)據(jù)冗余，根據(jù)業(yè)務(wù)再結(jié)合采用了當(dāng)前表+歷史表的數(shù)據(jù)模型。以下就用圖表來(lái)進(jìn)行當(dāng)前數(shù)據(jù)架構(gòu)的說(shuō)明：橫向分庫(kù)數(shù)據(jù)庫(kù)

2、架構(gòu)圖：縱向app layer+memcache layler+disk db layer圖：其中web層指的是客戶端瀏覽器層，邏輯上：app層指的是應(yīng)用服務(wù)層，mc層指的是memcache的客戶端層，ms層指的是memcache的服務(wù)層，db層指的是目前永久磁盤化的數(shù)據(jù)庫(kù)層，當(dāng)然在物理機(jī)器上可能app層跟mc層，ms層是重疊的部署在相同服務(wù)器上。數(shù)據(jù)模型架構(gòu)圖： 其中以上數(shù)據(jù)模型中除了少數(shù)幾張表外其他的都有歷史表存在，當(dāng)然有很多表是沒(méi)在這個(gè)模型圖中的，這部分是核心數(shù)據(jù)模型。這部分模型對(duì)象中也包括了一些冗余 性的設(shè)計(jì)，比如用戶中有真實(shí)姓名，特別是不在這個(gè)模型內(nèi)，由模型核心表產(chǎn)生的一些統(tǒng)計(jì)報(bào)表，

3、為了查詢的性能冗余了合理一些學(xué)校名稱，地區(qū)名稱等方面的設(shè) 計(jì)。二劣勢(shì)現(xiàn)象1.流水表性能瓶頸 當(dāng)前架構(gòu)的性能瓶頸集中在流水表的訪問(wèn)上，最大流水表的記錄量達(dá)到了超5億級(jí)別，這是由于目前外網(wǎng)在用的sybase數(shù)據(jù)庫(kù)系統(tǒng)版本，沒(méi)有采取很好的關(guān)于 分區(qū)的技術(shù)。曾經(jīng)有過(guò)把流水表進(jìn)行物理水平分割，把不同月份的數(shù)據(jù)分割放在不同的物理表上的模型改造設(shè)想，礙于產(chǎn)生的應(yīng)用程序修改工作量大，老舊數(shù)據(jù)遷移 的麻煩，再加上進(jìn)行了從單庫(kù)架構(gòu)改造到分庫(kù)架構(gòu)后，數(shù)據(jù)庫(kù)性能瓶頸就不是特別突出。所以模型改造這部分工作沒(méi)展開(kāi)。無(wú) 論是單庫(kù)或是分庫(kù)的模式，出現(xiàn)平臺(tái)訪問(wèn)數(shù)據(jù)庫(kù)的性能瓶頸依然集中在大流水表上，在訪問(wèn)高峰高并發(fā)量情況下，短信

4、的流水表進(jìn)程堵塞，數(shù)據(jù)庫(kù)服務(wù)I/O ,CPU的資源耗費(fèi)達(dá)到頂點(diǎn)，在服務(wù)器硬件環(huán)境不是特別理想情況下，出現(xiàn)了一定概率造成用戶訪問(wèn)緩慢甚至覺(jué)得頁(yè)面無(wú)法響應(yīng)現(xiàn)象，造成了用戶體念不良影響。2. 運(yùn)營(yíng)維護(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ù)庫(kù)的正常運(yùn)維監(jiān) 控，導(dǎo)致數(shù)

5、據(jù)庫(kù)問(wèn)題出現(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)安裝的sybase12.5版本是最低一個(gè)的EBF版本，存在較 多BUG,在索引統(tǒng)計(jì)量更新過(guò)程中可能導(dǎo)致數(shù)據(jù)庫(kù)出現(xiàn)病態(tài)，進(jìn)而影響第二天數(shù)據(jù)庫(kù)的正常運(yùn)行。3.運(yùn)維監(jiān)控紕漏（此部分非架構(gòu)原因引起） 當(dāng)前的數(shù)據(jù)庫(kù)監(jiān)控以及運(yùn)維維護(hù)還存在一些紕漏，出現(xiàn)了多次數(shù)據(jù)庫(kù)設(shè)備空間使用完畢，沒(méi)有及時(shí)添加數(shù)據(jù)庫(kù)設(shè)備空間導(dǎo)致數(shù)據(jù)庫(kù)掛起

6、問(wèn)題，也多次出現(xiàn)了數(shù)據(jù)庫(kù)日 志空間占滿導(dǎo)致數(shù)據(jù)庫(kù)掛起問(wèn)題。此類問(wèn)題還是比較明顯，還有一類問(wèn)題，不是整庫(kù)掛起，而是部分業(yè)務(wù)表訪問(wèn)異常，運(yùn)維可能監(jiān)控不到，等用戶訪問(wèn)到了這部分業(yè) 務(wù)功能不正常，由用戶反饋到運(yùn)維這邊。4.運(yùn)營(yíng)統(tǒng)計(jì)報(bào)表在當(dāng)前數(shù)據(jù)模型架構(gòu)下重用性較低 由于用戶需求的漸進(jìn)性，導(dǎo)致數(shù)據(jù)庫(kù)統(tǒng)計(jì)報(bào)表在數(shù)據(jù)模型設(shè)計(jì)時(shí)沒(méi)有站在至高點(diǎn)，隨著用戶需求的不斷積累，數(shù)據(jù)庫(kù)統(tǒng)計(jì)報(bào)表對(duì)象也跟著不斷積累，發(fā)現(xiàn)目前存在比較大一部分的統(tǒng)計(jì)報(bào)表數(shù)據(jù)在不同數(shù)據(jù)庫(kù)對(duì)象之間重復(fù)統(tǒng)計(jì)，沒(méi)有充分發(fā)揮統(tǒng)計(jì)數(shù)據(jù)的重用性。5.沒(méi)利用集群技術(shù) 當(dāng)前的數(shù)據(jù)庫(kù)架構(gòu)還沒(méi)采用成熟的集群技術(shù)，集群技術(shù)并不單單指單一數(shù)據(jù)庫(kù)系統(tǒng)的集群，可以混合集群，

7、比如內(nèi)存數(shù)據(jù)庫(kù)跟傳統(tǒng)永久磁盤化數(shù)據(jù)庫(kù)系統(tǒng)集群。6.分庫(kù)架構(gòu)還可完善 當(dāng)前的分庫(kù)架構(gòu)還可以繼續(xù)完善，引用成熟的數(shù)據(jù)庫(kù)主從分離，讀寫分離技術(shù)。7.內(nèi)存數(shù)據(jù)庫(kù)技術(shù)還沒(méi)充分利用 當(dāng)前的數(shù)據(jù)庫(kù)架構(gòu)雖然在前端使用了memcache技術(shù)，但是還可以繼續(xù)完善使用內(nèi)存數(shù)據(jù)庫(kù)技術(shù)再結(jié)合異步寫技術(shù)，使得架構(gòu)相得益彰。8.適合海量數(shù)據(jù)高并發(fā)讀寫，高效率存儲(chǔ)的非關(guān)系型數(shù)據(jù)庫(kù)沒(méi)充分利用 當(dāng)前的數(shù)據(jù)庫(kù)架構(gòu)還沒(méi)采用正在興起的NoSql，NewSql技術(shù)（目前部分外圍系統(tǒng)采用了mongodb來(lái)做試驗(yàn)品，而這部分系統(tǒng)的數(shù)據(jù)量并不大，非關(guān) 系型數(shù)據(jù)庫(kù)海量數(shù)據(jù)高并發(fā)訪問(wèn)的高效性優(yōu)勢(shì)沒(méi)有體現(xiàn)出來(lái)，從而也沒(méi)掌握真正的使用經(jīng)驗(yàn)），當(dāng)然這種

8、數(shù)據(jù)庫(kù)也有缺點(diǎn)，就是數(shù)據(jù)庫(kù)事務(wù)一致性，數(shù)據(jù)庫(kù)的寫實(shí)時(shí) 性和讀實(shí)時(shí)性，復(fù)雜的SQL查詢，特別是多表關(guān)聯(lián)查詢是無(wú)法滿足的。三改進(jìn)思路 在第二部分的劣勢(shì)現(xiàn)象中，總結(jié)了當(dāng)前數(shù)據(jù)庫(kù)架構(gòu)以及數(shù)據(jù)模型架構(gòu)的缺陷，缺陷還比較多，從另外一個(gè)角度也反映了公司產(chǎn)品數(shù)據(jù)庫(kù)架構(gòu)改進(jìn)和提升的空間還比較大，將來(lái)隨著不斷的迭代改進(jìn)，可以承受的業(yè)務(wù)量提升的空間也相應(yīng)的比較大。下面就根據(jù)劣勢(shì)現(xiàn)象進(jìn)行針對(duì)性的闡述改進(jìn)思路：1.流水表性能瓶頸改進(jìn) Sybase12.5沒(méi)有很好的解決大數(shù)據(jù)量表的性能問(wèn)題，但是通過(guò)數(shù)據(jù)庫(kù)轉(zhuǎn)到Oracle后，充分利用Oracle分區(qū)表，分區(qū)索引的特性來(lái)提升流水表 的訪問(wèn)性能，邏輯上表仍然是一張完整的表，只

9、是將表中的數(shù)據(jù)在物理上存放到多個(gè)表空間(物理文件上，這樣查詢數(shù)據(jù)時(shí)，不至于每次都掃描整張表。由于邏輯上 仍舊一表，使得應(yīng)用程序不需要修改，也避免了這個(gè)劣勢(shì)點(diǎn)描述的帶來(lái)額外許多開(kāi)發(fā)工作量的問(wèn)題，但是效果幾乎等同水平分割數(shù)據(jù)模型。2.大流水表運(yùn)維難的改進(jìn) 1)歷史數(shù)據(jù)清理運(yùn)維工作 在Oracel數(shù)庫(kù)系統(tǒng)中，針對(duì)對(duì)大流水表每個(gè)月的數(shù)據(jù)進(jìn)行分區(qū)，這樣運(yùn)維人員在清理歷史月份的數(shù)據(jù)時(shí)候，只要通過(guò)TRUNCATE PARTITION、DROP PARTITION的Oracle本身的分區(qū)維護(hù)命令輕松快速清理掉分區(qū)的數(shù)據(jù)（既指定月份的流水?dāng)?shù)據(jù)） 2)防止索引失效而進(jìn)行的統(tǒng)計(jì)量更新運(yùn)維工作 同樣Oracle也有等

10、同于sybase的統(tǒng)計(jì)量更新工作，在Oracle中通過(guò)對(duì)大流水表的分區(qū)工作后，進(jìn)行統(tǒng)計(jì)量的更新工作同樣就快捷簡(jiǎn)易，可以通過(guò)ANALYZE PARTITION的統(tǒng)計(jì)量分析維護(hù)命令可以輕松快速對(duì)指定分區(qū)的統(tǒng)計(jì)量進(jìn)行更新。3.運(yùn)維監(jiān)控紕漏的改進(jìn) 主要分兩個(gè)方面：a)數(shù)據(jù)庫(kù)剩余空間方面的監(jiān)控；b)數(shù)據(jù)庫(kù)出錯(cuò)日志的監(jiān)控。這兩個(gè)監(jiān)控雖然通過(guò)人為主動(dòng)性的查看數(shù)據(jù)庫(kù)相關(guān)信息可以監(jiān)控到，但是總歸還是 會(huì)有疏忽遺漏的時(shí)候，只是出問(wèn)題幾率高低之分。所以這里再加一道監(jiān)控，就是通過(guò)數(shù)據(jù)庫(kù)服務(wù)器端的監(jiān)控程序主動(dòng)發(fā)回有問(wèn)題或者告警的信息給運(yùn)維人員。這道監(jiān) 控程序可以通過(guò)shell程序以及數(shù)據(jù)庫(kù)程序，結(jié)合數(shù)據(jù)庫(kù)日志以及剩余空

11、間信息以短信或者郵件的方式發(fā)回給運(yùn)維人員。在數(shù)據(jù)庫(kù)剩余空間方面甚至可以通過(guò)數(shù) 據(jù)庫(kù)本身閥值的設(shè)置，做到自動(dòng)截取日志，自動(dòng)添加設(shè)備。4.運(yùn)營(yíng)統(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ù)庫(kù)性能。所以在這里提出了一種類似蒲公英性質(zhì)的模型，數(shù)據(jù)通過(guò)發(fā)散模式，即插即用到不同的運(yùn)營(yíng)統(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)表通過(guò)這些原子性的統(tǒng)計(jì)數(shù)據(jù)再組合成報(bào)表 所

12、需要的數(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)然通過(guò)了前面4點(diǎn)的改進(jìn)之后，數(shù)據(jù)庫(kù)性能會(huì)比目前的架構(gòu)提升一定的性能，至于集群技術(shù)就可以作為前面4點(diǎn)改進(jìn)后的補(bǔ)充和擴(kuò)展，如果在改進(jìn)后，依然還存在 較大性能瓶頸情況下可以采用Oracle RAC技術(shù)。甚至采用基于內(nèi)存數(shù)據(jù)庫(kù)的分布式數(shù)據(jù)庫(kù)架構(gòu)的混合集群技術(shù)。比如在Oracle數(shù)據(jù)庫(kù)及Web服務(wù)之間加一層Ameoba分布式數(shù)據(jù)庫(kù)代 理結(jié)合內(nèi)存數(shù)據(jù)庫(kù)的架構(gòu)，6.分庫(kù)架構(gòu)完善改

13、進(jìn) 目前的數(shù)據(jù)庫(kù)架構(gòu)采用了分庫(kù)方式，但是主庫(kù)（當(dāng)前庫(kù)）的讀寫卻是沒(méi)有分離的，縱觀淘寶的數(shù)據(jù)庫(kù)架構(gòu)演進(jìn)歷程，確是在某個(gè)歷程碑點(diǎn)做到了很好的讀寫分離，應(yīng) 用到DB的數(shù)據(jù)寫入與查詢從雙向通行變成了單向通行，通行效率更高，大大避免了相互影響?！敖璧佬旭偂钡那闆r不再出現(xiàn)。淘寶那個(gè)碑點(diǎn)做到了以下幾點(diǎn)：1)寫庫(kù)為集中式的oracle環(huán)境,提供數(shù)據(jù)安全性保障。2)讀庫(kù)使用mysql, 采用數(shù)據(jù)分片，分庫(kù)分表，每臺(tái)mysql放少量的數(shù)據(jù),單個(gè)數(shù)據(jù)分片內(nèi)部采用mysql復(fù)制機(jī)制。3)讀庫(kù)的超大memory容量，起到了很好的cache作用，在內(nèi)存中的數(shù)據(jù)查詢性能遠(yuǎn)遠(yuǎn)高于在硬盤上的性能4)oracle到多臺(tái)mysql

14、按規(guī)則復(fù)制結(jié)合淘寶架構(gòu)的思考，校訊通大流水也可以做到垂直分割到不同的服務(wù)器，也可以做到水品分割到不同的服務(wù)器，通過(guò)不同的服務(wù)器訪問(wèn)不同的流水表或者是不同范圍數(shù)據(jù)的流水表，那提升性能是肯定的。不過(guò)也要平衡考慮到應(yīng)用程序開(kāi)發(fā)的簡(jiǎn)便性。7.內(nèi)存數(shù)據(jù)庫(kù)技術(shù)利用 常見(jiàn)的內(nèi)存數(shù)據(jù)庫(kù)產(chǎn)品包括商業(yè)版和免費(fèi)版兩類。商業(yè)版如：Altibase，Timesten，Berkley DB等。他們?cè)陔娦牛鹑?，證券等高性能計(jì)算應(yīng)用中運(yùn)用較為廣泛。商業(yè)版功能強(qiáng)大，然而，價(jià)格比較昂貴，不適合目前“廉價(jià)PC+免費(fèi)軟件”的架構(gòu)搭建思 想。開(kāi)源領(lǐng)域產(chǎn)品主要有H2，HsqlDB，Derby，BerkeleyDB等。在混合集群架構(gòu)中，

15、內(nèi)存數(shù)據(jù)庫(kù)將承擔(dān)OLTP的職責(zé)，因此除了讀寫性能外，功能的完備，事務(wù)等都需要作為優(yōu)先評(píng)估的因素。盛傳H2是一個(gè)開(kāi)源的高性能內(nèi)存數(shù)據(jù)庫(kù)，可以通過(guò)整合Ameoba與H2，夾在applications和傳統(tǒng)db層之間來(lái)達(dá)到內(nèi)存數(shù)據(jù)庫(kù)層的架構(gòu)部署。Ameoba是分布式數(shù)據(jù)庫(kù)代理，它與MySQL整合已經(jīng)在阿里巴巴核心業(yè)務(wù)中成功運(yùn)用。如果僅將數(shù)據(jù)庫(kù)節(jié)點(diǎn)看作一個(gè)存儲(chǔ)，MySQL Node和H2 Node并無(wú)本質(zhì)區(qū)別。JDBC驅(qū)動(dòng)，DB切分，路由，皆由Ameoba統(tǒng)一負(fù)責(zé)。8.非關(guān)系型數(shù)據(jù)庫(kù)的使用 外圍的非核心數(shù)據(jù)，但是數(shù)據(jù)量又是比較大的的業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫(kù)可以采用非關(guān)系型數(shù)據(jù)庫(kù)，這是由非關(guān)系型數(shù)據(jù)庫(kù)的一些基本特

16、性決定的。非關(guān)系型數(shù)據(jù)庫(kù)有滿足如下需求的優(yōu)點(diǎn)特性：1)High performance - 對(duì)數(shù)據(jù)庫(kù)高并發(fā)讀寫的需求2)Huge Storage - 對(duì)海量數(shù)據(jù)的高效率存儲(chǔ)和訪問(wèn)的需求3)High Scalability & High Availability- 對(duì)數(shù)據(jù)庫(kù)的高可擴(kuò)展性和高可用性的需求但同時(shí)伴隨不能滿足以下需求的缺點(diǎn)：1)數(shù)據(jù)庫(kù)事務(wù)一致性需求2)數(shù)據(jù)庫(kù)的寫實(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í)訪問(wèn)的數(shù)據(jù)不要采用關(guān)系型數(shù)據(jù)庫(kù)，如果通過(guò)ETL把關(guān)系型數(shù)據(jù)庫(kù) 的流水?dāng)?shù)據(jù)

17、冗余基本信息，組成可以直接查詢的業(yè)務(wù)信息數(shù)據(jù)，導(dǎo)入到非關(guān)系型數(shù)據(jù)庫(kù)后，那對(duì)海量流水?dāng)?shù)據(jù)的查詢速度提升空間是很大的。其中代表型的非關(guān)系型 數(shù)據(jù)有Redis，Tokyo Cabinet，Cassandra，Voldemort，MongoDB，Dynomite，HBase，CouchDB，Hypertable， Riak，Tin， Flare， Lightcloud， KiokuDB，Scalaris， Kai，ThruDB等等非常之多。四架構(gòu)計(jì)劃 通過(guò)以上當(dāng)前架構(gòu)劣勢(shì)以及改進(jìn)思路的總結(jié)，改善的架構(gòu)計(jì)劃就比較清晰了，以下還是通過(guò)橫向的整體數(shù)據(jù)庫(kù)架構(gòu)，縱向的整體數(shù)據(jù)庫(kù)架構(gòu)，以及數(shù)據(jù)模型的架構(gòu)改進(jìn)來(lái)做為

18、新的架構(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ù)庫(kù)服務(wù)器后臺(tái)添加監(jiān)控以及智能處理的運(yùn)維程序工具。主要改進(jìn)的數(shù)據(jù)模型流水表對(duì)象如下圖：同樣進(jìn)行分區(qū)的還有其他的一些大流水表，這里不一一詳述，這些流水表從sybase進(jìn)入oracle的分區(qū)表，在數(shù)據(jù)庫(kù)轉(zhuǎn)型升級(jí)過(guò)程中完成。還有一點(diǎn)就是關(guān)于數(shù)據(jù)庫(kù)監(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ù)庫(kù)運(yùn)行穩(wěn)定，后續(xù)的改進(jìn)，可以通過(guò)實(shí)驗(yàn)和應(yīng)用結(jié)合逐步實(shí)施起來(lái)，作為應(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ù)庫(kù)結(jié)合的混合集群架構(gòu)模式，再加上外圍產(chǎn)品的非關(guān)系型數(shù)據(jù)庫(kù)，如下圖所示（服務(wù)器和db合為同個(gè)節(jié)點(diǎn)說(shuō)明，否則圖片篇幅占用過(guò)大）： 上面的架構(gòu)圖中，application（應(yīng)用服務(wù)層），data cache層，disk db layer層已經(jīng)實(shí)現(xiàn)，但是disk db Laye