Home | 簡體中文 | 繁體中文 | 雜文 | Search | ITEYE 博客 | OSChina 博客 | Facebook | Linkedin | 作品與服務 | Email

金融交易系統異地災備方案

http://netkiller.github.io/journal/trader.html

Mr. Neo Chen (陳景峯), netkiller, BG7NYT


中國廣東省深圳市龍華新區民治街道溪山美地
518131
+86 13113668890


版權聲明

轉載請與作者聯繫,轉載時請務必標明文章原始出處和作者信息及本聲明。

文檔出處:
http://netkiller.github.io
http://netkiller.sourceforge.net

微信掃瞄二維碼進入 Netkiller 微信訂閲號

QQ群:128659835 請註明“讀者”

2016-06-28

摘要

本文從災備角度出發,並不侷限于災備,而是從多維度讓你看到完成災備需要做哪些工作,解決哪些問題。

災備不僅僅是運維的工作,一個完善的災備系統需要多個部門的努力,網絡拓撲需要做特別的調整,伺服器需要特別的部署,軟件方面需要配合災備做特別的開發,才能滿足災備的需求,最終實現真正的7*24*365災備,並且儘量做到無人值守故障轉移。


目錄

1. 背景

隨着各種金融交易的推出,金融市場必將非常活躍,交易量的快速增加對交易系統產生了更大的壓力,如何使交易系統平穩運行,成為金融公司的頭等大事。 隨着客戶風險意識的增強,保證關鍵核心業務系統持續成功運作的需要,將發生風險的損失降到最低,保證企業的核心競爭力,金融公司對交易系統的可靠性提出了更高的要求。 目前金融公司普遍安裝了熱備份系統,達到了一定程度上的備份,但無法應對整個機房或大樓的災難事故,這就需要在異地建立一套金融交易系統,一旦主系統發生問題,且無法啟動熱備的情況下,馬上切換到異地災備系統進行交易。

1.1. 建立容災系統需要考慮哪些因素

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

  1. 數據的高可用性:災備系統應具有可靠性,同時災備系統的計算機系統故障不應影響業務的正常操作,達到 (Recovery Time Objective) “恢復時間目標”的要求。
  2. 減少數據丟失:達到 RPO (Recovery Point Objective)“恢復點目標”的要求。作為災備的系統,最主要的功能是將交易過程中的數據能在最短的延時情況下,同步到災備系統,最低限度丟失數據。
  3. 高性能:災備系統不應影響數據源系統的正常運行,應當高效地利用網絡,並允許各點採用最佳化的方法存取本地數據。
  4. 提高投資回報率:利用備份系統來支撐其他業務,以提高系統的利用率

1.2. 目前容災系統的實現方式

傳統的容災方式
  1. 基于存儲複製的容災,通過複製磁碟IO塊複製的方式,從生產中心向容災中心進行數據容災,根據複製設備的不同,又可以分為:基于主機,基于磁碟陣列,基于智能SAN,虛擬存儲設備
  2. 基于資料庫的容災,通過複製資料庫日誌或者數據檔案方式,從生產中心向容災中心進行數據容災
  3. 基于應用的容災,應用指向2個同時運作的數據中心,在任意一個中心活動情況下繼續工作

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

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

1.3. 系統災難恢復等級劃分

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

我國災難恢復等級劃分國信辦檔案 2005 “重要信息系統災難恢復指南”
  1. “第1級”:數據介質轉移(備份介質異地存放和定期更新)
  2. “第2級”:備用場地支持(異地介質存放和備份中心支持)
  3. “第3級”:電子傳送和部分設備支持
  4. “第4級”:電子傳送和完整設備支持
  5. “第5級”:實時數據傳送及完整設備支持
  6. “第6級”:零數據丟失

我認為等級劃分應該為

災難恢復等級劃分
  1. 第一級:冷備份

  2. 第二級:雙機熱設備份(HA高可用, 通常為 Active Standby)

  3. 第三級:雙活互備份(Active-Active 雙機互備)

  4. 第四級:負載均衡(隨時新增節點,移除節點,橫向擴展)

  5. 第五級:異地災備

  6. 第六級:全球負載均衡(分散式災備)

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

1.4. 做災備你面臨最大的挑戰是什麼?

What are your biggest disaster recovery challenges?
  1. Scalability(可擴展性)
  2. Availability(可用性)
  3. Performance(性能)
  4. Flexibility(靈活性)

2. 災備整體解決方案

