橫向復(fù)制(X軸原則)

橫向擴(kuò)展，即復(fù)制服務(wù)或數(shù)據(jù)庫來分散事務(wù)負(fù)載。具有非常高讀寫比例(5:1或更高，越高越好)的數(shù)據(jù)庫；口事務(wù)増長大于數(shù)據(jù)增長的系統(tǒng)。只需克隆服務(wù)并實施負(fù)載均衡；
對于數(shù)據(jù)庫，要確保訪問代碼能夠區(qū)分讀寫操作應(yīng)用理由:復(fù)制數(shù)據(jù)和功能可以使事務(wù)更快地擴(kuò)展。X軸拆分方法能夠快速實現(xiàn)，但是只能提高事務(wù)的擴(kuò)展性，不能提高數(shù)據(jù)的擴(kuò)展性。
系統(tǒng)最難擴(kuò)展的部分通常是數(shù)據(jù)庫或者持久存儲層。該問題可以追溯到EdgarF.Codd于1970年發(fā)表的論文4RelationalModelofDateforLargeSharedDataBanksl，該論文被認(rèn)為首次引人了關(guān)系數(shù)據(jù)庫管理系統(tǒng)(RDBMS)的概念。當(dāng)今最流行的RDBMS，如Oracle、MYSQL和SQLServer等，如其名字所示，都用于管理數(shù)據(jù)元素之間的關(guān)系。這些關(guān)系可以存在于表內(nèi)，也可以存在于表之間。大多數(shù)聯(lián)機(jī)事務(wù)處理(OLTP)系統(tǒng)中的表都被規(guī)范化為第三范式?，即表中的所有記錄都有相同的字段，所有非關(guān)鍵字段都不能只依賴于組合關(guān)鍵字的一部分，所有非關(guān)鍵字段都必須依賴于關(guān)鍵字。表中的每一列數(shù)據(jù)與其他列數(shù)據(jù)是有關(guān)系的。表之間的關(guān)系，通常稱為外鍵。大多數(shù)使用數(shù)據(jù)庫的應(yīng)用都有賴于數(shù)據(jù)庫基于其ACID屬性支持并實施這些關(guān)系。維護(hù)和實施這些關(guān)系使得拆分?jǐn)?shù)據(jù)庫需要很多工作。

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

本文名稱：橫向復(fù)制(X軸原則)
地址分享：http://www.muchs.cn/news6/144006.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供建站公司、動態(tài)網(wǎng)站、品牌網(wǎng)站制作、網(wǎng)站維護(hù)、網(wǎng)站設(shè)計、虛擬主機(jī)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)