舊瓶裝新酒 - cap

本篇文章嘗試從原理的角度分析下面幾個問題：

資料一致性

在不使用共享儲存的情況下，傳統RDBMS（例如：Oracle/MySQL/PostgreSQL等），能否做到在主庫出問題時的資料零丟失。

2. 分割槽可用性

有多個副本的資料庫，怎麼在出現各種問題時保證系統的持續可用？

3. 效能

使用共享儲存的RDBMS，為了保證多個副本間的資料一致性，是否會損失效能？如何將效能的損失降到最低？

一、資料一致性

問：脫離了共享儲存，傳統關係型資料庫就無法做到主備強一致嗎？

答：我的答案，是No。哪怕不用共享儲存，任何資料庫，也都可以做到主備資料的強一致。Oracle如此，MySQL如此，PostgreSQL如此，OceanBase也如此。

Q： 如何實現主備強一致？

大家都知道資料庫中最重要的一個技術：

WAL

（Write-Ahead-Logging）。更新操作寫日誌（Oracle Redo Log，MySQL Binlog等），事務提交時，保證將事務產生的日誌先刷到磁碟上，保證整個事務的更新操作資料不丟失。那實現資料庫主備資料強一致的方法也很簡單：

事務提交的時候，同時發起兩個寫日誌操作，一個是將日誌寫到本地磁碟的操作，另一個是將日誌同步到備庫並且確保落盤的操作；

主庫此時等待兩個操作全部成功返回之後，才返回給應用方，事務提交成功；

整個事務提交操作的邏輯，如下圖所示：

上圖所示，由於事務提交操作返回給應用時，事務產生的日誌在主備兩個資料庫上都已經存在了，強同步。因此，此時主庫Crash的話，備庫提供服務，其資料與主庫是一致的，沒有任何事務的資料丟失問題。主備資料強一致實現。用過Oracle的朋友，應該都知道Oracle的Data Guard，可工作在 最大效能，最大可用，最大保護 三種模式下，其中第三種 最大保護 模式，採用的就是上圖中的基本思路。

實現資料的強同步實現之後，接下來到了考慮可用性問題。現在已經有主備兩個資料完全一致的資料庫，備庫存在的主要意義，就是在主庫出故障時，能夠接管應用的請求，確保整個資料庫能夠持續的提供服務：主庫Crash，備庫提升為主庫，對外提供服務。此時，又涉及到一個決策的問題，主備切換這個操作誰來做？人當然可以做，接收到主庫崩潰的報警，手動將備庫切換為主庫。但是，手動的效率是低下的，更別提資料庫可能會隨時崩潰，全部讓人來處理，也不夠厚道。一個HA（High Availability）檢測工具應運而生：HA工具一般部署在第三臺伺服器上，同時連線主備，當其檢測到主庫無法連線，就切換備庫，很簡單的處理邏輯，如下圖所示：

HA軟體與主備同時連線，並且有定時的心跳檢測。主庫Crash後，HA探測到，發起一個將備庫提升為主庫的操作（修改備庫的VIP或者是DNS，可能還需要將備庫啟用等一系列操作），新的主庫提供對外服務。此時，由於主備的資料是透過日誌強同步的，因此並沒有資料丟失，資料一致性得到了保障。

有了基於日誌的資料強同步，有了主備自動切換的HA軟體，是不是就一切萬事大吉了？我很想說是，確實這個架構已經能夠解決90%以上的問題，但是這個架構在某些情況下，也埋下了幾個比較大的問題。

首先，一個一目瞭然的問題，主庫Crash，備庫提升為主庫之後，此時的資料庫是一個單點，原主庫重啟的這段時間，單點問題一直存在。如果這個時候，新的儲存再次Crash，整個系統就處於不可用狀態。此問題，可以透過增加更多副本，更多備庫的方式解決，例如3副本（一主兩備），此處略過不表。

其次，在主備環境下，處理主庫掛的問題，算是比較簡單的，決策簡單：主庫Crash，切換備庫。但是，如果不是主庫Crash，而是網路發生了一些問題，如下圖所示：

若Master與Slave之間的網路出現問題，例如：斷網，網路抖動等。此時資料庫應該怎麼辦？Master繼續提供服務？Slave沒有同步日誌，會資料丟失。Master不提供服務？應用不可用。在Oracle中，如果設定為 最大可用 模式，則此時仍舊提供服務，允許資料不一致；如果設定為 最大保護 模式，則Master不提供服務。因此，在Oracle中，如果設定為 最大保護 模式，一般建議設定兩個或以上的Slave，任何一個Slave日誌同步成功，Master就繼續提供服務，提供系統的可用性。

網路問題不僅僅出現在Master和Slave之間，同樣也可能出現在HA與Master，HA與Slave之間。考慮下面的這種情況：

HA與Master之間的網路出現問題，此時HA面臨兩個抉擇：

HA到Master之間的連線不通，認為主庫Crash。選擇將備庫提升為主庫。但實際上，只是HA到Master間的網路有問題，原主庫是好的（沒有被降級為備庫，或者是關閉），仍舊能夠對外提供服務。新的主庫也可以對外提供服務。兩個主庫，產生雙寫問題，最為嚴重的問題。

