與簡單地將一部分數據從一台機器拷貝到另一台機器相比，企業內業務數據的複製要複雜的多。災備系統必須滿足以下所有業務需求：

以上的容災方案都顯得過時，這些老舊的容災方案依靠IOE(IBM，Oracle, EMC)提供的解決方案，IOE的方案通常是通用很強，你只能按照他們要求實施，IOE並不清楚我們的業務邏輯，所以方案不一定是最好的，另外一旦使用了IOE產品，就會被他們綁架，金錢投入無休止。

隨着開源軟件技術發展，IOE的產品優勢越來越不明顯，技術固步自封，影響到了用戶甚至成為企業發展的瓶頸，IOE投資回報率沒有性價比，不符合當下互聯網時代。

系統災難恢復有國際標準，我國也有自己的系統災難恢復標準，一般分為六個等級，但我覺得都較為過時，不符合互聯網時代 。

我認為等級劃分應該為

從第二級開始就具備“零數據丟失”，遠遠高於國家標準與國際標準。一級可能需要人工介入，但從第二級開始都是無人值守，到第三級可以達到7*24*365不停機運轉，實現智能故障轉移。

雙活互備不分主次機房，兩個機房同時對外提供服務，當一方出現故障時才會將用戶自動切換到另一個機房。

在雙活互備方案基礎上，我們還可以進一步擴展，做到三地互備，甚至更多的備份，但考慮到成本一般不會超過三個機房。

兩機房也好，三機房也罷，接入線路一定要選擇不同供應商。

單機房最大的優勢是網絡連接比較方便，很多公司購買的機櫃相鄰，可能從機柜上方走綫。

圖 1. 單機房高可用雙活互備解決方案

雙機熱備這種我認為是過時的技術，常常主系統出現故障時，你會發現備用系統無法工作。所以我設計的系統都是AA(Active-Active)所有節點都對外提供服務，能夠更早的發現問題。

圖 2. 雙機房異地災備方案

異地災備通常將兩個機房打通，但是由於線路頻寬有限(通常是1G雙絞綫或光纖 )我能做太複雜連接。通常我們將這條綫主要用戶數據複製，狀態同步，其他伺服器獨立工作。

圖 3. 三機房互備異地災備方案

三機房安全級別更高，採用三角路由方案，任何時刻都有兩條鏈路是暢通的，通過路由表優化決定一下跳，而且可以繞過故障節點。

三機房有三個入口，通過智能DNS將用戶解析到距離自己最近的節點上，用戶也可以在交易軟件端手動選擇。

三機房的資料庫採用環形複製

網站提供新聞，資訊，開戶，轉帳，活動，報表，在綫客服等等功能

圖 4. 動態頁面方案

上面是動態頁面方案，分為SSL伺服器，WEB伺服器，API介面伺服器，Admin伺服器。全部具備水平擴展與動態伸縮。下面分別詳細說明他們的功能，為什麼這樣部署。

與門戶網站不同，我們的網站訪問量並不大，性能瓶頸基本不存在，更多是考慮高可用。

靜態頁面以及CDN部門這裡就不談了，非常簡單，有興趣可能到http://netkiller.github.io/找相關資料。

在交易過程中出現報盤中斷是大忌，我們必須盡一切努力，讓交易系統能源源不斷的接收價格數據。為此我需要重點考慮數據源的災備。

圖 5. 數據源災備解決方案

我們設計了一個DataFeed程序，能夠多方接收數據，因為每個數據源提供的產品不同。我們在這裡可以合併，篩選，過濾等等。這個應用可以實現水平擴展，我們可以放在2個以上的機房當中。

接下來在交易伺服器中，設置多個數據源分別指向Data Feed 1,2~n。與Trader相同機房的DataFeed的優先順序總是最高。

數據的部署要考慮幾個問題，我一直不建議主備方案，而是採用雙活方案。所以我們要考慮兩個機房或者三個機房他們數據複製問題，性能瓶頸問題，數據安全問題等等