雙機設備已經推出歷史舞台,基于主備的數據中心方案也顯得過時,我只推薦雙活的備份方案。

2.1. 雙活互備方案

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

雙活互備方案的優點
  1. 切換成功率高:災備系統的核心部件基本處于運行狀態,不存在災備切換時起不來的情況。
  2. 切換時間快:由於切換的時候,省去了災備系統啟動各服務性程序,與交易所數據同步等操作,可以進一步縮短切換的時間。
  3. 數據實時性高:數據的實時性可以與主系統達到同步。
  4. 數據丟失率低:可以保證主系統中只要已經報入交易所的委託,災備系統都可以獲取到。
雙活互備方案的缺點
  1. Active-Active 可以會出現數據不同步,兩機交易伺服器數據出現差異
  2. 實時同步對網絡環境要求比較高,這個不用過于擔心,目前IDC的網絡環境越來越好。

提示

另外需要注意的是當雙活啟動時,平均分配用戶到兩套交易系統上,如果一個交易系統出現故障,可能會增加另一個交易系統訪問壓力,所以要注意監控兩個交易系統伺服器的使用情況。

2.2. 三機房互備方案

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

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

3. 數據中心網絡

滿足災備前提是網絡暢通無阻,同時網絡拓撲設計能夠支持災備。

數據中心要求
  1. 供電要求:雙路供電,電力來自不同的發電廠,UPS 後備電源,柴油發電機組

  2. 空調要求:通常從地面送風的機房比較好

  3. 室內氣體監控:數據中心應該具備氣體監控,室內粉塵,濕度監控

  4. 消防:二氧化碳滅火器

  5. 機櫃:機櫃有很多規格,雖然都能放入機架伺服器,但有些比較小,沒有提供電源綫與網路槽。220V電源與網綫混在一起可能造成一定的數據丟包。

  6. 網絡設備:我常常考察一個機房會看他們的核心出口設備(是否有頂級的Cisio設備)

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

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

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

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

3.2. 雙機房互備異地災備方案

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

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

3.3. 三機房互備異地災備方案

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

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

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

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

4. 伺服器部署

一旦數據中心網絡部分完成,下一步就是部署各種伺服器,同時伺服器的部署必須滿足災備的要求,否則無法實現災備切換與故障轉移。

伺服器與交換機連接,按照伺服器重要程度或者是否具備故障轉移,有兩種方案,如具備分散式部署的伺服器可能只連接一條網綫,有些伺服器無法分散式部署,我們是兩個網卡分別連接兩條網綫到兩台交換機,同時網卡綁定為一個適配器。

4.1. 網站

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

圖 4. 動態頁面方案
動態頁面方案

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

動態頁面伺服器
  1. SSL:負責處理用戶請求的加密與解密,我們將它與WEB分離,這樣能夠更好的伸縮擴展,同時提供故障轉移功能,我們可以部署很多台這樣的伺服器。在不同城市,然後通過智能DNS將用戶解析到距離用戶最近的節點上。

  2. WEB:動態頁面伺服器

  3. API: Service 伺服器,可以通過SOAP, JSON, MQ等等方式訪問,WEB任何操作都要請求API伺服器完成,WEB伺服器不允許直接操作資料庫,全交由API處理。API具有運用層防火牆的功能與ACL訪問控制列表。

  4. Admin:網站後台

  5. HA:負載均衡軟件或設備

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

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

4.2. 數據源

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

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

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

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

4.3. 資料庫

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

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

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

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

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

提示

如果是三個以上機房,將採用環形複製,大致原理Master A向Master B複製,Master B向 Master C複製,Master C在向Master A 複製,形成一個環路。

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

5. 軟件開發

軟件的設計都要圍繞着災備進行,不能分散式運行,就不合格。

5.1. 交易軟件分散式交易

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

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

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

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

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

解決掛單問題,通常交易是即時完成的,較難處理的就是掛單。

下面的方案是最簡單的,開發難度最低。

資料庫表中增加一個欄位例如

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

trader1 表示該記錄產生在trader1 必須在Trader 1上完成成交

trader2 表示該記錄產生在trader2 必須在Trader 2上完成成交

測試用例
  1. Trader1 上登陸,下單,然後退出
  2. 在Trader2 上登陸如果1 | trader1 | xxxxx 沒有成交,將node 改為 trader2 同時將掛單數據載入到Trader2伺服器的內存中。
  3. Trader1 的中的掛單將失效
  4. 如果登陸Trader2前1 | trader1 | xxxxx 已經成交,就放棄載入內存。

