前幾天，在首席群里討論，某些人已經(jīng)實(shí)現(xiàn)了在常去的城市都有房產(chǎn)了，出差都有自己的房住（當(dāng)然有沒有其他的目的就不得而知了）。相較于外出住酒店，兩種方式各有優(yōu)劣：

• 自有房產(chǎn)是自己的，住著安全放心
• 自有房產(chǎn)需要持續(xù)維護(hù)：平時(shí)需要打掃衛(wèi)生，交物業(yè)費(fèi)，裝修家具等等
• 在不同城市的自有房產(chǎn)水平不同：房屋面積，裝修家具水平，交通，周邊等等
• 酒店不是自己的，可能有安全風(fēng)險(xiǎn)
• 酒店不需要持續(xù)投入，隨到隨住
• 酒店可以提供更多的選擇
• …

上面的內(nèi)容借用德哥今天公眾號(hào)結(jié)尾的一句話“其實(shí)這段內(nèi)容（原文為：這篇文章）的內(nèi)容和標(biāo)題是匹配的, 只是我還沒想好到底有什么關(guān)聯(lián)”。
數(shù)據(jù)庫(kù)的高可用究竟是什么，我覺得還是得從實(shí)際需求場(chǎng)景來：

• 如果你的業(yè)務(wù)不允許中斷，那么數(shù)據(jù)庫(kù)的高可用目標(biāo)就是能夠持續(xù)提供數(shù)據(jù)庫(kù)能力
• 如果你的業(yè)務(wù)允許短時(shí)間中斷，那么數(shù)據(jù)庫(kù)的高可用目標(biāo)就是能夠快速恢復(fù)拉起的能力
• 如果你的業(yè)務(wù)允許較長(zhǎng)時(shí)間中斷，那么數(shù)據(jù)庫(kù)高可用的目標(biāo)就是有辦法能夠恢復(fù)數(shù)據(jù)庫(kù)即可
• 如果你的業(yè)務(wù)無關(guān)緊要，那么數(shù)據(jù)庫(kù)高可用的目標(biāo)就是…可以算沒有目標(biāo)

（Oracle Maximum Availability Architecture (MAA)）

那么從我個(gè)人角度以盡可能高的要求來看看數(shù)據(jù)庫(kù)的高可用。

1 主從架構(gòu)

（MySQL Replication）

主從架構(gòu)是我們用的比較多的高可用架構(gòu)，除了上圖MySQL Replication，Oracle有(Active) DataGuard，PostgreSQL也有類似的主從架構(gòu)。主從架構(gòu)的優(yōu)點(diǎn)其實(shí)是架構(gòu)簡(jiǎn)單，大多數(shù)主從架構(gòu)除了可以實(shí)現(xiàn)異地的數(shù)據(jù)容災(zāi)以外，也可以提供讀寫分離的能力（即主寫備讀），提升數(shù)據(jù)庫(kù)整體性能表現(xiàn)。
主從架構(gòu)主要需要考慮的問題是在switchover或failover后，應(yīng)用能夠正確連接到正確角色的數(shù)據(jù)庫(kù)上，在這一點(diǎn)上MySQL提供了MySQL Router，三方開源則有MHA和Orchestrator等；Oracle則有TAC和GDS等。

2 集群

這里說的集群要區(qū)分于分布式架構(gòu)，主要涉及MySQL Group Replication（MGR）和Oracle RAC架構(gòu)等。

（Oracle Real Application Cluster (RAC)）

這里的集群主要是在實(shí)例級(jí)別提供高可用，即集群內(nèi)部分實(shí)例故障，不影響數(shù)據(jù)庫(kù)提供服務(wù)。但在RAC架構(gòu)中仍可能有存儲(chǔ)的單點(diǎn)故障，因此存儲(chǔ)側(cè)也應(yīng)該實(shí)現(xiàn)高可用。當(dāng)然在集群之上也可以和主從架構(gòu)配合使用，提供異地容災(zāi)能力。

（Oracle RAC+DG）

3 分布式

無論是Redis、MongoDB還是大量的國(guó)產(chǎn)數(shù)據(jù)庫(kù)，都提供了分布式數(shù)據(jù)庫(kù)架構(gòu)。

（OceanBase 4.x）

其實(shí)簡(jiǎn)單來看，就是每個(gè)分片內(nèi)以主從或者副本的方式，分片每個(gè)節(jié)點(diǎn)可以在不同的地域，實(shí)現(xiàn)高可用。而數(shù)據(jù)庫(kù)的訪問接口則一般通過分布式集群本身來管理并提供服務(wù)。分布式架構(gòu)中，只要不是某個(gè)分片的所有節(jié)點(diǎn)全掛的情況出現(xiàn)，理論上不會(huì)出現(xiàn)數(shù)據(jù)庫(kù)異常。

4 誤區(qū)

前兩天一朋友的數(shù)據(jù)庫(kù)通過主從架構(gòu)上線實(shí)現(xiàn)了國(guó)產(chǎn)數(shù)據(jù)庫(kù)的上線，本是一件好事，但是有些人卻說，不是分布式，高可用不行啊。其實(shí)反觀下整體架構(gòu)，這些人為啥看不到，別人用1+1的節(jié)點(diǎn)解決了分布式需要10+臺(tái)服務(wù)器才能解決的問題。不得不說，分布式數(shù)據(jù)庫(kù)在高可用上看似非常美好，但是節(jié)點(diǎn)數(shù)量的提升帶來的管理壓力提升、元數(shù)據(jù)維護(hù)增加、網(wǎng)絡(luò)壓力增大等，而且分布式不一定適合所有應(yīng)用場(chǎng)景產(chǎn)生的數(shù)據(jù)結(jié)構(gòu)和業(yè)務(wù)場(chǎng)景（這里還不考慮業(yè)務(wù)代碼變更）。

5 光是數(shù)據(jù)庫(kù)？

舉個(gè)栗子，數(shù)據(jù)庫(kù)實(shí)現(xiàn)異地容災(zāi)，且前端應(yīng)用可以自動(dòng)連接到對(duì)應(yīng)角色的實(shí)例。但是業(yè)務(wù)應(yīng)用程序卻只部署在了一個(gè)地方，那么如果這個(gè)地方整個(gè)IDC出現(xiàn)異常，那么前端業(yè)務(wù)同樣不可能實(shí)現(xiàn)容災(zāi)切換，所以應(yīng)用程序也需要多地部署。

總結(jié)

本期淺談了一下數(shù)據(jù)庫(kù)的高可用，我認(rèn)為一切還是從需求出發(fā)，結(jié)合可接受成本來做高可用。
老規(guī)矩，知道寫了些啥。