本文將跳出任何一種數據庫，從原理的角度上來分析下面的幾個問題：

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

• 問題二：分區可用性。有多個副本的數據庫，怎么在出現各種問題時保證系統的持續可用？

• 問題三：性能。不使用共享存儲的RDBMS，為了保證多個副本間的數據一致性，是否會損失性能？如何將性能的損失降到最低？

• 總結

問題一：數據一致性

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

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

如何實現主備強一致？大家都知道數據庫中最重要的一個技術：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的開銷并未增大。只要是異步化做得好，整個系統的吞吐量，并不會由于引入強同步而降低。

總結

洋洋灑灑寫了一堆，最后做一個小小的總結：

• 各種主流關系型數據庫系統是否可以實現主備的強一致，是否可以保證不依賴于存儲的數據一致性？

? ? ? ? ? 可以。Oracle有，MySQL 5.7，阿里云RDS，網易RDS都有類似的功能。

• 目前各種關系型數據庫系統，能否在保證主備數據強一致的基礎上，提供系統的持續可用和高性能？

? ? ? ? ? 可以做，但是難度較大，目前主流關系型數據庫缺乏這個能力。

---

作者介紹

何登成（花名：圭多），阿里巴巴數據庫技術資深專家，2014年加入阿里巴巴數據庫團隊。2014、2015連續兩次作為“雙11大促/新春紅包”活動數據庫整體負責人。同時負責領導AliDB內核的研發工作（包括AliSQL, AliRocks等數據庫內核）。圭多在追求技術的道路上，十年如一日。

歡迎加入

阿里巴巴數據庫技術

長按二

總結

以上是生活随笔為你收集整理的数据一致性-分区可用性-性能—多副本强同步数据库系统实现之我见的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。