跨機(jī)房問題解決方案
跨機(jī)房問題一直都是一個(gè)老大難的問題，先看傳統(tǒng)數(shù)據(jù)庫(kù)的跨機(jī)房方案。
Master/Slave方案
這是最常用的方案，適用于大多數(shù)需求。Master將操作日志實(shí)時(shí)地發(fā)送到Slave，Slave當(dāng)成Master的一個(gè)Hot Backup。Master宕機(jī)時(shí)，服務(wù)切換到Slave，需要修改客戶端邏輯使得Master失效時(shí)自動(dòng)尋找新的Master。
這個(gè)方案有一個(gè)問題就是數(shù)據(jù)庫(kù)的Master和Slave一般不是強(qiáng)同步的，所以，切換到Slave后可能丟失宕機(jī)前的少量更新。如果將Master和Slave做成強(qiáng)同步的，即：所有的數(shù)據(jù)必須同時(shí)寫成功Master和Slave才成功返回客戶端，這樣又帶來了另外一個(gè)問題：Master和Slave中任何一臺(tái)機(jī)器宕機(jī)都不允許寫服務(wù)，可用性太差。因此，Oracle有一種折衷的模式：正常情況下Master和Slave是強(qiáng)同步的，當(dāng)Master檢測(cè)到Slave故障，比如Slave宕機(jī)或者M(jìn)aster與Slave之間網(wǎng)絡(luò)不通時(shí)，Master本地寫成功就返回客戶端。采用這種折衷的同步模式后，一般情況下Master和Slave之間是強(qiáng)同步的，Master宕機(jī)后切換到Slave是安全的。當(dāng)然，為了確保數(shù)據(jù)安全后，宕機(jī)的Master重啟后可以和新的Master(原有的Slave)對(duì)比***更新的操作日志，如果發(fā)現(xiàn)不一致可以提醒DBA手工介入，執(zhí)行數(shù)據(jù)訂正過程。
Master和Slave之間強(qiáng)同步還有一個(gè)問題就是跨機(jī)房延時(shí)，對(duì)于關(guān)鍵業(yè)務(wù)，同城的機(jī)房可以部署專用光纖，在硬件層面上解決這個(gè)問題；異地的機(jī)房一般用來做備份，與主機(jī)房之間的數(shù)據(jù)同步一般是異步的，可能有秒級(jí)延時(shí)。
Bigtable跨機(jī)房方案
Bigtable跨機(jī)房部署兩套集群，每個(gè)機(jī)房有各自的GFS存儲(chǔ)和Bigtable Master。機(jī)房之間的數(shù)據(jù)同步方式為異步，類似Master/Slave方案。Bigtable Tablet Server將操作日志Flush到GFS成功后返回客戶端，并生成異步任務(wù)將操作日志同步到備機(jī)房。這里的難點(diǎn)在于Tablet Server宕機(jī)時(shí)，某些操作日志還沒有完成同步，因此，操作日志同步點(diǎn)也需要記錄到GFS中，當(dāng)其它Tablet Server加載宕機(jī)Tablet Server原先服務(wù)的tablet時(shí)，將繼續(xù)發(fā)送沒有同步完成的操作日志到備機(jī)房。如果主機(jī)房整體發(fā)生故障，比如機(jī)房停電，可以手工將服務(wù)切換到備機(jī)房，這時(shí)會(huì)丟失***的一部分更新操作，需要人工執(zhí)行訂正操作。
Bigtable跨機(jī)房方案還有一個(gè)問題，為了提高壓縮率，Bigtable跨機(jī)房的同步是按列進(jìn)行的，而Bigtable保證行事務(wù)，這樣就可能出現(xiàn)某些行的部分列同步成功，部分列同步失敗，破壞行事務(wù)。早期的Google App Engine底層存儲(chǔ)為Bigtable，這個(gè)問題沒有給出自動(dòng)化的解決方案。
Megastore跨機(jī)房方案(基于Paxos)
一般來說，實(shí)際中使用的方案都是Master/Slave方案，Megastore中基于Paxos的方案理論上是目前***的，但是實(shí)現(xiàn)過于復(fù)雜，只有Google在工程上做了實(shí)現(xiàn)。Master/Slave方案的問題在于Master宕機(jī)時(shí)切換到Slave需要時(shí)間，為了保證不會(huì)同時(shí)出現(xiàn)兩個(gè)Master的情況，這個(gè)時(shí)間一般比較長(zhǎng)，比如30s ~ 1分鐘，而且不能做到自動(dòng)化。Paxos的好處在于允許多個(gè)機(jī)房同時(shí)做Master，同時(shí)提供寫服務(wù)，Paxos協(xié)議將通過Quorum-Based的策略保證達(dá)成一致。一般情況下，主機(jī)房作為Paxos協(xié)議的Leader提供寫服務(wù)，當(dāng)Leader發(fā)生故障時(shí)，備機(jī)房的節(jié)點(diǎn)可以被選為新的Leader提供寫服務(wù)。即使多個(gè)機(jī)房認(rèn)為自己是Leader，Paxos協(xié)議也能保證同一時(shí)刻只有一個(gè)Leader的寫操作被大家同意并生效，并且做到了宕機(jī)切換的自動(dòng)化。只要超過一半的機(jī)房沒有出現(xiàn)故障，Paxos協(xié)議就能夠保證不停寫服務(wù)。
Google App Engine目前依賴于Google Megastore，解決了機(jī)房宕機(jī)可能破壞行事務(wù)的問題。Amazon Dynamo也給出了一種Vector Clock的做法解決多點(diǎn)同時(shí)寫入的問題，這是一種事后驗(yàn)證的做法，理論上很有意思，但由于弱一致性，實(shí)踐上沒有特別成功的案例。
需要注意的是，Megastore中的復(fù)制方案在理論上很***，但實(shí)現(xiàn)過于復(fù)雜，基本沒有可行性。另外，無論采用怎樣的跨機(jī)房同步和切換方案，都不能解決強(qiáng)同步寫操作延時(shí)較長(zhǎng)的問題，一般來說，這個(gè)延時(shí)將達(dá)到幾十到幾百毫秒。
一種回避Paxos的切換方案
選主一般可以通過引入開源的Zookeeper做到，不過Zookeeper本身的穩(wěn)定性尚待考驗(yàn)，有一種回避Paxos的切換方案比較有意思。機(jī)房宕機(jī)切換自動(dòng)化成本太高，但是對(duì)于很多單點(diǎn)服務(wù)，機(jī)房?jī)?nèi)部宕機(jī)切換的自動(dòng)化很有必要。Oceanbase采用Linux的一個(gè)開源方案：Pacemaker，通過heartbeat和虛IP漂移的方式實(shí)現(xiàn)機(jī)房?jī)?nèi)部宕機(jī)自動(dòng)切換。由于主備切換本質(zhì)上是一個(gè)選主問題，理論上只有Paxos或者類似協(xié)議可以解決，而Pacemaker沒有采用復(fù)雜的Paxos協(xié)議，它對(duì)硬件是有依賴的，比如要求主備節(jié)點(diǎn)之間通過直連線保證網(wǎng)絡(luò)不會(huì)發(fā)生故障，而這在機(jī)房?jī)?nèi)部是可以做到的。機(jī)房之間采用前面提到的Master/Slave方案，可以寫一個(gè)腳本ping主機(jī)房的Master，當(dāng)確認(rèn)主機(jī)房Master宕機(jī)時(shí)(比如一分鐘不通)將服務(wù)切換到備機(jī)房并報(bào)警。
【編輯推薦】
