前言

企業(yè)應(yīng)用需要以盡可能快的速度來存儲并檢索盡可能多的數(shù)據(jù)，在應(yīng)用的性能管理中有兩個重要的指標(biāo)，它們分別是響應(yīng)時間與吞吐量。

其中響應(yīng)時間越短，應(yīng)用的響應(yīng)度就越高，因此響應(yīng)時間是衡量性能的指標(biāo)；而擴展則指的是在保持響應(yīng)時間較短的同時，提升系統(tǒng)的負(fù)載能力，因此吞吐量是可擴展性的衡量指標(biāo)。

響應(yīng)時間與吞吐量

“事務(wù)響應(yīng)時間”是根據(jù)系統(tǒng)完成一個事務(wù)所花費的時間來計算的，因此包含下面這些種類的分段時間：

獲取數(shù)據(jù)庫連接的時間；

將所有數(shù)據(jù)庫語句通過無線發(fā)送完畢的時間；

執(zhí)行所有輸入語句的時間；

將結(jié)果發(fā)回數(shù)據(jù)庫客戶端所花費的時間；

在釋放數(shù)據(jù)庫連接前，由于執(zhí)行應(yīng)用級計算而導(dǎo)致事務(wù)呈空閑狀態(tài)的時間。

吞吐率是根據(jù)輸入工作的完成速率來定義的。在數(shù)據(jù)庫概念中，吞吐量可以根據(jù)指定時間間隔內(nèi)所執(zhí)行的事務(wù)數(shù)量來計算。

從這個定義我們能夠推斷出：只要減少事務(wù)在執(zhí)行時所花費的時間，系統(tǒng)就能處理更多的請求。

減少響應(yīng)時間會讓釋放數(shù)據(jù)庫連接的速度變得更快，因此每秒能處理的事務(wù)就越多。但在高并發(fā)環(huán)境中，只減少響應(yīng)時間是不夠的。為了保持響應(yīng)時間有一個固定的最大值，必須根據(jù)輸入請求的吞吐量相應(yīng)地增加系統(tǒng)的容量。增加更多的資源可以在一定程度內(nèi)提升可擴展性，直到容量增益開始下降為止。

容量規(guī)劃使用了反饋驅(qū)動機制，需要持續(xù)對應(yīng)用進行監(jiān)控，因此任何優(yōu)化都必須通過應(yīng)用的性能指標(biāo)來執(zhí)行。

向上擴展與橫向擴展

擴展就是通過增加更多資源以提高容量。垂直擴展（即向上擴展）指的是在單臺機器上增加更多資源，而水平擴展（即橫向擴展）指的是增加可用機器的數(shù)量。

傳統(tǒng)上來說，為數(shù)據(jù)庫服務(wù)器增加更多的硬件資源是增加數(shù)據(jù)庫容量的最佳方案。關(guān)系數(shù)據(jù)庫是在70年代末出現(xiàn)的，25年之后根據(jù)摩爾定律的發(fā)展趨勢，數(shù)據(jù)庫供應(yīng)商搭上了硬件發(fā)展的東風(fēng)。

分布式系統(tǒng)比集中式系統(tǒng)更難管理，復(fù)雜度大大增加，這就是為什么水平擴展比垂直擴展更具有挑戰(zhàn)性的原因。另一方面，配置一臺專用的高性能服務(wù)器，其價格足以購買多臺商品機——而后者可用資源（CPU、內(nèi)存、硬盤存儲器）加起來遠(yuǎn)比單個專用服務(wù)器要多得多。在決定哪種擴展方法更適合指定的企業(yè)系統(tǒng)時，價格（包括硬件與證書授權(quán)）與固有的開發(fā)運營費用都要納入考量。

構(gòu)建在許多開源項目（比如PHP，MySQL）之上的Facebook就使用了水平擴展的架構(gòu)，以適應(yīng)它那巨大的流量。而StackOverflow則是垂直擴展架構(gòu)的最佳范例，在一篇博文里，JeffAtwood解釋道：Windows與SQLServer授權(quán)的價格也是他們不選擇水平擴展方式的原因之一。

無論效果有多強大，一個專用的服務(wù)器仍只是一個單獨的故障點，若系統(tǒng)可用性出了問題，吞吐量就會降到零。因此在大多企業(yè)系統(tǒng)中，對數(shù)據(jù)庫復(fù)制是有強制要求的。

主從復(fù)制

主從復(fù)制方案很適合讀寫比例較高的企業(yè)系統(tǒng)，可以提高其可用性。

主節(jié)點負(fù)責(zé)記錄，它也是唯一接受寫入的節(jié)點，在主節(jié)點上執(zhí)行的所有記錄修改會復(fù)制到從節(jié)點上。二進制復(fù)制使用了主節(jié)點預(yù)寫式日志（WAL），而基于SQL語句的復(fù)制則在從節(jié)點上完全重演主節(jié)點的操作。

