詳解阿里雲RDS金融資料庫（三節點版）：背景篇

知識 07-15

背景

提到金融級資料庫，大家可能不約而同的會想到Oracle，DB2等商業資料庫。但是隨著開源資料庫的發展，開源資料庫正在逐漸成為資料庫產業的核心，比如MySQL、PostgreSQL資料庫，已經深入阿里、平安科技、蘇寧、高德、國家電網（還有很多）的核心。可以看到，不管是MySQL還是PostgreSQL，有越來越多成功的核心應用案例。

目前還有一些金融企業核心資料庫依舊是老牌的商業資料庫，個人認為並不是這些商業資料庫比開源資料庫有多優秀，而是牽一髮而動全身，非單純技術層面的問題。特別是關係民生的金融行業，更換資料庫可不是那麼容易。

開源資料庫在新生業務中是有巨大機會的，畢竟社會是在不斷進步和發展的，老物件會逐漸成為人們的回憶，消失在歷史的長河裡。

不管是商業資料庫，還是開源資料庫，在金融行業混，都必須跨過一道坎：高可用。

（當然，不可否認，解決金融問題，除了高可用，還有更多，包括功能，性能，SQL標準方方面面。不在本系列文章討論範疇）

硬體為王 - 傳統資料庫高可用架構

實際上扛起金融核心大旗的還不算Oracle，背後的硬體才是真正的王者，估計也是Oracle收購SUN的原因之一(感嘆一下，SUN的ZFS至今無人能及)。

IBM 大機、小機、高端存儲，以其穩定性、可用性、性能等方面的卓越表現征服了當時的市場。而軟體層面，實際上更多的是圍繞硬體來進行設計，包括Oracle的RAC架構，也是需要依賴共享存儲的。

生態的原因，在硬體為王時代的資料庫，由於硬體的強勢，資料庫軟體依附這些硬體，這也是為什麼又這麼多基於共享存儲的高可用的架構。

詳解阿里雲RDS金融資料庫（三節點版）：背景篇

傳統資料庫的高可用架構存在的問題

價格昂貴，集中式存儲單點故障（好的存儲可能會在鏈路、機頭、存儲介質、電源模塊、內部背板等層面全面解決單點問題）

詳解阿里雲RDS金融資料庫（三節點版）：背景篇

如果存儲層存在單點（不管是機頭還是鏈路或者其他），軟體層面需要再做一層mirror或RAID冗餘，例如LVM，ZFS，ASM等技術，但是存儲的強一致一定會引入RT（需要軟體層彌補，例如事務分組提交、非同步WAL等）。

詳解阿里雲RDS金融資料庫（三節點版）：背景篇

甚至大量的容災方案，也是出自存儲硬體廠商之手，因為除了硬體廠商，沒有人更了解如何對存儲實現異地冗餘了。

彎道超車 - 開源資料庫高可用架構

隨著x86硬體架構(以及對應的軟體生態freebsd,linux等)、SSD硬碟的發展，到現在GPUFPGATPU等晶元及其軟體生態的成長。開放性硬體在功能、軟體生態、硬體性能等方面全面提升，以IBM為代表的封閉式硬體逐漸失去了核心地位。

業務的發展和開放性硬體生態的發展，助長了開源資料庫的發展，MySQL、PostgreSQL資料庫就是非常典型的代表。

開放性使得更多的用戶可以獲取到，更多的用戶又助長了軟體本身的發展，這使得最近10年開源資料庫已經開始全面超越商業資料庫。最典型的例子是PostgreSQL，從SQL兼容性，硬體生態對接（LLVM，向量計算，多核並行，GPU計算等），軟體生態對接（PL/R, PL/JAVA, PL/Python, PL/CUDA, 機器學習庫等等），擴展性（9種擴展索引介面支持各種類型的檢索，擴展類型支持DNA、圖像特徵值、化學類型等，擴展語言介面、擴展外部數據源介面等），雲生態（RDS PG OSS可並行讀寫OSS海量存儲外部表）等各個方面全面超越商業資料庫。

開源資料庫通過內部的複製，實現了高可用架構的彎道超車。以MySQL為代表的binlog複製，以PostgreSQL為代表的stream replication。

開源資料庫採樣通用硬體，多節點，更低的成本，更優秀的擴展性，解決了用戶的高可用問題。

兩節點方案

詳解阿里雲RDS金融資料庫（三節點版）：背景篇

兩節點的HA方案，屬於廉價的解決方案，無法同時保證高可用和高可靠。

要保證高可靠（0數據丟失），就必須等BINLOG或WAL複製到備庫才返回，備庫只要稍有抖動或者備庫故障，就會導致可用性下降。（也就是說，主備任何一個異常都會影響可用性）。

兩節點方案採用自動降級機制，在備庫正常的情況下，採用同步模式（數據需要寫雙份才返回給用戶），保證可用性和可靠性。在備庫異常時，則自動降級為非同步，只能保證可用性（可靠性無法保證，如果此時主庫掛了，備庫恢復，發生HA切換，可能導致部分未同步的數據丟失）。

阿里雲RDS率先推出三節點方案，同時保證資料庫的高可靠和高可用，滿足了金融行業高可用和零數據丟失的需求。

三節點方案

詳解阿里雲RDS金融資料庫（三節點版）：背景篇

可靠性保證：三節點方案中，用戶在提交事務時，需要等待至少一個備庫收到日誌副本，才返回給用戶事務成功結束的信號，確保資料庫的可靠性（用戶收到確認的事務，已持久化到多數派主機中）。

可用性保證：三節點方案中，即使一台伺服器掛掉（無論哪台），也不影響業務的可用性，因為已提交的數據至少有2份副本，掛掉一台，還有至少1台主機是包含了已提交事務的持久化內容的。

多節點引入的世界問題

多節點同時解決了可用性、可靠性的問題。但是實現並非易事，在解決可用性問題時，會涉及到另一個問題，因為異常時需要選出一個新的主庫，什麼情況下開始選舉？選誰？都是問題。

選主問題有一個非常著名的典故，拜占庭將軍的問題。

以下截取自互聯網：

拜占庭位於如今的土耳其的伊斯坦布爾，是東羅馬帝國的首都。由於當時拜占庭羅馬帝國國土遼闊，為了防禦目的，軍隊相隔很遠，將軍與將軍之間靠信差傳消息。進行軍事決策時，所有將軍必需達成「一致的共識」。但是，在軍隊內有可能存有叛徒和敵軍的間諜，左右將軍們的決定，在進行共識時，結果並不一定代表大多數人的意見。於是在已知有成員不可靠的情況下，其餘忠誠的將軍在不受叛徒或間諜的影響下如何達成一致的協議，拜占庭問題就此形成。

拜占庭假設是對現實世界的模型化，由於硬體錯誤、網路擁塞或斷開以及遭到惡意攻擊，計算機和網路可能出現不可預料的行為。和我們提到的三節點要解決的問題是一致的。

下一篇《阿里雲RDS金融資料庫(三節點版) - 理論篇》將講解RDS三節點的理論基礎 - Raft協議。

詳解阿里雲RDS金融資料庫（三節點版）：背景篇