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