提示

更新記錄狀態必須增加node條件
				
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技術也比較成熟。

5.2. 交易終端

5.2.1. 用戶分流

用戶分流是指,不同用戶登錄到不同的伺服器上進行交易。因為我們的交易系統是可以水平擴展的,可以有很多台交易伺服器並且都是Active狀態,任意一台伺服器都能登陸交易,我們可以使用哈希算法基于用戶ID,將用戶分流到指定伺服器。

用戶分流還可以使用智能DNS技術,將用戶分流到距離自己最近的交易伺服器上。

還可以根據路由TTL值與Ping值進行優先順序分配。

5.2.2. 會話保持

交易終端與交易伺服器一旦連接,出現超時中斷,人為退出,下一次連接還應該上一次連接的那台交易伺服器。

如果是交易伺服器無法連接將會重新分配一台,並記錄配置

如果交易伺服器採用的是雙向通知,或者消息隊列技術,可不必記錄登陸伺服器,可能按照最小連連接數算法分配伺服器。

5.3. API 應用程序介面

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

圖 9. CVS開發框架

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

5.4. 大數據的問題

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

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

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

5.4.1. 第一個階分區表

第一個階段數據分區存儲,實施規劃是五年之內。五年之內你可以使用分區這種技術存儲數據。分許能夠保持索引的連續,方便複雜的資料庫查詢。

5.4.2. 第二個階分庫分表

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

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

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

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

圖 11. 推薦的分表方案
推薦的分表方案

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

圖 12. 基于功能分表方案
基于功能分表方案

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

5.5. 數據校對

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

6. 自動化運維

自動化運維保障伺服器快速部署,改善災備的響應速度。尤其是需要重建某些伺服器的時候。

自動化運維應具備
  1. 自動化安裝
  2. 自動化配置
  3. 自動化運行
  4. 自動化備份
  5. 自動化診斷
  6. 自動化監控

自動化運維可以降低人為因素產生的故障,如誤刪除。

7. 災備培訓和演練

演練的主要目的是,驗證兩個交易系統能夠互備,相互做對方的備份,我們將當前登錄的系統稱為主系統,另一次叫做災備系統(僅僅是觀看的角度)。

另一個目的是,雙活系統能夠自動規避很多小災難,災難沒有擴大前系統已經自動修復了,長此以往系統管理員就會麻木,懶惰,僥倖。當更大的故障發生或雙活不能正常工作時,由於管理員長期不再狀態,就會產生難以預期的後果。

7.1. 培訓內容

  1. 災備原理

  2. 災備中心繫統結構(系統部署圖、網絡結構圖)

  3. 災備系統運營維護

  4. 公司操作流程

  5. 切換操作流程

  6. 數據檢查與驗證

7.1.1. 培訓對象

公司災備應急小組所有成員

其他感興趣員工

7.1.2. 操作流程

公司操作流程
  1. 報告災難發生並申請災備切換
  2. 確認災難發生並同意災備切換(主交易中心無法進行正常交易)
  3. 獲取授權
  4. 做切換前準備
  5. 切換到災備系統
  6. 切換後檢查
  7. 切換後報告
  8. 發佈消息(通知營業部、客戶)
  9. 進行正常交易

7.2. 演練環境設置

業務準備
  1. 確定演練時間

  2. 通知參與演練的客戶

  3. 通知參與演練的業務部門

技術準備
  1. 做好演練前的數據備份

  2. 檢查災備各應用服務狀態

參與部門
  1. 開發部門

  2. 測試部門

  3. 業務部門

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

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

7.3. 演練級別與方式

演練級別定義
  1. 接入線路故障
  2. 網絡設備故障
  3. 伺服器故障
  4. 資料庫故障

演練的方式有兩種

演練方式
  1. 有計劃的演練,通知各部門,災備應急小組人員各就位,然後開始演練
  2. 突擊演練,在沒有通知其他部門的情況下,臨時啟動演練,搶修主交易系統。

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

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

7.4. 開始演練

7.4.1. 切換前操作

切換前操作
  1. 確認資料庫已經備份無誤
  2. 檢查監控系統是否正工作,短信網關是否正常工作

主要的工作室數據備份,其他工作可能作為演練的一部們,工作流程等各種問題在演練中暴漏出來,才能對後面的工作改進有所幫助。

7.4.2. 切換操作

雙活互備切換操作,要進行兩次,第一次將A機房視為主機房,從A向災備機房B切換。完成後檢查無誤,再反向操作一次。

