通過簡單的配置，即可讓自己上傳的數據異步準實時地同步到另一個機房，實現跨機房的數據復制

在發生重大災難導致整個機房無法訪問時，可以將桶的上傳下載操作切換到災備機房，極大提升服務可用性

災備恢復服務切回主機房后，災備期間所有上傳到災備機房的數據都會同步回主機房，主機房有用戶全量的數據

通過接入NOS的子服務NCDN和WanProxy，整個災備過程可以對用戶完全透明

可以讓用戶自主選擇將桶創建在哪個機房（杭州機房，北京機房等）。用戶可以根據自己服務器的地址就近選擇桶所屬機房，提高上傳下載速度；

可以進一步實現跨機房的數據災備，提高災難情況下的系統可用性

當一個桶配置了跨分區災備的屬性后，該桶的所有更新操作，均會記錄在NOS_Sync表中（為了保證主從分區數據的一致性，寫入NOS_Sync表必須同原更新操作放在一個事務中）

NosSyncer同步程序定期將NOS_Sync表中的數據讀出，進行聚合處理后，將數據同步到指定的分區

為什么選擇將同步信息放在數據庫中？
其實，最初想到的辦法并不是將同步信息寫到數據庫中，而是在更新操作完成后，記錄一條日志，并通過日志收集，日志處理，處理結果上傳到隊列服務，再由NosSyncer從隊列服務中獲得待同步的任務并執行數據復制。這種實現方式的好處是，整個數據同步的邏輯是離線的，線上的服務只需要輸出一條日志即可，跨分區數據復制邏輯不會對當前的線上業務產生影響。
而該方案有兩個明顯的問題：
1）NOS支持覆蓋寫操作，例如兩個用戶可以同時上傳一個名為A的對象，后上傳成功的會覆蓋先上傳的。因此，同步信息的順序應該同實際插入的順序一致，才能保證同步到災備分區時也是同樣的操作順序，保證主從分區的數據一致性。而采用日志這種方式，多個NOS服務器上的日志收集順序是無法保證先后的（即使日志帶時間戳）。該問題可以通過抓取binlog日志來保證順序性。
2）該方案需要依賴日志收集，日志處理，隊列等一系列外部的服務，需要的部署和運維精力較大。同時，在我們設計該系統時，這些服務的可靠性還有待驗證，暫時不適用于我們的服務。

為什么將插入NOS_Sync表的操作同更新操作放在同一個事務里？
這主要是為了保證所有的更新操作和NOS_Sync表中的同步信息一一對應，而同步信息按順序插入，同步程序只需要順序讀取同步信息并以此執行即可，這可以保證復制操作的執行順序和實際更新順序一致。

數據復制的邏輯可以進行什么優化？
數據復制優化有兩個方向：1) 并發復制； 2）減少復制數據量；
具體做法是，在取出一組同步信息后，首先在內存中對同步信息進行處理：
1）過濾不必要的同步操作（例如：上傳A(file1)，上傳A(file2)，上傳A(file3) 可以合并為 上傳A(file3)）
2）確認哪些操作可以并發執行（例如：上傳A(file1)，上傳B（file2）直接可以并發執行）
在進行數據復制時，首先調用去重操作，如果可以去重上傳，則不傳輸數據。

下行災備情況一：用戶過CDN下載，災備時直接切換CDN回源地址，災備過程對客戶端透明（災備切換時間約5分鐘）

下行災備情況二：有邏輯的客戶端，在感知到主分區故障后，主動切換訪問到災備分區，災備過程需要客戶端配合

下行災備情況三：無邏輯的客戶端（如瀏覽器），若要災備則需要切換域名，由于切換域名生效時間過久，線上基本不會操作

上行災備情況一：用戶過WanProxy進行上傳，災備時WanProxy自動將上傳切換到災備機房，災備過程對用戶透明

上行災備情況二、情況三：客戶端依賴產品的上傳服務器來進行上傳，當發生災備時，需要上傳服務器切換（或通知用戶切換）上傳地址，災備過程需要上傳服務器配合

災備分區 —— 主機房發生災難時服務切到哪里，正常狀態下，數據從主機房復制到災備機房

是否切換 —— 主機房發生災難時，通過該字段設置主備切換

由于硬件條件限制（機房間無專線，數據傳輸走公網），因此不建議對大對象（如視頻）實施災備服務。

用戶可以將自己的數據按照重要程度放在多個桶中（如視頻，圖片，重要文件等），并對最重要的桶開啟災備服務，保證災難狀態時可以提供最基本的服務。

逐漸將產品的上傳切到WanProxy上傳服務，將下載切到NCDN服務，從而透明地實現跨機房災備。