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