對(duì)于數(shù)據(jù)庫(kù)，要確保訪問(wèn)代碼能夠區(qū)分讀寫(xiě)操作應(yīng)用理由:復(fù)制數(shù)據(jù)和功能可以使事務(wù)更快地?cái)U(kuò)展。X軸拆分方法能夠快速實(shí)現(xiàn)，但是只能提高事務(wù)的擴(kuò)展性，不能提高數(shù)據(jù)的擴(kuò)展性。
系統(tǒng)最難擴(kuò)展的部分通常是數(shù)據(jù)庫(kù)或者持久存儲(chǔ)層。該問(wèn)題可以追溯到Edgar F.Codd于1970年發(fā)表的論文4 Relational Model of Date for Large Shared Data Banksl，該論文被認(rèn)為首次引人了關(guān)系數(shù)據(jù)庫(kù)管理系統(tǒng)(RDBMS)的概念。當(dāng)今最流行的RDBMS，如 Oracle、MYSQL和SQL Server等，如其名字所示，都用于管理數(shù)據(jù)元素之間的關(guān)系。這些關(guān)系可以存在于表內(nèi)，也可以存在于表之間。大多數(shù)聯(lián)機(jī)事務(wù)處理(OLTP)系統(tǒng)中的表都被規(guī)范化為第三范式?，即表中的所有記錄都有相同的字段，所有非關(guān)鍵字段都不能只依賴(lài)于組合關(guān)鍵字的一部分，所有非關(guān)鍵字段都必須依賴(lài)于關(guān)鍵字。表中的每一列數(shù)據(jù)與其他列數(shù)據(jù)是有關(guān)系的。表之間的關(guān)系，通常稱(chēng)為外鍵。大多數(shù)使用數(shù)據(jù)庫(kù)的應(yīng)用都有賴(lài)于數(shù)據(jù)庫(kù)基于其ACID屬性支持并實(shí)施這些關(guān)系。維護(hù)和實(shí)施這些關(guān)系使得拆分?jǐn)?shù)據(jù)庫(kù)需要很多工作。
擴(kuò)展數(shù)據(jù)庫(kù)的技術(shù)之一是利用大多數(shù)應(yīng)用和數(shù)據(jù)庫(kù)執(zhí)行的讀操作比寫(xiě)操作多這一事實(shí)。我們的一個(gè)客戶(hù)負(fù)責(zé)為顧客預(yù)定酒店，每次預(yù)定平均需要檢索400次。每個(gè)預(yù)定都是1次寫(xiě)操作，而每次檢索則是1次讀操作，這樣就導(dǎo)致了讀寫(xiě)比例為400:1。創(chuàng)建數(shù)據(jù)的只讀副本就可以輕松地?cái)U(kuò)展這種類(lèi)型的系統(tǒng)。
根據(jù)數(shù)據(jù)的時(shí)間敏感度，有兩種方法可以分布數(shù)據(jù)的只讀副本。所謂時(shí)間敏感度，指的是相對(duì)于數(shù)據(jù)的寫(xiě)副本來(lái)說(shuō)，只讀副本有多么新，或者是否完全正確。在你堅(jiān)持要求整個(gè)系統(tǒng)的數(shù)據(jù)是即時(shí)、同步且完全正確之前，仔細(xì)考慮一下這種系統(tǒng)的成本有多高吧。雖然完全同步數(shù)據(jù)是理想狀態(tài)，但它的成本真的很高。況且，這種情況的性?xún)r(jià)比可能也并不是你想要的。
讓我們?cè)倏纯茨莻€(gè)每寫(xiě)1次就需要400次讀操作的預(yù)定系統(tǒng)吧。它處理的是顧客的預(yù)定，所以你可能認(rèn)為他們要顯示給顧客的是完全同步的數(shù)據(jù)。首先，要給顧客提供的一條預(yù)定數(shù)據(jù)必須保持400個(gè)數(shù)據(jù)集同步。其次，數(shù)據(jù)與主事務(wù)數(shù)據(jù)庫(kù)之間有3秒、30秒或者90秒的不同步并不意味著該數(shù)據(jù)一定是錯(cuò)的，只是存在這種幾率。該客戶(hù)的系統(tǒng)中可能一直保存著10萬(wàn)條數(shù)據(jù)，每天預(yù)定的有10%。如果這些預(yù)定平均分布在一天中，那么大約一秒(0.86秒)完成一次預(yù)定。在機(jī)會(huì)均等的情況下，一位顧客想預(yù)定另一位顧客剛定的房間的可能性是0.1049%(假設(shè)數(shù)據(jù)每90秒同步一次)。當(dāng)然，顧客還有0.19%的可能性選擇已經(jīng)預(yù)定過(guò)的房間，雖然這不太理想，但在顧客把預(yù)定的房間加入購(gòu)物車(chē)之前再做次最后檢査就可以避免這種情況。當(dāng)然，每個(gè)應(yīng)用的數(shù)據(jù)需求都不同，但從我們的討論中，希望你能明白應(yīng)該如何抵制所有數(shù)據(jù)必須實(shí)時(shí)同步的想法。
討論過(guò)時(shí)間敏感度了，那么讓我們來(lái)看看分布數(shù)據(jù)的方法。一種方法是在數(shù)據(jù)庫(kù)前端使用緩存層。每次查詢(xún)可以讀取對(duì)象緩存，而不是每次都讀數(shù)據(jù)庫(kù)。只有當(dāng)數(shù)據(jù)被標(biāo)示為過(guò)期時(shí)，才需要查詢(xún)主事務(wù)數(shù)據(jù)庫(kù)，獲取數(shù)據(jù)，更新緩存?？紤]到有那么多優(yōu)秀開(kāi)源的鍵一值存儲(chǔ)系統(tǒng)可以作為對(duì)象緩存，所以首先強(qiáng)烈推薦這種方法。
除了在應(yīng)用層和數(shù)據(jù)庫(kù)層之間增設(shè)對(duì)象緩存之外，還可以通過(guò)復(fù)制數(shù)據(jù)庫(kù)來(lái)拆分?jǐn)?shù)據(jù)。大多數(shù)主要的關(guān)系數(shù)據(jù)庫(kù)系統(tǒng)都有某種類(lèi)型的復(fù)制功能。 MYSQL是通過(guò)主從數(shù)據(jù)庫(kù)的概念來(lái)實(shí)現(xiàn)復(fù)制功能的。所謂主數(shù)據(jù)庫(kù)就是執(zhí)行寫(xiě)操作的主要數(shù)據(jù)庫(kù)，從數(shù)據(jù)庫(kù)是主數(shù)據(jù)庫(kù)的只讀副本。主數(shù)據(jù)庫(kù)會(huì)把更新、插人、刪除等操作記錄在二進(jìn)制的日志中。每個(gè)從數(shù)據(jù)庫(kù)則是從主數(shù)據(jù)庫(kù)請(qǐng)求二進(jìn)制的日志，在自身重現(xiàn)這些操作。雖然這些操作是異步的，但是主數(shù)據(jù)庫(kù)和從數(shù)據(jù)庫(kù)中數(shù)據(jù)更新的延遲是非常小的。通常，這種實(shí)現(xiàn)都由幾個(gè)從數(shù)據(jù)庫(kù)或者只讀副本構(gòu)成，它們都配置在負(fù)載均衡器之后。應(yīng)用向負(fù)載均衡器發(fā)起讀請(qǐng)求，負(fù)載均衡器以循環(huán)計(jì)成者南連方式押該請(qǐng)求傳遞給只讀副本。
我們把這種類(lèi)型的拆分稱(chēng)為X軸拆分， AKF擴(kuò)展立方中，它被表示為“X軸一橫向復(fù)制'”。熟悉Web應(yīng)用托管的開(kāi)發(fā)者都會(huì)認(rèn)同這樣一個(gè)例子:在系統(tǒng)的Web層或應(yīng)用層上，負(fù)載均衡器后的多個(gè)服務(wù)器上都運(yùn)行著相同的代碼。一旦負(fù)載均衡器收到請(qǐng)求后，它就把該請(qǐng)求分發(fā)到其中一個(gè)Web或應(yīng)用服務(wù)器上進(jìn)行處理。在應(yīng)用層進(jìn)行這種分發(fā)的好處是可以在負(fù)載均衡器后面放置成百上千的服務(wù)器，都運(yùn)行同樣的代碼，處理類(lèi)似的請(qǐng)求。
X軸原則不僅適用于數(shù)據(jù)庫(kù)。Web服務(wù)器和應(yīng)用服務(wù)器通常也能被輕松克隆，這樣就能夠把事務(wù)平均分配到多個(gè)系統(tǒng)上進(jìn)行橫向擴(kuò)展。這種應(yīng)用或Web服務(wù)的克隆實(shí)施起來(lái)相對(duì)比較容易，可以擴(kuò)展能夠處理的事務(wù)數(shù)量。遺憾的是，對(duì)于我們執(zhí)行某些事務(wù)而必須操作的數(shù)據(jù)而言，該方法并不能幫助我們提高擴(kuò)展性。在內(nèi)存中緩存客戶(hù)的專(zhuān)有數(shù)據(jù)或者不同功能特有的數(shù)據(jù)可能會(huì)造成擴(kuò)展服務(wù)的瓶頸，很難在不影響客戶(hù)響應(yīng)時(shí)間的前提下擴(kuò)展網(wǎng)站建設(shè)這些服務(wù)。要解決這種內(nèi)存限制，需要利用擴(kuò)展立方體的Y軸和Z軸。
本文地址：http://m.cdrpkj.cn//article/3453.html