切換要模擬各種故障,通常採用的手段就是拔網綫,關閉伺服器,關閉應用,使其每條災備鏈路都能跑通。

數據中心故障
  1. 模擬機房停電,將另一側災備機房關機

  2. 接入鏈路故障

  3. 防火牆設備故障

  4. 交換機故障設備故障

伺服器故障
  1. 網站故障
  2. 數據源故障
  3. 交易伺服器故障
  4. 資料庫故障

切換過程中,每一次動作,都應該收到來自監控系統的報警並精確描述的故障。這也是完善監控系統絶佳機會。

7.4.3. 切換後檢查

由於數據實時採集同步存在延時以及線路中斷可能,導致同步時存在數據丟失,故災備系統中的數據與主交易系統的數據可能存在不一致,故客戶端連上災備系統後,需要重新登錄,獲取災備系統中的數據進行確認,在確認正確後,即可重新進行交易。

檢查項目
  1. 網站訪問壓力是否正常
  2. 交易系統的壓力是否正常
  3. 數據同步是否正常
  4. 數據源是否正常
測試部門介入項目
  1. 開戶,入金,出金
  2. 行情數據
  3. 各種交易情況驗證
  4. 交易記錄
  5. 各種報表
  6. 多方面的數據核對

7.5. 演練結果檢查

應用系統服務狀態檢查
  1. 主庫備庫數據是否一致

  2. 介面能否正常工作

  3. 網上交易能否正常進行

  4. 交易壓力是否正常

公司需要進行多方面的數據核對,包括
  1. 委託單是否一致, 委託回報是否完整

  2. 成交回報是否完整, 交易記錄是否完整

  3. 行情數據是否正確

  4. 客戶資金是否正常

7.6. 可能存在的風險

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

7.6.1. 主交易系統短期無法恢復

由於發生重大事件,可能造成災害發生時切換到災備中心的交易系統無法切換回主交易系統。導致交易需要長時間在災備中心運行,對災備中心形成壓力。對於此情況,公司應該制定詳細的預案,保證災備中心能承擔起正常交易壓力,使用戶交易正常進行。 當確認災備中心無法在短時間切換回主交易中心時,公司應立即啟動預案,並和服務部門聯繫,請求技術支持。通過增加伺服器、增加訪問頻寬、交易數據備份等方式,使災備中心轉換為主交易系統,長期承擔主交易系統交易工作。

7.6.2. 切換災備系統後業務的影響

當主交易系統需要切換到災備系統時,為避免一部分人仍然連接到主交易系統,一部分人連接到災備系統,切換前必須關閉主交易系統的應用伺服器或者段外網絡。

在切換以後,有部分業務將受影響,以下為部分情況:
  1. 各類終端需要重新登錄,如果有業務流水沒有同步到災備系統,則會丟失部分業務數據。
  2. 客戶的尚未觸發的條件單不再有效也不會再觸發,這個必須和客戶聲明,避免引起糾紛;
  3. 第三方交易系統在災備切換後,也需要進行切換,否則會無法使用。

7.6.3. 數據不同步產生的影響

由於數據同步時,存在延時,故有可能災備系統和主系統之間線路中斷後,有部分已經發生的業務沒有同步到災備系統中,部分業務也會受些影響, 故客戶端切換到災備系統中時需要重新登錄系統,以便重新查詢資料庫中的數據進行核對。

相關影響如下:
  1. 雙活互備相互切換,導致兩套數據中的數據不一致,系統管理員可以重新同步資料庫;
  2. 主交易系統中已經生成但沒有發往交易所的委託單沒有同步,此時災備系統中將沒有這筆記錄,且資金是不凍結的;
  3. 主交易系統中已經發往交易所的委託單沒有同步,此時災備系統中將沒有這筆記錄,且資金是不凍結的,需要補發此筆委託的委託回報;

7.7. 災備系統備份

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

7.8. 系統運營維護

應用系統服務狀態檢查
  1. 每日實時監控
  2. 每日無人值守備份檔案傳輸到備機上
  3. 保證交易系統升級版本相同
  4. 每月做一次災備切換預演,確保備份系統能正常工作
  5. 嚴重災難記錄

8. FAQ

8.1. 實現雙活最大的障礙是什麼?

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

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

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

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

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

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

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

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

8.2. 雙活怎麼解決數據衝突問題

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

如有下面兩個伺服器,每個伺服器有各自的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
			
comments powered by Disqus