說明
災備： 是指容災和備份。容災是爲了在遭遇災害時能保證信息系統能正常運行，幫助企業實現業務7*24小時連續性的目標，備份是爲了應對災難來臨時造成的數據丟失問題。容災備份產品的最終目標是幫助企業應對人爲誤操作、軟件錯誤、病毒入侵等“軟”性災害以及硬件故障、自然災害等“硬”性災害。
兩地三中心：
- 兩地是指同城、異地
- 三中心是指生產中心、同城容災中心、異地容災中心。
備端在線兩地三中心災備方案網絡設計如下：
容災系統 衡量指標
衡量容災系統的主要指標有
- RPO(Recovery Point Object) :災難發生時允許丟失的數據量
- RTO(Recovery Time Objective) : 系統恢復的時間
- 容災半徑: 生產系統和容災系統之間的距離
- ROI(Return of Investment): 容災系統的投入產出比
RPO 是指業務系統所允許的災難過程中的最大數據丟失量（以時間來度量），這是一個災備系統所選用的數據複製技術有密切關係的指標，用以衡量災備方案的數據冗餘備份能力。
RTO 是指“將信息系統從災難造成的故障或癱瘓狀態恢復到可正常運行狀態，並將其支持的業務功能從災難造成的不正常狀態恢復到可接受狀態”所需時間，其中包括備份數據恢復到可用狀態所需時間、應用系統切換時間、以及備用網絡切換時間等，該指標用以衡量容災方案的業務恢復能力。例如，災難發生後半天內便需要恢復，則 RTO 值就是十二小時。
容災半徑是指生產中心和災備中心之間的直線距離，用以衡量容災方案所能防禦的災難影響範圍。
容災方案的 ROI 也是用戶需要重點關注的，它用以衡量用戶投入到容災系統的資金與從中所獲得的收益的比率。
顯然，具有零 RTO 、零 RPO 和大容災半徑的災難恢復方案是用戶最期望的，但受系統性能要求、適用技術及成本等方面的約束，這種方案實際上是不大可行的。所以，用戶在選擇容災方案時應該綜合考慮災難的發生概率、災難對數據的破壞力、數據所支撐業務的重要性、適用的技術措施及自身所能承受的成本等多種因素，理性地作出選擇。
做災備你面臨最大的挑戰是什麼？
- Scalability(可擴展性)
- Availability(可用性)
- Performance(性能)
- Flexibility(靈活性)
容災級別
按照容災系統對應用系統的保護程度可以分爲數據級容災 、 應用級容災 和 業務級容災。
數據級容災 僅 將生產中心的數據複製到容災中心，在生產中心出現故障時，僅能實現 存儲 系統的接管或是數據的恢復 。容災 中心的數據可以是本地生產數據的完全複製（ 一般 在同城實現） ， 也可以比生產數據略微落後，但必定是可用的 （一般 在異地實現） ， 而差異的數據 通常 可以通過一些工具（ 如 操作記錄、日誌等） 可以 手工補回。基於數據容災 實現 業務恢復的速度 較慢 ，通常情況下 RTO 超過 24 小時， 但是這種 級別 的容災系統運行維護成本較低。
應用級容災是 在數據級容災的基礎上，進一步實現應用 可用性 ，確保業務的快速恢復。這就 要求 容災系統 的 應用不能改變原有業務處理邏輯，是對生產中心繫統的基本複製 。因此 ，容災中心需要建立起一套和本地生產相當的備份環境，包括主機、網絡、應用、 IP 等 資源均有配套，當 生產 系統發生災難時，異地系統可以 提供 完全可用的生產環境。 應用級 容災的 RTO 通常 在 12 個 小時 以內 ，技術複雜度較高，運行維護的成本也比較高。
業務級容災 是生產中心 與容災中心對業務請求同時進行 處理 的容災方式，能夠確保 業務 持續可用。這種 方式 業務 恢復 過程的自動化程度高， RTO 可以 做到 30 分鐘 以內 。 但是 這種容災級別 的 項目 實施難度大， 需要從 應用層對系統進行改造，比較適合流程固定 的 簡單業務系統 。 這種 容災系統 的運行維護成本最高。
同城容災
同城容災 是在同城或相近區域內 （ ≤ 200KM ）建立兩個數據中心 : 日常情況下可同時分擔業務及管理系統的運行，並可切換運行；災難情況下可在基本不丟失數據的情況下進行災備應急切換，保持業務連續運行。
與異地災備模式相比較，本地雙中心具有投資成本低、建設速度快、運維管理相對簡單、可靠性更高等優點；異地災備中心是指在異地建立一個備份的災備中心，用於雙中心的數據備份，當雙中心出現自然災害等原因而發生故障時，異地災備中心可以用備份數據進行業務的恢復。
異地容災
異地容災 主備中心之間的距離較遠 （＞ 200KM ) ， 因此一般採用異步鏡像，會有少量的數據丟失。異地災難備份不僅可以防範火災、建築物破壞等可能遇到的風險隱患，還能夠防範戰爭、地震、水災等風險。由於同城災難備份和異地災難備份各有所長，爲達到最理想的防災效果，數據中心應考慮採用同城和異地各建立一個災難備份中心的方式解決。
備端在線容災系統設計
1）當生產服務器處於正常工作狀態時，把生產服務器的監控代理軟件連接至服務器。當監控代理檢測到主存儲數據變化後，將捕獲變化的數據實時的複製到備用存儲上，實現了實時的複製。具體部署如下圖：
2）當生產服務器故障，或者存儲故障導致生產系統無法正常提供業務支持時，本地容災服務器可直接接替生產服務器工作保障業務系統的持續運行；當本地機房發生災難時，異地機房的容災服務器可直接接替生產服務器工作保障業務系統的持續運行。具體部署如下圖：
3）當生產系統恢復工作後，代理軟件會繼續其生產服務器的複製工作，並且在這之前會通過回切工具保障主備系統數據一致，具體部署如下圖：
異地容錯的容災系統設計
如果本地機房發生故障，將異地容災服務器中備份的數據進行手動恢復，可以直接恢復到原生產服務器（也可恢復到新服務器）。備份存儲系統保存了應用系統任意時刻的數據，恢復時可恢復到任意時間點，實現容錯，具體部署如下圖：
具體實施面臨的問題
1. 分類
根據是否需要數據同步大體分爲三類：
1、必須同步型。（比如數據庫）
2、無須同步型。比如緩存，僅僅是當做緩存，就可以這樣做（這個有待商榷，其實緩存也需要同步的，嚴格來說的話）。
3、只能單活（對全局原子要求較高），不接受有一定時延的“不一致”窗口。
2. 核心問題
數據同步、網絡時延。
3. 切換方式
1、自動切換。自動切換表現爲當災難來臨時，程序內部可以自動識別出問題然後切換至可用機房。
2、手動切換。通過簡單的配置，在幾分鐘或者一兩小時內切換到另外的機房。
4. 異地多活面臨的挑戰
4.1、切換問題。
切換問題不僅僅是災難發生自動切換到好的機房，還有另外一個問題，就是災難機房恢復能力後，如何再切換回去，切換回去的數據同步問題又是需要解決的。
4.2、跨機房流量問題。
跨機房的流量是花錢的。所以不是無限大的。控制跨機房消息體大小，越小越好。然而，很多時候要想保證數據同步是一件很耗費流量的事情。但跨機房流量真的是一座山。
既然跨機房流量有限制，而且不穩定。所以有一種解決方案就是不跨機房。既然不跨機房就要做用戶分區，確保每個用戶只能訪問自己所在的區，這樣至少能保證該用戶自己的數據的完整。
4.3、所有的業務都適合做異地雙活嗎？
異地多活效果看起來很誘人，但如果不假思索貪大求全的要求所有業務都實現異地多活的話，就會把自己帶到坑裏去。
第一個原因是異地多活是有成本的，包括開發成本和維護成本。需要實現異地多活的業務越多，方案越複雜，投入的設計開發時間越多；同時維護成本也會越高，需要更多的機器，需要更多的帶寬。
第二個原因是有的業務理論上就無法實現異地多活。典型的有“餘額”和“庫存”這兩個業務。
以餘額爲例，假設我們實現了餘額的異地多活業務，用戶小明有10000塊錢，在A機房給女友轉賬了5000塊，還剩餘5000塊；如果此時A機房異常且數據還沒同步到B機房，小明登錄到B機房發現自己又有10000塊了，小明感覺中彩票了，趕緊又轉了10000塊給女友，最後出現了小明只有10000塊卻轉賬了15000塊的問題，對於和資金相關的業務，這樣的問題是絕對無法容忍的，哪怕一個用戶有問題都不行。
所以，異地多活也不能保證所有業務都異地多活，在設計異地多活方案的時候，需要從業務和用戶的角度出發，識別出核心和關鍵業務，明確哪些業務是必須實現異地多活，哪些是可以不實現異地多活，哪些是不能實現異地多活的。比如“登錄”必須實現異地多活、“註冊”和“修改用戶信息”不一定要實現異地多活。
4.4、冷備還是熱備。冷備了以後，一直冷備，當真正出現問題，你還有勇氣去切換到那個一直冷的機房嗎？恐怕需要點勇氣。
4.5、數據一致性問題。
解決方案：
（1）守護進程同步。
（2）客戶端雙寫。
（3）不去解決。不需要解決的前提是用戶分區。分區後，從本質上說，其實是沒有做到雙活的。只是看起來一個業務確實被分到了多個機房而已。
4.6、讀取問題。
這個相對來說要好解決一些，就是就近讀取。
業務以及基礎組件異地雙活方案
數據庫的異地雙活
Zookeeper異地雙活
先來點背景知識：
1、zookeeper中的server機器之間會組成leader/follower集羣，1:n的關係。採用了paxos一致性算法保證了數據的一致性，就是leader/follower會採用通訊的方式進行投票來實現paxos。
2、zookeeper還支持一種observer模式，提供只讀服務不參與投票，提升系統。
異地多活決定了我們需要進行跨機房操作，比如杭州，美國，香港，青島等多個機房之間進行數據交互。
跨機房之間對應的網絡延遲都比較大，比如中美機房走海底光纜有ping操作200ms的延遲，杭州和青島機房有70ms的延遲。
爲了提升系統的網絡性能，在部署zookeeper網絡時會在每個機房部署節點，多個機房之間再組成一個大的網絡保證數據一致性。(zookeeper千萬別再搞多個集羣)。
說明：
a. 數據涉及網絡傳輸，S/E/T/L幾個階段會分散在2個或者更多Node節點上，多個Node之間通過zookeeper進行協同工作 (一般是Select和Extract在一個機房的Node，Transform/Load落在另一個機房的Node)
b. node節點可以有failover/loadBalancer. (每個機房的Node節點，都可以是集羣，一臺或者多臺機器)
業務實例異地雙活
業務實例的異地雙活。這個相對來說要簡單一些，只要做到無狀態，再如果通過Docker這些容器結束，基本上是相對來說容易一些。
消息隊列的異地雙活
rabbitmq 每個機房部署一套server，然後每個機房的業務使用各自機房的mq。通過haproxy自動映射到本機房的broker。topic同步，通過REST API讀取到
配置文件，然後同步到另外一個機房的rabbitmq下。
具體REST API：
http://17X.XXX.X.XXX:15672/api/definitions
以上只是同步了rabbitmq的元數據，而且是全量同步。
消息同步問題：如果不同步會導致消息丟失。所以mq消息其實也是需要同步的。
同步可以通過客戶端雙寫，或者服務端複製。雙寫更加容易。
Redis的異地雙活
Redis 的異地雙活。就是分別在每個機房搭建一套Redis集羣。 然後每個機房的業務都去訪問各自機房的Redis集羣。
但這樣只是能保證基本的緩存能力。如果業務中涉及到一些全局的原子操作，那麼這樣的做法顯然不能滿足需求。
原因很簡單，比如你使用redis incr自增命令：
a 機房 加1 後變爲了1，b機房的業務也加1， 本來應該是2。結果由於各自都是訪問了自己的redis，所以全局計數顯然是有問題的。
怎麼解決呢？就需要涉及到全局操作的業務，去單獨的連接 一個全局的唯一的那個 redis集羣，這個redis集羣專門用於 業務的全局操作。
但這樣的後果，就是會涉及到跨機房流量問題，因爲這個全局的redis集羣無論放在哪個機房，另外一個機房的業務要想訪問都得跨機房。
大數據的問題
數據量最大的當屬交易數據，有些金融產品雙向交易，交易時間長，所以交易數據的累積相當可觀。當交易數據積累到一定數量級，我們就可以從多角度數據挖掘，爲決策提供數據支持。
第一個階分區表
第一個階段數據分區存儲，實施規劃是五年之內。五年之內你可以使用分區這種技術存儲數據。分許能夠保持索引的連續，方便複雜的數據庫查詢。
第二個階分庫分表
當數據龐大到無論怎麼優化都無法提高查詢性能是，這時你就要考慮數據庫拆分了。
數據庫拆分需要遵循幾個原則，不僅僅是按照年份或月份分庫分表。
數據庫拆分
- 基於用戶拆分，要能保證查詢某個用戶的數據不需要跨庫，也不需要聯合多表查詢，這樣會降低查詢效率。
- 基於業務拆分，某些業務所用到的表，集中放在一臺服務器上，保證數據查詢不需要跨庫，或者聯合多表查詢。
圖. 傳統的分表方案
![傳統的分表方案]()
傳統方法，將數據日期切分，這回帶來索引的不連續問題，且查詢時必須加帶日期，以便定位到指定的表中。如果需要做數據挖掘，需要統計四年的數據，必須查詢四次，效率大打折扣。
圖. 基於用戶分表方案
新的拆分方案，通過哈西算法均勻的將用戶分配到指定數據庫中或表中。這樣所有針對該用戶的操作都能在同一個數據庫中完成。
圖. 基於功能分表方案
根據不同的功能拆分數據庫或表，也是一種非常不錯選擇。
參考
https://blog.51cto.com/zhaoshilei/1888923
http://blog.itpub.net/26736162/viewspace-2216584/
https://cloud.tencent.com/developer/article/1082855
https://baike.baidu.com/item/%E5%AE%B9%E7%81%BE%E5%A4%87%E4%BB%BD
https://www.netkiller.cn/journal/trader.html