HA到Master之間的連線不通，認為是網路問題，主庫未Crash。HA選擇不做任何操作。但是，如果這時確實是主庫Crash了，HA不做操作，資料庫不對外提供服務。雙寫問題避免了，但是應用的可用性受到了影響。

最後，資料庫會出現問題，資料庫之間的網路會出現問題，那麼再考慮一層，HA軟體本身也有可能出現問題。如下圖所示：

如果是HA軟體本身出現了問題，怎麼辦？我們透過部署HA，來保證資料庫系統在各種場景下的持續可用，但是HA本身的持續可用誰來保證？難道我們需要為HA做主備，然後再HA之上再做另一層HA？一層層加上去，子子孫孫無窮盡也 … …

其實，上面提到的這些問題，其實就是經典的分散式環境下的一致性問題（Consensus），近幾年比較火熱的Lamport老爺子的Paxos協議，Stanford大學最近發表的Raft協議，都是為了解決這一類問題。（對Raft協議感興趣的朋友，可以再看一篇Raft的動態演示PPT：Understandable Distributed Consensus）

二、分割槽可用性

前面，我們回答了第一個問題，資料庫如果不使用共享儲存，能否保證主備資料的強一致？答案是肯定的：可以。但是，透過前面的分析，我們又引出了第二個問題：如何保證資料庫在各種情況下的持續可用？至少前面提到的HA機制無法保證。那麼是否可以引入類似於Paxos，Raft這樣的分散式一致性協議，來解決上面提到的各種問題呢？

答案是可以的，我們可以透過引入類Paxos，Raft協議，來解決上面提到的各類問題，保證整個資料庫系統的持續可用。考慮仍舊是兩個資料庫組成的主備強一致系統，仍舊使用HA進行主備監控和切換。

再回顧一下上一節新引入的兩個問題：

HA軟體自身的可用性如何保證？

如果HA軟體無法訪問主庫，那麼這時到底是主庫Crash了呢？還是HA軟體到主庫間的網路出現問題了呢？如何確保不會同時出現兩個主庫，不會出現雙寫問題？

如何在解決上面兩個問題的同時，保證資料庫的持續可用？

為了解決這些問題，新的系統如下所示：

相對於之前的系統，可以看到這個系統的複雜性明顯增高，而且不止一成。資料庫仍舊是一主一備，資料強同步。但是除此之外，多了很多變化，這些變化包括：

資料庫上面分別部署了HA Client；

原來的一臺HA主機，擴充套件到了3臺HA主機。一臺是HA Master，其餘的為HA Participant；

HA主機與HA Client進行雙向通訊。HA主機需要探測HA Client所在的DB是否能夠提供服務，這個跟原有一致。但是，新增了一條HA Client到HA主機的Master Lease通訊。

這些變化，能夠解決上面的兩個問題嗎？讓我們一個一個來分析。首先是：HA軟體自身的可用性如何保證？

從一臺HA主機，增加到3臺HA主機，正是為了解決這個問題。HA服務，本身是無狀態的，3臺HA主機，可以透過Paxos/Raft進行自動選主。選主的邏輯，我這裡就不做贅述，不是本文的重點，想詳細瞭解其實現的，可以參考網際網路上洋洋灑灑的關於Paxos/Raft的相關文章。總之，透過部署3臺HA主機，並且引入Paxos/Raft協議，HA服務的高可用可以解決。HA軟體的可用性得到了保障。

第一個問題解決，再來看第二個問題：如何識別出當前是網路故障，還是主庫Crash？如何保證任何情況下，資料庫有且只有一個主庫提供對外服務？

透過在資料庫伺服器上部署HA Client，並且引入HA Client到HA Master的租約（Lease）機制，這第二個問題同樣可以得到完美的解決。所謂HA Client到HA Master的租約機制，就是說圖中的資料庫例項，不是永遠持有主庫（或者是備庫）的權利。當前主庫，處於主庫狀態的時間是有限制的，例如：10秒。每隔10秒，HA Client必須向HA Master發起一個新的租約，續租它所在的資料庫的主庫狀態，只要保證每10秒收到一個來自HA Master同意續租的確認，當前主庫一直不會被降級為備庫。

第二個問題，可以細分為三個場景：

場景一：主庫Crash，但是主庫所在的伺服器正常執行，HA Client執行正常

主庫Crash，HA Client正常執行。這種場景下，HA Client向HA Master傳送一個放棄主庫租約的請求，HA Master收到請求，直接將備庫提升為主庫即可。原主庫起來之後，作為備庫執行。

場景二：主庫所在的主機Crash。（主庫和HA Client同時Crash）

此時，由於HA Client和主庫同時Crash，HA Master到HA Client間的通訊失敗。這個時候，HA Master還不能立即將備庫提升為主庫，因為區分不出場景二和接下來的場景三（網路問題）。因此，HA Master會等待超過租約的時間（例如：12秒），如果租約時間之內仍舊沒有續租的訊息。那麼HA Master將備庫提升為主庫，對外提供服務。原主庫所在的主機重啟之後，以備庫的狀態執行。