圖 6. 資料庫災備解決方案

上圖我的方案中採用了Master-Master雙活方案，同時每個Master都會有一個Slave。Master 主要用於主要的業務，Slave主要用戶數據分析，報表查詢等等非實時，且長時間允許等等查詢服務

資料庫訪問需要經過SLB伺服器，為資料庫提供負載均衡，故障轉移，水平擴展等等功能。

所有的數據操作只能通過API完成，不能直接連接資料庫並通過SQL存取，上面已經提到過，這裡不再多講。

如果資料庫查詢如果出現瓶頸，增加Slave即可。

交易軟件通常使用TCP私有協議，與我們常見的HTTP協議不同，HTTP是無狀態，即用戶請求-處理數據-渲染HTML頁面-銷毀並釋放內存，我們很容易開發基于負載均衡的橫向水平擴展的應用程序。 而交易軟件採用的是持久TCP連接，實時傳輸用戶請求，並將結果會送給用戶，中間過程不允許中款，且用戶狀態數據存儲在該交易伺服器的內存中，如果我們採用常規手段做負載均衡，就會出現用戶被分配到另一台伺服器上，而無法繼續交易。

我們首先要做的就是將用戶狀態持久化，有點類似我們在HTTP應用中將Session持久化方法，將這些數據存儲到公共的共享伺服器上。同時該伺服器也需要做高可用等等，保證無單點故障。

第二步，我們解決分散式交易，分散式交易是指可以在交易伺服器上任意一個節點上均可交易。方法有很多，複雜程度也不同。

通常解決分散式運行的方法，無非是同步|互斥排他鎖|共享存儲等等，其實就是兩多綫程的很多技術擴展到了互聯網上。使用節點同步解決共享內存訪問問題，使用遠程鎖解決解決多節點訪問問題等等。

-----------------------------------------
Id  | node | status | xxxxx
-----------------------------------------
1 | trader1 | N | xxxxx
2 | trader2 | Y | xxxxx
-----------------------------------------
				

				
Update tab set status=Y where id=1 and node =<my node> …
				
				

5.1.2. 分散式交易解決方案一

雙向通知的含義是Trader 1狀態發生改變會通知Trader 2， 反之Trader 2狀態發生改變會通知 Trader 1。

圖 7. 雙向通知解決方案

上圖可以看出通知與資料庫持久關係圖，在交易周期內實時接收通知，一旦收到通知，便根據通知中的指令做出反應，改變當前交易伺服器的狀態。

這種設計可以採用日誌複製，然後重做日誌的方式，非常累西資料庫同步技術，缺點是可能有延遲。設計需要考慮進去。如果超過三個節點就要採用環形複製

我曾經想過通過IP組播，廣播技術實現通知發佈，這樣就可以不設置目的地地址，同時增加了部署的靈活性，而且對於廣播節點數量沒有限制。比較適合三個以上的機房部署。

5.1.3. 分散式交易解決方案一

消息對列，即將所有交易伺服器接入到消息隊列中，所有通知均推送進入消息隊列，由消息隊列伺服器統一管理通知消息，同時消息具備持久化。

圖 8. 消息對列解決方案

這種方法將消息交換MQ去處理，免去了自行開發消息中間件，目前MQ技術也比較成熟。

上文反覆提到了API，關於API請參考我的另一邊文章《CVS開發框架》，這裡不再引用。

圖 9. CVS開發框架

框架講述的設計思路，你可以使用你最熟悉語言技術重新實現。

我們這個行業不是門戶網站，所以數據量不會非常大，但我們要未雨綢繆，我們在設計階段就將這些問題考慮進去，使將來不會困擾我們。

數據量最大的當屬交易數據，有些金融產品雙向交易，交易時間長，所以交易數據的累積相當可觀。

雖然你可以定時刪除，但我不建議。我認為交易數據需要永久保留，為什麼？ 當交易數據積累到一定數量級，我們就可以從多角度數據挖掘，為決策提供數據支持。

5.4.2. 第二個階分庫分表

