新聞動態
技術中心
技術中心
當前位置:科達自控 >> 服務支持 >> 技術中心 >> 瀏覽文章
基于阿里云的雙活災備方案的設計
作者:黃濤 日期:2019年04月27日 來源:本站原創 瀏覽: 次

內容導讀:下面簡單介紹下各個方案的內容: 1.冷備:離線手工對數據進行容災備份,當發生故障時,手工切換到備用環境。 2.熱備:實時對主生產環境的數據進行備份,當發生故障時,自動或手工切換到災備環境。 3.雙活:兩套環境實時進行雙向數據同步,每套環境都承載其中一部分流量,當發生故障時,只由其中一套環境承載所有流量。

說起容災備份方案,一般說來有下面這個發展方向:
點擊瀏覽下一頁

下面簡單介紹下各個方案的內容:
1.冷備:離線手工對數據進行容災備份,當發生故障時,手工切換到備用環境。
2.熱備:實時對主生產環境的數據進行備份,當發生故障時,自動或手工切換到災備環境。
3.雙活:兩套環境實時進行雙向數據同步,每套環境都承載其中一部分流量,當發生故障時,只由其中一套環境承載所有流量。
只有進行數據同步所涉及到的內部,一般包含如下內容:數據庫(一般是MySQL)、Redis、MongoDB、搜索引擎(一般是ElasticSearch)和大數據應用(一般是HBase和HDFS)。由于容災方案很多,下面只針對阿里云下的方案進行講解。數據庫方面,則只將MySQL,其他數據庫可以觸類旁通。搜索引擎則只講ES(ElasticSearch)。
一、MySQL的數據同步
下面講兩種方案:
1.阿里云自帶雙活方案(DTS)
2.采用Canal實現
 阿里的MySQL災備方案,后面采用的就是阿里的DTS服務,可以根據流量等情況,選擇服務的類型。DTS使用很方便,可以實現表級(只同步需要的表)甚至是字段級別的數據同步。RDS有重連機制,基本上可以保障在發送MySQL主從切換等情況下,數據不丟失,但是下面一些情況需要重點關注:
1.DTS無法規避MySQL寫沖突,需要在業務上進行規避。最典型的場景,就是按照業務???,或者按照客戶歸屬性進行劃分,保證兩個中心,不會對同一條數據進行更新操作。
2.DTS有一定的表結構變化同步能力,但并不是全部,所以當發生表結構變化的時候,需要特別關注。第一種情況就是月表,如果是每個月生成一張月表,那么災備中心可能就有問題,可以一次性生成未來好幾年的月表。另外一種情況就是升級的時候,需要對表增加一個字段,這個時候最好是等待兩個中心同時更新完成后,才進行數據同步。
3.延遲不可避免,最好不要對一個中心寫,然后在另外一個中心讀。
第二種方案就是采用開源框架canal,自己寫代碼實現MySQL的數據同步,它的處理流程如下:​​​​
點擊瀏覽下一頁

