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