前言

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

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

響應時間與吞吐量

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

獲取數據庫連接的時間；

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

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

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

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

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

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

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

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

向上擴展與橫向擴展

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

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

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

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

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

主從復制

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

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

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

因為主節(jié)點不會立刻進行選舉，因此異步復制拓撲結構也被稱為熱備用。

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

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

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

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

多個主節(jié)點復制

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

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

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

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

因為主節(jié)點不會立刻進行選舉，因此異步復制拓撲結構也被稱為熱備用。

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

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

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

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

多個主節(jié)點復制

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

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

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

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

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

分片

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

一般來講，關系數據庫提供了水平分區(qū)的方式，即在同一個數據庫服務器上將數據分布到多個表格中。與水平分區(qū)相反，分片則需要一個分布式的系統(tǒng)拓撲結構，以便數據可以分布在多臺機器上。

每個分片必須是獨立的，因為用戶事務只能使用單個分片內的數據。跨分片連接一般是不允許的，因為分布式加鎖和網絡開銷的成本都可能會導致事務的響應時間很長。

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

典型的分片拓撲結構至少包括兩個單獨分開的數據中心：

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

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

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

優(yōu)化數據層，縮短事務響應時間；

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

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