異步復(fù)制非常常見——特別是在有許多從節(jié)點要更新的情況下。雖然從節(jié)點的更新速度可能會落后于主節(jié)點，但最終結(jié)果是一致的。在主節(jié)點崩潰的情況下，整個集群會從可用的從節(jié)點中選出新的主節(jié)點（一般是更新記錄最新的那個節(jié)點）。

因為主節(jié)點不會立刻進行選舉，因此異步復(fù)制拓?fù)浣Y(jié)構(gòu)也被稱為熱備用。

大多數(shù)據(jù)庫系統(tǒng)允許有一個同步的從節(jié)點，代價是增加響應(yīng)時間（主節(jié)點必須無停頓地同步通知從節(jié)點進行復(fù)制）。在主節(jié)點發(fā)生故障的情況下，自動故障轉(zhuǎn)移機制可以將同步的從節(jié)點提升為新的主節(jié)點。

擁有一個同步的從節(jié)點可以在主節(jié)點發(fā)生故障的情況下確保系統(tǒng)數(shù)據(jù)一致，因為這個同步從節(jié)點是完全復(fù)制主節(jié)點的。同步主從復(fù)制也被稱為熱備份拓?fù)洌驗橥綇墓?jié)點時刻準(zhǔn)備著頂上主節(jié)點的位置。

如果只有異步從節(jié)點可用，新選舉出來的從節(jié)點可能會比發(fā)生故障的主節(jié)點更新速度慢，在這種情況下系統(tǒng)用一致性與持久性換取了更低的延遲與更高的吞吐量。

除了解決單點故障的問題之外，數(shù)據(jù)庫復(fù)制也能增加事務(wù)的吞吐量。在主從拓?fù)渲?，從?jié)點可以接受只讀事務(wù)，因此可以分流讀取的流量。增加從節(jié)點的可用只讀連接，可以減少主節(jié)點的資源競爭，反過來也能減少讀寫事務(wù)的響應(yīng)時間。如果主節(jié)點不能再與一直增加的讀寫流量同步，使用多個主節(jié)點進行復(fù)制也許是更好的選擇。

多個主節(jié)點復(fù)制

在多個主節(jié)點的復(fù)制方案中，所有節(jié)點都是平等的，都可以接受只讀與讀寫事務(wù)。這樣一來將負(fù)載量分配到多個節(jié)點上，就可以只增加事務(wù)的吞吐量，并減少響應(yīng)時間了。

然而，由于分布式系統(tǒng)都是與權(quán)衡相關(guān)的，在多主節(jié)點復(fù)制方案中想要確保數(shù)據(jù)的一致性是很有挑戰(zhàn)性的，因為單一可信的來源可不止一個。由于同樣的數(shù)據(jù)可以在不同節(jié)點上同時修改，因此可能會造成更新沖突的問題。在這種復(fù)制方案中，可以考慮采用避免沖突的方式，或者在檢測到?jīng)_突發(fā)生后，自動應(yīng)用沖突解決算法的方式來解決問題。

主節(jié)點負(fù)責(zé)記錄，它也是唯一接受寫入的節(jié)點，在主節(jié)點上執(zhí)行的所有記錄修改會復(fù)制到從節(jié)點上。二進制復(fù)制使用了主節(jié)點預(yù)寫式日志（WAL），而基于SQL語句的復(fù)制則在從節(jié)點上完全重演主節(jié)點的操作。

異步復(fù)制非常常見——特別是在有許多從節(jié)點要更新的情況下。雖然從節(jié)點的更新速度可能會落后于主節(jié)點，但最終結(jié)果是一致的。在主節(jié)點崩潰的情況下，整個集群會從可用的從節(jié)點中選出新的主節(jié)點（一般是更新記錄最新的那個節(jié)點）。

因為主節(jié)點不會立刻進行選舉，因此異步復(fù)制拓?fù)浣Y(jié)構(gòu)也被稱為熱備用。

大多數(shù)據(jù)庫系統(tǒng)允許有一個同步的從節(jié)點，代價是增加響應(yīng)時間（主節(jié)點必須無停頓地同步通知從節(jié)點進行復(fù)制）。在主節(jié)點發(fā)生故障的情況下，自動故障轉(zhuǎn)移機制可以將同步的從節(jié)點提升為新的主節(jié)點。

擁有一個同步的從節(jié)點可以在主節(jié)點發(fā)生故障的情況下確保系統(tǒng)數(shù)據(jù)一致，因為這個同步從節(jié)點是完全復(fù)制主節(jié)點的。同步主從復(fù)制也被稱為熱備份拓?fù)?，因為同步從?jié)點時刻準(zhǔn)備著頂上主節(jié)點的位置。

如果只有異步從節(jié)點可用，新選舉出來的從節(jié)點可能會比發(fā)生故障的主節(jié)點更新速度慢，在這種情況下系統(tǒng)用一致性與持久性換取了更低的延遲與更高的吞吐量。