場景三：主庫正常，但是主庫到HA Master間的網路出現問題

對於HA Master來說，是區分不出場景二和場景三的。因此，HA Master會以處理場景二同樣的邏輯處理場景三。等待超過租約的時間，沒有收到續租的訊息，提升原備庫為主庫。但是在提升備庫之前，原主庫所在的HA Client需要做額外的一點事。原主庫HA Client傳送給HA Master的續租請求，由於網路問題，一直沒有得到響應，超過租約時間，主動將本地的主庫降級為備庫。如此一來，待HA Master將原備庫提升為主庫時，原來的主庫已經被HA Client降級為備庫。雙主的情況被杜絕，應用不可能產生雙寫。

透過以上三個場景的分析，問題二同樣在這個架構下被解決了。而解決問題二的過程中，系統最多需要等待租約設定的時間，如果租約設定為10秒，那麼出各種問題，資料庫停服的時間最多為10秒，基本上做到了持續可用。這個停服的時間，完全取決於租約的時間設定。

到這兒基本可以說，要實現一個持續可用（分割槽可用性保證），並且保證主備資料強一致的資料庫系統，是完全沒問題的。在現有資料庫系統上做改造，也是可以的。但是，如果考慮到實際的實現，這個複雜度是非常高的。資料庫的主備切換，是資料庫內部實現的，此處透過HA Master來提升主庫；透過HA Client來降級備庫；保證資料庫崩潰恢復後，恢復為備庫；透過HA Client實現主庫的租約機制；實現HA主機的可用性；所有的這些，在現有資料庫的基礎上實現，都有著相當的難度。能夠看到這兒，而且有興趣的朋友，可以針對此問題進行探討

三、效能

資料一致性，透過日誌的強同步，可以解決。分割槽可用性，在出現任何異常情況時仍舊保證系統的持續可用，可以在資料強同步的基礎上引入Paxos/Raft等分散式一致性協議來解決，雖然這個目前沒有成熟的實現。接下來再讓我們來看看一個很多同學都很感興趣的問題：如何在保證強同步的基礎上，同時保證高效能？回到我們本文的第一幅圖：

為了保證資料強同步，應用發起提交事務的請求時，必須將事務日誌同步到Slave，並且落盤。相對於非同步寫Slave，同步方式多了一次Master到Slave的網路互動，同時多了一次Slave上的磁碟sync操作。反應到應用層面，一次Commit的時間一定是增加了，具體增加了多少，要看主庫到備庫的網路延時和備庫的磁碟效能。

為了提高效能，第一個很簡單的想法，就是部署多個Slave，只要有一個Slave的日誌同步完成返回，加上本地的Master日誌也已經落盤，提交操作就可以返回了。多個Slave的部署，對於消除瞬時的網路抖動，非常有效果。在Oracle的官方建議中，如果使用最大保護模式，也建議部署多個Slave，來最大限度的消除網路抖動帶來的影響。如果部署兩個Slave，新的部署架構圖如下所示：

新增一個Slave，資料三副本。兩個Slave，只要有一個Slave日誌同步完成，事務就可以提交，極大地減少了某一個網路抖動造成的影響。增加了一個副本之後，還能夠解決當主庫Crash之後的資料安全性問題，哪怕主庫Crash，仍舊有兩個副本可以提供服務，不會形成單點。

但是，在引入資料三副本之後，也新引入了一個問題：主庫Crash的時候，到底選擇哪一個備庫作為新的主庫？當然，選主的權利仍舊是HA Master來行使，但是HA Master該如何選擇？這個問題的簡單解決可以使用下面的幾個判斷標準：

日誌優先。兩個Slave，哪個Slave擁有最新的日誌，則選擇這個Slave作為新的主庫。

主機層面排定優先順序。如果兩個Slave同時擁有最新的日誌，那麼該如何選擇？此時，選擇任何一個都是可以的。例如：可以根據Slave主機IP的大小進行選擇，選擇IP小的Slave作為新的主庫。同樣能夠解決問題。

新的主庫選擇出來之後，第一件需要做的事，就是將新的Master和剩餘的一個Slave，進行日誌的同步，保證二者日誌達到一致狀態後，對應用提供服務。此時，三副本問題就退化為了兩副本問題，三副本帶來的防止網路抖動的紅利消失，但是由於兩副本強同步，資料的可靠性以及一致性仍舊能夠得到保障。

當然，除了這一個簡單的三副本最佳化之外，還可以做其他更多的最佳化。最佳化的思路一般就是同步轉非同步處理，例如事務提交寫日誌操作；使用更細粒度的鎖；關鍵路徑可以採用無鎖程式設計等。

多副本強同步，做到極致，並不一定會導致系統的效能損失。極致應該是什麼樣子的？我的想法是：

對於單個事務來說，RT增加。其響應延時一定會增加（至少多一個網路RT，多一次磁碟Sync）；

對整個資料庫系統來說，吞吐量不變。遠端的網路RT和磁碟Sync並不會消耗本地的CPU資源，本地CPU的開銷並未增大。只要是非同步化做得好，整個系統的吞吐量，並不會由於引入強同步而降低。

本篇文章整理自：