canal的基本原理跟DTS一樣,就是讀取MySQL的binlog文件,然后將數據寫入kafka中,另外一份訂閱讀取數據,并將數據寫入到災備數據庫。
canal方案的好處就是開源的,不需要收費,當時它的可靠性肯定沒有DTS高,下面地方需要特別注意:
1.主從切換下的數據丟失:正常情況下,canal進行數據同步,肯定不會發生數據丟失,但在MySQL異常,主從切換等各種異常情況下,如果處理不當,有可能發生少量數據丟失,所以需要評估業務是否能接受,如果要求極高的可靠性,最好采用阿里的方案。
2.雙活方案:canal是單向同步的,而雙活要求雙向同步,那么采用canal的時候,就需要對數據變化進行時候,標識好那些是同步的數據,那些的變化的數據,要不然就容易發生同步的回路,導致死循環。
二、Redis的數據同步
阿里對Redis的內核做了改造,支持進行數據的同步,當時當前只支持全部的同步,所以當雙活環境對同一個key進行操作的時候,則有可能發生問題,需要業務上需要對這個進行改造。
三、ES的數據同步
阿里當前沒有支持ES的數據同步,所以只能自己實現,一般情況下,ES的寫入有兩種方式:
1.直接在代碼里面實現,將數據寫入ES
2.先將數據寫入MySQL,然后再將MySQL的數據同步到ES
針對第一種方式,有一種可行的實現方式,就是將數據寫入ES之后,將數據也寫入一份到Kafka,然后災備中心通過訂閱Kafka,將數據寫入到災備的ES。這里還有個雙活,因為災備中心的服務采用的是同一套代碼,那么災備中心往主中心同步的邏輯也是一樣。但這里有個問題,由于是同一套代碼,所有最后是往Kafka的同一個Topic寫數據,那么如何區分呢?下面有幾個解決思路:
1.業務邏輯進行處理,不同的中心自動寫入到不同的Topic
2.Topic通過配置實現,不同的中心配置不同的Topic
3.寫入的數據增加標識,可以識別對應的中心。Kafka消費者在接收到消息后,丟棄不需要處理的數據
上面三種方案,推薦使用第一種。
針對ES寫入的第二種方式,目前通常有兩種實現方式:
1.通過Flume、Sqoop、Spark等工具,將數據從MySQL讀取出來,然后寫入到ES
2.通過canal,解析MySQL的binlog文件,然后寫入數據到kafka,然后再寫入到ES
第一種方案更加偏重于定時的數據同步,很多公司都是在凌晨執行進行數據的同步,由于該方案會對MySQL造成壓力,如果MySQL做了kill的配置,很可能由于執行時間過長會被MySQL kill掉,造成數據丟失。
第二種方案是實時同步的方案,處理不當,在發生異常的情況下,有可能會出現少量的數據丟失。如果只是需要凌晨同步,推薦用第一種方案,如果是對實時性要求比較高,推薦用第二種方案。由于這兩張方案通常都是寫入到kafka,那么我們可以通過訂閱kafka,實現同時往災備中心寫數據。由于ES的集群方式,理論上還有另外一種方式,那就是一個ES集群,同時配置主中心和災備中心的節點,當發生災備時,理論上還有一半的節點可以使用。這個方案存在一個重大的缺陷,那就是災備中心往往跟主中心距離遙遠,比如說,主中心的南方,備中心在備份,如果一個ES集群同時包含不同地域的節點,那么這個時延可能無法接受,由于ES需要在不同的節點和分片上面進行數據的傳輸和備份,少量時延都可能對ES的性能造成大的影響,這對業務的感知就很差,所以不推薦該方式。 
四、全局ID(自增ID)的設計
業務上面需要用到各種各樣的唯一主鍵,在以前只有一個MySQL數據庫的時代,全局ID往往是采用MySQL的自增ID來實現的,但隨著規模的擴大,MySQL出現分表分庫,并發量往往也在加大,MySQL的自增ID往往無法支撐性能,比較通常的的采用Redis來實現全局ID功能。在雙活或者災備環境下,Redis全局ID和MySQL自增ID都存在問題,因為主環境和災備環境是隔離的,雙方產生的ID的可能存在重復。解決的思路就是采用主環境和災備環境分別生成不一樣的ID,比如說,主環境產生單數的ID,災備環境產生雙數的ID,這樣就保證兩邊產生的ID不重復了。但這樣就有另外一個問題,那就是有可能一個ID比較少的數據,產生的時間點卻是比較晚的,在這種情況下,在災備切換前,可以把災備環境的ID刷新到最新的ID值,這樣產生的數據就基本上是順序的了。
五、定時任務的處理
正常的業務,后臺都有各種定時任務,定時任務的類型主要有統計類(每天凌晨對數據進行統計)、遷移類(比如說每天凌晨,將數據遷移到歷史表)和監控類(比如說看門狗,用來監控系統是否正常)。針對1和2兩種類型,其實都可以認為是對MySQL的數據進行操作,而由于災備會進行數據同步,如果備份中心也進行MySQL的數據處理,那么就會導致數據被重復處理,或者產生重復數據,所以備份中心的統計類和監控類定時任務不需要開啟,只在主中心啟動就行。針對監控類定時任務,則災備中心同時也需要啟動。
六、公共數據的處理
假設雙活的環境,業務不是完全隔離的話,那么就涉及到公共數據了,包括客戶、權限、部門、系統參數等。正常情況下,跟客戶和客戶所屬地域相關的配置,是不會出現不同中心修改同一條記錄的情況,那么也就不會出現寫沖突了。但是少量公共配置,比如說系統參數,還是可能出現寫沖突。比較穩妥的方式還是對這部分公共配置增加中心的配置,也就是不同有不同的配置,這樣就不會出現寫沖突了。
七、消息隊列的處理
在微服務架構體系里,往往使用了RabbitMQ、Kafka等消息隊列,通常的做法就是微服務在接受到請求并處理后,將下一步處理作為消息發送到消息隊列,消息隊列的消費者接收到消息后進行后續處理。正常情況下,在雙活系統里,主中心和災備中心的消息隊列分別處理各自地域的數據,互不干擾。但是當消息隊列處理的是公共數據的變化的,就可能有些問題了。比如說,消息隊列是監聽DB的變化,然后進行后續處理,那么災備中心的服務應該停了,只由一個處理就可以。
八、告警監控的處理
正常情況下,告警監控主要包括以下內容:主機告警監控、應用告警監控、日志分析和告警、業務告警、日常巡檢、中間件告警。其中,應用告警主要是指java、php、go、c等服務,通?;峒囁賾τ枚雜Φ腃PU、IO、緩存,吞吐量、慢事務、GC時間、緩存等。日志分析和告警主要是收集業務采集的日志,然后進行分析,通常使用ELK、GrayLog等,監控主要有異常日志,業務操作日志、請求日志等。業務告警主要是指業務專門寫的測試代碼,主要有業務撥測,自動化單元測試,自動化集成測試等。日常巡檢通常就是運維人員每天,每周,每月執行的巡檢操作,一般包括自動和手工。中間件告警包括MySQL、RabbitMQ、Kafka、Redis、MongoDB等。雙活情況下,上面告警監控都要能正常處理。

上一篇文章:關于大型網站技術——存儲的瓶頸 下一篇文章:幾種排序、查找算法的cpp實現
相關鏈接
發表評論
用戶評論
版權所有 山西科達自控股份有限公司 晉ICP備09004627號    晉公網安備 14019202000008號     
官方微信
胜负彩17059期投注策略
新浪官方微博
騰訊官方微博
21点手机游戏 黑马人工计划软件手机版 时时彩六码层进倍投 重庆时时彩漏洞在哪 七乐彩下载 后二倍投方案 大乐游戏mg游戏pt游戏sw游戏 pk10赛车计划走势技巧 3d历史上的今天开奖结果走势图 网赌AG百家了作弊 够力七星彩 pk106码倍投金额技巧表 重庆时时开彩龙虎和 双色球为什么延迟开奖 11选5六码组合一共多少组 河北时时现场开奖结果查询