背景
提到金融級數據庫，大家可能不約而同的會想到Oracle，DB2等商業數據庫。但是隨著開源數據庫的發展，開源數據庫正在逐漸成為數據庫產業的核心，比如MySQL、PostgreSQL數據庫 ，已經深入阿里、平安科技、蘇寧、高德、國家電網（還有很多）的核心。可以看到，不管是MySQL還是PostgreSQL，有越來越多成功的核心應用案例。
目前還有一些金融企業核心數據庫依舊是老牌的商業數據庫，個人認為並不是這些商業數據庫比開源數據庫有多優秀，而是牽一髮而動全身，非單純技術層面的問題。特別是關係民生的金融行業，更換數據庫可不是那麼容易。
開源數據庫在新生業務中是有巨大機會的，畢竟社會是在不斷進步和發展的，老物件會逐漸成為人們的回憶，消失在歷史的長河裡。
不管是商業數據庫，還是開源數據庫，在金融行業混，都必須跨過一道坎：高可用。
（當然，不可否認，解決金融問題，除了高可用，還有更多，包括 功能，性能，SQL標準 方方面面。不在本系列文章討論範疇）
硬件為王 - 傳統數據庫高可用架構
實際上扛起金融核心大旗的還不算Oracle，背後的硬件才是真正的王者，估計也是Oracle收購SUN的原因之一(感嘆一下，SUN的ZFS至今無人能及)。
IBM 大機、小機、高端存儲，以其穩定性、可用性、性能等方面的卓越表現征服了當時的市場。而軟件層面，實際上更多的是圍繞硬件來進行設計，包括Oracle的RAC架構，也是需要依賴共享存儲的。
生態的原因，在硬件為王時代的數據庫，由於硬件的強勢，數據庫軟件依附這些硬件，這也是為什麼又這麼多基於共享存儲的高可用的架構。
傳統數據庫的高可用架構存在的問題
價格昂貴，集中式存儲單點故障（好的存儲可能會在 鏈路、機頭、存儲介質、電源模塊、內部背板等 層面全面解決單點問題）
如果存儲層存在單點（不管是機頭還是鏈路或者其他），軟件層面需要再做一層mirror或RAID冗餘，例如LVM，ZFS，ASM等技術，但是存儲的強一致一定會引入RT（需要軟件層彌補，例如事務分組提交、異步WAL等）。
甚至大量的容災方案，也是出自存儲硬件廠商之手，因為除了硬件廠商，沒有人更瞭解如何對存儲實現異地冗餘了。
彎道超車 - 開源數據庫高可用架構
隨著x86硬件架構(以及對應的軟件生態freebsd,linux等)、SSD硬盤的發展，到現在GPU\FPGA\TPU等芯片及其軟件生態的成長。開放性硬件在功能、軟件生態、硬件性能等方面全面提升，以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。
開源數據庫採樣通用硬件，多節點，更低的成本，更優秀的擴展性，解決了用戶的高可用問題。
兩節點方案
兩節點的HA方案，屬於廉價的解決方案，無法同時保證高可用和高可靠。
要保證高可靠（0數據丟失），就必須等BINLOG或WAL複製到備庫才返回，備庫只要稍有抖動或者備庫故障，就會導致可用性下降。（也就是說，主備任何一個異常都會影響可用性）。
兩節點方案採用自動降級機制，在備庫正常的情況下，採用同步模式（數據需要寫雙份才返回給用戶），保證可用性和可靠性。在備庫異常時，則自動降級為異步，只能保證可用性（可靠性無法保證，如果此時主庫掛了，備庫恢復，發生HA切換，可能導致部分未同步的數據丟失）。
阿里雲RDS率先推出三節點方案，同時保證數據庫的高可靠和高可用，滿足了金融行業高可用和零數據丟失的需求。
三節點方案
可靠性保證：三節點方案中，用戶在提交事務時，需要等待至少一個備庫收到日誌副本，才返回給用戶事務成功結束的信號，確保數據庫的可靠性（用戶收到確認的事務，已持久化到多數派主機中）。
可用性保證：三節點方案中，即使一臺服務器掛掉（無論哪臺），也不影響業務的可用性，因為已提交的數據至少有2份副本，掛掉一臺，還有至少1臺主機是包含了已提交事務的持久化內容的。
多節點引入的世界問題
多節點同時解決了可用性、可靠性的問題。但是實現並非易事，在解決可用性問題時，會涉及到另一個問題，因為異常時需要選出一個新的主庫，什麼情況下開始選舉？選誰？都是問題。
選主問題有一個非常著名的典故，拜占庭將軍的問題。
以下截取自互聯網：
拜占庭位於如今的土耳其的伊斯坦布爾，是東羅馬帝國的首都。由於當時拜占庭羅馬帝國國土遼闊，為了防禦目的，軍隊相隔很遠，將軍與將軍之間靠信差傳消息。進行軍事決策時，所有將軍必需達成 “一致的共識”。但是，在軍隊內有可能存有叛徒和敵軍的間諜，左右將軍們的決定，在進行共識時，結果並不一定代表大多數人的意見。於是在已知有成員不可靠的情況下，其餘忠誠的將軍在不受叛徒或間諜的影響下如何達成一致的協議，拜占庭問題就此形成。
拜占庭假設是對現實世界的模型化，由於硬件錯誤、網絡擁塞或斷開以及遭到惡意攻擊，計算機和網絡可能出現不可預料的行為。和我們提到的三節點要解決的問題是一致的。
下一篇《阿里雲RDS金融數據庫(三節點版) - 理論篇》將講解RDS三節點的理論基礎 - Raft協議。
系列文章
《阿里雲RDS金融數據庫(三節點版) - 背景篇》
《阿里雲RDS金融數據庫(三節點版) - 理論篇》
《阿里雲RDS金融數據庫(三節點版) - 性能篇》
《阿里雲RDS金融數據庫(三節點版) - 案例篇》
阿里雲RDS金融數據庫(三節點版)
阿里雲RDS金融數據庫 - MySQL三節點版
阿里雲RDS金融數據庫 - PostgreSQL三節點版(敬請期待)