當數據龐大到無論怎麼優化都無法提高查詢性能是，這時你就要考慮資料庫拆分了。

資料庫拆分需要遵循幾個原則，不僅僅是按照年份或月份分庫分表。

資料庫拆分

1. 基于用戶拆分，要能保證查詢某個用戶的數據不需要跨庫，也不需要聯合多表查詢，這樣會降低查詢效率。
2. 基于業務拆分，某些業務所用到的表，集中放在一台伺服器上，保證數據查詢不需要跨庫，或者聯合多表查詢。

圖 10. 傳統的分表方案

傳統方法，將數據日期切分，這回帶來索引的不連續問題，且查詢時必須加帶日期，以便定位到指定的表中。如果需要做數據挖掘，需要統計四年的數據，必須查詢四次，效率大打折扣。

圖 11. 推薦的分表方案

新的拆分方案，通過哈西算法均勻的將用戶分配到指定資料庫中或表中。這樣所有針對該用戶的操作都能在同一個資料庫中完成。

圖 12. 基于功能分表方案

根據不同的功能拆分資料庫或表，也是一種非常不錯選擇。

由於網絡傳輸丟包和延遲等客觀情況，當交易數據量比較大且並發請求過多時，可能導致數據無法同步成功或丟失，造成兩個交易系統數據不一致。 兩個交易資料庫的數據不對等，為瞭解決該問題，可採開發一個數據校對工具，對數據進行比對和修復。確保數據一致性和完整性。

模擬災難: 在演練開始時間，關閉主交易中心的所有的應用，模擬災難發生。此時，公司應完全按照“公司操作流程”和“災備系統切換流程”來切換災備系統。

演練過程: 見“切換操作”和“公司操作流程”

演練的方式有兩種

第一種方式適合災備演練初期，因為各部門都有準備，是在良好的環境下進行，大家都坐在電腦前，看著嚴控數據，有條不紊按部就班。

但故障是隨時都能出現的，是無法預知的。所以我們還需要實行“突擊演練”。“突擊演練”最近接真是故障發生的場景，可能大家會手忙腳亂，打破之前的各種流程。你會接到各部門領導的電話，可能你當時還在睡覺或外出路上，你沒有地方上網，你的腦子一片空白，這才是真實場景。

當主交易系統切換到災備系統後，必然會有一些影響業務的情況會發生，公司需要事先有所準備，並制定相關應急預案。

當災備中心承擔交易時，災備系統中的所有交易數據將進行備份，供事後的查詢和備案。公司可以採用熱備系統，備份災備中心的交易數據。並做好災備中心數據及時轉移到安全位置。確保災備中心數據不會丟失。

實現雙活最大的障礙是人，不是技術。你是否有足夠的權限起到很大的作用。

很多企業動不動講流程，跨部門溝通十分困難，甚至設置了很多部門防火牆（無形的牆），部門領導平級更是問題，這樣會無休止爭論下去，無法決策。

另外很多企業管理層不懂技術，無法做決策，有些領導更是怕擔責任。

開發人員都會牴觸你方案，因為在現有的穩定系統上增加改動且他並不理解的工作，後續的測試，驗收都受到影響。

運維也很不情願，只要是生產環境任何調整都存在一定的風險。

如果你的企業向上面一樣，企業已經在走下坡路了，不做事就不出事，拒絶創新.....

總之，裝B的人不在少數。

Many people think they are full of niubility and like to play zhuangbility, which only reflect their shability and erbility.

此文章已發佈，收到很多讀者的提問，雙活就是雙寫那麼怎麼解決同時寫入時的數據衝突問題。

如有下面兩個伺服器，每個伺服器有各自的ID，它們產生的數據類似下面

A伺服器: 1, 3, 5, 7
B伺服器: 2, 4, 6, 8
			

如果是三地數據中心，將產生類似如下的數據

A伺服器: 1, 4, 7, 10
B伺服器: 2, 5, 8, 11
C伺服器: 3, 6, 9, 12