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