除了解決單點故障的問題之外，數(shù)據(jù)庫復(fù)制也能增加事務(wù)的吞吐量。在主從拓?fù)渲?，從?jié)點可以接受只讀事務(wù)，因此可以分流讀取的流量。增加從節(jié)點的可用只讀連接，可以減少主節(jié)點的資源競爭，反過來也能減少讀寫事務(wù)的響應(yīng)時間。如果主節(jié)點不能再與一直增加的讀寫流量同步，使用多個主節(jié)點進行復(fù)制也許是更好的選擇。

多個主節(jié)點復(fù)制

在多個主節(jié)點的復(fù)制方案中，所有節(jié)點都是平等的，都可以接受只讀與讀寫事務(wù)。這樣一來將負(fù)載量分配到多個節(jié)點上，就可以只增加事務(wù)的吞吐量，并減少響應(yīng)時間了。

然而，由于分布式系統(tǒng)都是與權(quán)衡相關(guān)的，在多主節(jié)點復(fù)制方案中想要確保數(shù)據(jù)的一致性是很有挑戰(zhàn)性的，因為單一可信的來源可不止一個。由于同樣的數(shù)據(jù)可以在不同節(jié)點上同時修改，因此可能會造成更新沖突的問題。在這種復(fù)制方案中，可以考慮采用避免沖突的方式，或者在檢測到?jīng)_突發(fā)生后，自動應(yīng)用沖突解決算法的方式來解決問題。

為了避免沖突，可以使用兩階段提交協(xié)議，以確保在分布式事務(wù)中，要么所有的參與進程都提交事務(wù)成功，要么都取消事務(wù)。這種設(shè)計允許所有節(jié)點隨時執(zhí)行同步，不過相對的，也會造成事務(wù)響應(yīng)的時間增加（由于降低了寫入操作的速度）。

如果節(jié)點分布在廣域網(wǎng)（WAN）上，同步延遲可能會大幅增加。如果由于某個節(jié)點變得不可訪問而造成同步失敗，那么所有主節(jié)點上的事務(wù)都會執(zhí)行回滾。

盡管從數(shù)據(jù)一致性的角度來看，避免沖突是更好的辦法，但同步復(fù)制可能會導(dǎo)致事務(wù)響應(yīng)的時間很長。而異步復(fù)制在吞吐量方面更為優(yōu)秀，前提是必須要解決更新沖突的問題。異步多主節(jié)點復(fù)制需要有檢測沖突的機制以及自動解決沖突的算法，一旦檢測到?jīng)_突，自動解決方案就會嘗試合并這兩個沖突分支，在失敗的情況下會請求人工介入。

分片

如果數(shù)據(jù)的規(guī)模超出了復(fù)制多節(jié)點環(huán)境的總?cè)萘?，切分?jǐn)?shù)據(jù)就會變得無可避免。分片指的是將數(shù)據(jù)分布到多個節(jié)點上，這樣每個實例就只包含整體數(shù)據(jù)的一個子集。

一般來講，關(guān)系數(shù)據(jù)庫提供了水平分區(qū)的方式，即在同一個數(shù)據(jù)庫服務(wù)器上將數(shù)據(jù)分布到多個表格中。與水平分區(qū)相反，分片則需要一個分布式的系統(tǒng)拓?fù)浣Y(jié)構(gòu)，以便數(shù)據(jù)可以分布在多臺機器上。

每個分片必須是獨立的，因為用戶事務(wù)只能使用單個分片內(nèi)的數(shù)據(jù)?？绶制B接一般是不允許的，因為分布式加鎖和網(wǎng)絡(luò)開銷的成本都可能會導(dǎo)致事務(wù)的響應(yīng)時間很長。

通過減少每個節(jié)點的數(shù)據(jù)大小，就能減少索引所占的空間。請求的數(shù)據(jù)越少，事務(wù)的響應(yīng)時間也就越短。

典型的分片拓?fù)浣Y(jié)構(gòu)至少包括兩個單獨分開的數(shù)據(jù)中心：

每個數(shù)據(jù)中心都可以提供一個專門的地理區(qū)域，這樣就可以跨地理區(qū)域來平衡負(fù)載。并非所有表格都需要執(zhí)行跨分片分區(qū)，較小的那些會復(fù)制到每個分區(qū)上。為了保持分片同步，需要采用異步復(fù)制機制。

在之前的圖表中，系統(tǒng)將國家表格從一個數(shù)據(jù)中心鏡像到另一個，分區(qū)只在用戶表格中實現(xiàn)。為了避免對跨分片處理數(shù)據(jù)產(chǎn)生需求，每個用戶及其相關(guān)的所有數(shù)據(jù)都只會存放在同一個數(shù)據(jù)中心上。

在尋求增加系統(tǒng)容量的解決方案中，分片一般是在其他選項都不可用時的最后選擇——其他選項包括：

優(yōu)化數(shù)據(jù)層，縮短事務(wù)響應(yīng)時間；

在成本合算的配置前提下，對每個復(fù)制節(jié)點進行擴展；

增加更多復(fù)制節(jié)點，直到同步延遲開始降到可接受閾值之下。