mysql Android 云计算 Windows linux 开源 php centos 微软 java nginx shell 编程 Firefox wordpress apache google 程序员 Python Ubuntu

阿裏雲數據庫,破解大型網站架構設計中的數據存儲難題

摘要:3月10日,2017阿裏雲網站行業熱點問題和解決方案線下研討會在上海舉行。在本次研討會上,阿裏雲數據庫團隊產品專家王義成(花名摯尤)針對於大型網站的數據庫架構設計以及阿裏雲ApsaraDB所提供的服務管理和解決方案進行了深入介紹。

分享者簡介:王義成(花名摯尤),阿裏雲數據庫團隊產品專家,負責阿裏雲NoSQL數據庫的產品規劃。加入阿裏巴巴近5年的時間,參與過多種雲數據庫的產品設計工作。目前主要負責阿裏雲的MongoDB、Redis以及MemCache產品,旨在為廣大客戶提供安全可靠的數據庫解決方案。

以下內容根據演講視頻以及PPT整理而成。

最近一年整個數據庫行業可以說是風生水起,同時也發生了包括MongoDB黑天事件以及最近的GitLab刪庫誤操作事件在內的很多事件,這些事件導致了各自的業務都遭受了巨大損失。而很有意思的一件事情就是在MongoDB黑天事件發生之後,使用阿裏雲MongoDB服務的實例數開始出現暴漲,這其實是因為大家都抱著亡羊補牢的心態,開始使用雲數據庫。

今天就為通過以下四個主題為大家簡單剖析為什麽做大型網站需要使用雲數據庫:
一、通用數據庫架構
二、ApsaraDB.概要介紹
三、ApsaraDB.服務管理
四、ApsaraDB.解決方案

本次分享中首先會介紹大多數互聯網行業的數據庫通用架構設計、自建數據庫的一些常見問題以及面對的困難,之後將介紹ApsaraDB基於什麽樣的考量為用戶設計出了什麽樣的產品以及ApsaraDB所提供的服務管理能力,最後還將介紹ApsaraDB為阿裏雲整體提供了什麽樣的數據庫解決方案。

一、通用數據庫架構

1.電商高並發,高性能場景
在第一部分將介紹互聯網企業中常用的五個場景。第一個場景就是電商高並發,高性能場景。在電商高並發的場景下,很多架構采用了mysql,也有一些架構采用了PostgreSQL,並且目前大量的電商行業也開始使用MongoDB數據庫。而且對於新興的電商企業而言,由於數據相對比較靈活,所以基本上都會選擇使用MongoDB構建線上應用,還有一部分電商使用Redis做持久化存儲,將用戶信息類的數據直接使用Redis存儲到數據庫中。

821c7ae7a57a2383f7460663317776c5e0b13962

這類場景對於數據庫的要求關鍵字就是高性能和數據安全。那麽如何保證數據庫具有較高的性能並且保障數據安全,並且電商的核心交易往往存儲在MySQL數據庫中,該如何從網絡層面來保護數據安全,又如何防止SQL註入,這些問題都是應用DBA或者開發同學需要考慮的事情。如果使用自建的數據庫時就需要考慮應該采用什麽樣的手段來保障數據庫的高性能和安全,應該采用一主多從策略還是采用水平分區策略,這些問題都需要進行考慮。

2.金融:安全交易類場景

d14465e0486b84cf9d5ca52dd39b88518d0991d1

第二個場景就是安全交易金融類的場景。在金融類場景下,數據庫往往需要支持海量的數據存儲,可以從上圖中看到,可以結合前面的分布式Proxy和後面MySQL以及MongoDB數據庫實現分布式數據庫的架構。目前MySQL和MongoDB數據庫是可以實現分布式數據庫設計的,包括阿裏雲的DRDS以及開源的TADL等都可以用於構建自己的數據庫系統。而在自建數據庫時就需要去考量如何進行數據庫的橫向擴展以及如何保證分布式數據庫能夠平穩地運行,並且保證網絡安全和數據安全。除此之外,金融類場景中的一個核心要求就是保證業務高度可靠,當單節點無法滿足需求時需要使用雙機熱備,而當使用雙機熱備的時候如何保證在主機宕機的情況下備機不會丟失數據、某一個機房掛掉之後業務能夠瞬間恢復、緩存數據宕掉之後能夠避免對於後臺整體業務的沖擊過大以及在緩存宕掉之後能夠迅速地拉起等問題,都是在自建數據庫時需要仔細考慮的,而這些也正是處理中的難點。


3.網站:高性價比場景

0978ff25abe23001fc4488022aebf16f5719969f

第三類場景針對的是比較通用的網站類,也就是要求高性價比的場景。在這個場景下的數據存儲可能會使用到緩存層以及後臺的數據庫層,數據庫可能會使用MySQL、PG或者MongoDB,在緩存部分可能會使用到Redis或MemCache。這個場景下對於緩存的要求就是成本足夠低並且性能足夠高,這些也是在自建數據庫時需要保證的,而對於後臺存儲數據庫而言,則要求具有較高的性價比。因此如果使用一主一備的策略可能無法滿足高性價比的需求,所以需要使用讀寫分離以及一主多從的策略。雖然MySQL、PG以及MongoDB都提供了原生的一主多從的策略模式,但是如何處理這樣的模式以及讀寫分離策略,都是需要應用程序開發人員以及DBA進行聯合考量的,所以在自建數據庫時就將會耗費大量的人力、物力和財力。

4.遊戲:行業高可用場景

76fd688ccaa79668d4286adfb65edd6a4144f18f

第四類場景是遊戲類通用的數據庫場景,該場景的核心特點就是ECS和數據庫具有分服的概念,也就是在遊戲中會分出多個區。所以對於遊戲數據庫而言,需要保證其高穩定並且防止對於數據的誤操作。對於一些遊戲產品而言,往往發展非常迅速,可能一到兩周就會更新一個版本,如果開發和測試不完善就可能因為誤操作導致數據錯誤。那麽DBA如何保證在發生誤操作時,能夠瞬間恢復到誤操作發生之前的時間節點的數據狀態,這也是整體維護上的難點。而且在遊戲行業往往需要秒開數據庫,可能一天開多個區,會有大量用戶進來,那麽如何保證整體的前端服務、CDN以及底層的數據庫在一兩分鐘之內就能夠將業務全部開啟,這也是對於數據庫的一個考驗。

5.通用:大數據分析

ecc4e2e4de0b4cb0d398637aad8b55978ad32f74

第五個場景是大數據分析場景,在這個場景下的底層可能是一個Hadoop集群在晚上換算各種數據,白天就能夠將數據展示給老板看。比如整個網站的交易量數據都需要經過一夜的運算存儲到前端的MySQL或者Redis數據庫中,快速方便地供業務內部人員審核。在這個場景下,對於數據庫要求就是需要一個能夠將Hadoop中的數據一鍵式地導入到MySQL中的工具,還需要增加易用性,使得各個業務方都能夠方便地查看數據,並且需要低成本地應用MySQL和MongoDB數據庫來滿足內部查詢需求。所以在大數據分析場景下數據庫的關鍵詞就是易用,需要數據庫服務能夠提供數據通道,保證在異構的數據引擎之間進行數據快速傳輸,並滿足數據庫層面的低成本訴求。

以上就是互聯網應用中的五種通用的數據庫架構,總結而言自建數據庫的難點就在於以下四個方面:

958edc75266ac5025f8d7daa0b6eb4ab3e428b8d

1.穩定性,首先就是宕機怎麽辦?如果搭建了一主一備的數據庫策略,就需要保證主機宕機之後服務能夠快速恢復起來,並且機房宕機之後也要保證服務能夠快速起來。如果發生了地域的災難性事件之後需要能夠在一天或者幾個小時之內迅速恢復服務,而如果數據量非常大時就難以保證數據庫服務能夠在一天之內恢復,這些都是自建數據庫的難點。另外如果數據丟失了怎麽辦?可能業務是正常的,但是被黑客黑掉了,發生了像MongoDB黑天這樣的事件或者被SQL註入攻擊了,在這樣的情況下業務如何才能快速地恢復起來,還有白名單策略是否足夠好,以及在SQL註入將數據刪除之後是否能夠迅速恢復SQL註入之前的數據庫狀態,並且判斷出是誰對發起的SQL註入或者攻擊,這些都是在自建數據庫時需要考慮的難點。除此之外,還需要保證發生誤操作時數據庫的穩定性,雖然MySQL有比較合理的權限管理機制,但是像新興的MongoDB以及Redis等數據庫對於權限管理的處理還是比較粗放的,而在權限管理不合理的情況下,如果觸發了誤操作將可能修改了整個數據庫,此時DBA如何才能夠快速地將數據恢復以及恢復後會丟失多少數據都是需要考量的難點。

2.擴展性,當業務快速發展的時候,數據庫如何縱向地升級也需要在自建數據庫時考慮。大家在ECS上可以自由調配資源,如果沒有使用雲服務而是使用的自建機房,當進行活動宣傳時可能出現平時業務的十倍增長量,這使得數據庫的壓力也會急劇增加,縱向的數據庫如何調度也將會成為難點。對於自建機房而言,服務器的采購周期也會很漫長,而搭建在ECS上就能夠解決這個問題。但還存在一個問題就是數據庫的縱向升級也是存在瓶頸的,即便是ECS也是有固定的配置,當單個ECS已經無法承擔業務壓力的時候,數據庫又應該如何橫向升級也需要在自建數據庫時考慮。舉個簡單的例子,大家都知道Redis是單線程的,ECS配置再高也只能增加內存的數量,QPS的極限也就是十萬,當業務迅速上來,縱向升級已經達到極限的時候,如何將Redis直接橫向擴展為集群的實例,以及擴展成為集群之後如何進行維護,這些也都是DBA需要面對的巨大挑戰。除此之外如何實現異構數據庫之間的數據互通,如何將MySQL中的數據定向地導入到MongoDB或者Hadoop中,或者將Hadoop中的數據導入到MySQL中,這些都是需要耗費很多開發力量並且需要很多DBA的運維工作的。

3.安全性,如果能夠預防SQL註入以及網絡攻擊,如何在遭受攻擊的時候終止攻擊,也就是在判斷出這是一個SQL註入時,如何將其進行攔截也是在自建數據庫時需要考慮的。還有如何亡羊補牢,在遭受攻擊被脫庫或者刪庫之後,在最短的時間內將數據找回並且將業務恢復起來,對於DBA而言也是難點。另外就是在遭受攻擊之後,需要追查出攻擊者到底是內鬼還是外部黑客,如果在管理比較混亂時,查出數據庫是如何被刪掉的以及到底是誰攻擊的,都是自建數據庫的難點所在。

4.優化和人力,SQL慢了該如何進行優化,在前期數據庫管理時如果優化了數據庫的性能就能夠提升網站的整體性能。另外架構演練如何進行升級,比如從原本的只有MySQL的數據庫架構演化成為前端+緩存並且使用更加合理的數據庫的架構,這些都是優化中的難點。

其實除此之外,關系型數據庫的DBA還是容易招募到的,但是招NoSQL領域的DBA還是相對比較困難的。那麽在整體運維層面比較困難的情況下,如何最大地發揮數據庫的價值就是阿裏雲推出的數據庫服務的目標。圍繞著在自建數據庫中遇到的難點,就能夠襯托出阿裏雲數據庫產品的使命。

二、ApsaraDB.概要介紹
之前分享了在自建數據庫中遇到的難點和需要解決的問題,接下來介紹一下阿裏雲的ApsaraDB數據庫在做什麽以及能夠幫助用戶解決什麽樣的問題。

飛天技術棧
下圖是阿裏雲的飛天技術棧。最下層是阿裏雲的數據中心,其上層是阿裏雲的操作系統和文件系統,再上一層就是服務部署和資源調度,再上面一層就是任務系統、安全管理以及集群監控。在飛天技術棧最上面的這一層就是用戶可見的雲服務,這一層大致分為了七大板塊:計算、存儲、網絡、數據庫、內容分發、大數據以及中間件。目前阿裏雲數據庫團隊的產品有關系型數據庫RDS、包括Redis、MongoDB、MemCached在內的NoSQL類的數據庫以及金融類的數據庫OceanBase、針對大數據的EMR和Greenplum以及自研集成了OLTP以及OLAP的數據庫PetaData。

fd0a7a08d634832204c2ac1a435076561544f5d3


阿裏雲數據庫-ApsaraDB產品家族
下圖是阿裏雲數據庫團隊目前支持的幾款產品,開源類的產品包括MySQL、PostgreSQL、MongoDB、Redis、MemCached、Greenplum以及Hadoop。而在商業化數據庫體系裏則支持SQL Server的2008和2012兩個版本,以及PostgreSQL的高級版,可以兼容95%的Oracle協議的PPAS,其可以作為Oracle用戶上雲的臨時替代方案,另外對於Oracle這部分,存在ApsaraDB的合作夥伴能夠幫助用戶去維護和構建雲上Oracle,另外還有HAVA,也就是ApsaraDB的合作夥伴SAP上線的HANA1,在未來不久就可以在阿裏雲上售賣HANA的版本。

d34b96fd772ff66f666e384b4228ba2b1536407d

 

流量组件

下图是阿里云上的几个大的流量组件。

25e9707a3c34b57621a46ea86d25ea3752acad32

1.VPC+SLB,在安全性上,阿裏雲提供VPC + SLB的模式,這其中的SLB是購買RDS服務或者Redis、MongoDB自帶,這個SLB其實是內部直接包在RDS中的,其主要幫助做四層的負載均衡。VPC的虛擬路由器和虛擬交換機保證在公有雲之上該網絡只有自己的專有網絡內的用戶能夠連接,保障與其他網絡用戶的天然隔離,並且在整個數據庫層面之前會綁定一層針對DDOS攻擊的防禦措施。

2.Proxy,Proxy也是阿裏雲數據庫團隊自研的組件,其主要作用是幫助用戶實現七層的負載均衡。像分布式事務和讀寫分離這些都是在應用場景中幫助用戶解決性價比問題的,當一個請求過來之後,可以直接通過Proxy判斷該請求是讀還是寫,並根據策略分發到讀或者寫節點,不需要應用程序再進行解析和判斷。SQL解析一方面就是將請求分析出來並且分配到相應的讀或者寫節點,另外就是及時地終止攻擊,這個層面的SQL解析還處於研發階段,未來希望通過SQL解析來判斷請求中的語句是否存在SQL註入的嫌疑,如果用戶選擇讓阿裏雲幫助進行判斷,如果發現的確是SQL註入就會在應用程序上直接進行攔截,避免對於數據庫造成災難性的損失。還有一點就是連接保持,比如想要對於MySQL進行內核修復時,升級版本對於前端而言是非常痛苦的,應用程序就需要全部重連。而在主備進行切換或者主數據庫進行內核升級的時候,如何保證業務不受影響,都需要依靠Proxy幫助進行連接的保持,而這則會免去對於運維幹擾。

3.DB Engine,這裏有多種數據復制方式保證RPO和RTO在相應的結合模式上進行處理,當對於數據可靠性要求比較高時,可能會選擇雙節點+半同步的模式;而當對RPO要求比較高時可能會選用異步復制的模式,這樣就可以通過DB Engine來適配多種數據復制模式來解決不同用戶的需求。另外DB Engine提供了插件式引擎,阿裏雲數據庫團隊提供了大的中臺來支撐用戶的服務能力,目前也已經實現了插件式引擎方式,比如在新建數據庫時只需要一兩個月的時間就可以實現產品的公測和商業化,能夠快速地滿足用戶對於數據庫的需求。除此之外還提供了源碼級定制,數據庫團隊在開源領域吸收了中國頂尖的內核級開發人員來維護源碼級的版本,目前使用的MySQL版本也都是去年開源的AliSQL的版本,其相比於原生MySQL內核性能提升了70%,而像MongoDB和Redis也都能夠從內核層面幫助用戶解決性能問題。

4.HA,用戶使用數據庫一個核心的需求就是穩定,而穩定性需要強大的HA系統來支撐。阿裏雲數據庫團隊的HA能夠幫助用戶進行健康檢查、流量切換以及SLA計算。原生的流量切換只會檢測程序的安全性,當內存hang住或者IO出現問題時,原生無法切換過來,而阿裏雲的HA策略是嘗試真實地寫磁盤IO,保證在受到影響之後HA都可以切換過來。

流量路徑
下圖是數據庫架構的流量路徑,這裏介紹了用戶購買阿裏雲數據庫服務之後的數據流向。下圖存在雙節點,其實雙節點的設計也會存在問題,比如某一機房斷電或者網絡出現故障,數據中心也就會癱瘓了,而阿裏雲的MySQL和Redis都提供了跨可用區的復制,也就是數據庫實例存在多個可用區,當一個可用區出現故障之後可以直接將流量切換到備用機房,保障業務不受影響。下圖展現的大致流程就是流量到來之後,數據將通過Proxy路由到DB Engine層,DB Engine層通過阿裏雲內網專線將數據復制到遠端的跨可用區的數據庫節點上,也就是如下圖所示的左邊是主節點,右邊是備用節點,只不過備用節點平時不會承擔流量,數據正常進行復制。如果發現主節點宕機之後就可以直接將流量全部一鍵切換到備用節點上,免除了用戶自己維護穩定性的困難,也同時保障了服務的高可用。

fc7e1522f5ea9c9ee4e249d62ad5e148d9fd140a


連接優化
下圖展現的則是Proxy的連接保持優勢,其實在數據庫層面往往需要兩個節點,對於大型的雲服務而言,某一臺主機壞掉是很正常的情況,那麽在宕機或者在數據庫內核更新時如何才能不影響用戶業務,其實背後都是依靠Proxy體系支撐的。內部的SLB直接連到為用戶提供的Proxy上,Proxy連接DB Engine,當主機需要升級或者宕機的時候,可以把主機的鏈接斷掉,直接將Proxy連接到備用節點,而在恢復時連接其實並沒有斷掉,在切換時可能會有一兩秒的卡頓,但是對於卻免去了業務重連的處理。總之,整個雲服務就可以依靠Proxy實現連接保持。

a06c10eba17804fe7d82b3f4389e404f565657b5


复制方式
目前阿里云数据库服务一共提供了以下四种复制方式:

084ea7b55c7531e12174bc2bc1f524a3c17cff3c

  • RPO + RTO模式,該模式實現了瞬間恢復以及恢復後能夠找到時間點,在默認的雙節點情況下進行半同步復制,也就是數據必須要到達備端之後才能返回,所以當主節點宕機之後,備節點能夠快速地運行起來,但是這樣性能就會有相應的損耗,因為需要將數據傳輸到備端,如果選用了雙可用區本身還會有3到5毫秒的延遲。
    RTO + Performance模式,這個模式下能夠保證在數據宕機之後能夠快速起來,這對於RTO不是很高的要求,可能起來之後數據會丟失一些,但是要求性能足夠高,這種模式使用雙節點 + 異步復制。
    RPO + Performance模式,這種模式下數據宕掉之後可能恢復時間會長一些,可能需要1到5分鐘,但其RPO是沒有問題的,其底層使用了共享存儲並且性能足夠高,並且使用的是單節點。
    RPO + RTO + Performance模式,它使用了多節點、強同步復制以及最終一致性,目前MongoDB的三節點都是復用的這種模式。

    三、ApsaraDB.服務管理
    之前概要性地介紹了ApsaraDB,接下來從服務管理層面為大家介紹與自建數據庫相比,ApsaraDB的優勢所在。

 

1347e029598f55c69422a47415f33b17a9594152

首先,對於服務可用性而言,阿裏雲的數據庫提供主備架構、同城容災和異地容災模式,可以在半天之內將流量切換到備節點,並且不影響業務,還支持直接在控制臺上點擊主備切換來演習故障發生時的情況。如果自建數據庫,則需要在自己的ECS上去考慮如何處理服務可用性以及在宕機時如何進行切流量的問題。

對於數據可靠性而言,阿裏雲提供的數據庫通過本地RAID5實現了在線存儲冗余,而ECS采用的是高效雲盤 + SSD雲盤,所以在本地存儲方面兩種方案是差不多的。在離線長效備份方面,阿裏雲ApsaraDB支持一鍵式將文件存儲到OSS上並且可以存儲延長至兩年,而ECS自建數據庫時則需要自己寫OSS腳本來上傳數據。第三方面就是按時間點恢復,就是當出現開發的誤操作或者刪除了一個表格之後,需要將數據恢復到誤操作前一秒的狀態,其實ApsaraDB支持將增量日誌和AOF日誌等全部存儲到OSS上。在控制臺發起操作之後,後臺就會將備份文件以及增量日誌在一個新的時序上恢復起來,數據就能夠直接回滾回來。在數據復制方面,ApsaraDB支持異步 + 半復制的方式,則使用ECS自建數據庫則需要自己進行配置。

在數據安全性部分,目前ApsaraDB支持白名單分組,而ECS則是支持安全組,在未來四、五月份的時候數據庫團隊就會將白名單分組取消,並將其和ECS安全組融合起來,解決目前客戶在使用時的體驗較差的問題。在審計日誌方面,ApsaraDB會依靠內部的系統將SQL的審計日誌收集起來並且存儲到遠端的存儲中,用戶可以定期地將SQL審計日誌拉到本地進行查看,而且這個系統對於整體的性能損耗並不大,但是可以實現有蹤可查,當發生問題的時候,就可以知道到底是誰發動了攻擊,以及時間點、所使用的ip以及進行的操作。在網絡加密和存儲加密方面,阿裏雲數據庫也處於比較領先的位置,ApsaraDB經過數據庫的的等級認證,目前已經支持了SSL網絡加密以及TDE存儲加密。如果選擇了TDE存儲加密,即使數據被拖走對方在沒有密匙的情況下也無法解析自己的數據,這部分在金融行業裏也是要求非常嚴格的。

在監控與報警部分,阿裏雲數據庫支持資源類的監控,也就是對於實例的CPU、內存、磁盤等的資源進行監控,還有就是引擎層面的監控,對於MySQL、Redis以及MongoDB等引擎層面的監控。在數據庫引擎層面存在很多可以監控的指標,這些都可以通過圖形化的方式展現給用戶。在秒級監控部分,ApsaraDB支持300s和60s的監控模式,後續還可能對於像緩存等業務實現更細的粒度。並且ApsaraDB支持雲監控的報警,對於數據庫的監控指標而言,當發現這些指標出現異常時可以通過雲監控直接向運維人員的手機或者郵箱發送報警信息。

在參數管理部分,ApsaraDB可以在數據庫運維層面為用戶提供參數模板和修改歷史以及開銷的分析。

在性能優化部分,阿裏雲數據庫會為用戶提供一套系統來幫助用戶審查所有的SQL日誌,並對於日誌進行相應的去重分析來判斷對於SQL應該加什麽樣的索引以及對於某張表應該如何處理給出相應的建議。

而一站式服務就是對於阿裏雲數據庫整體的生態提供的工具。阿裏雲數據庫提供了數據管理的工具,大家使用MySQL可能知道有Navicat等,在ECS上自建數據庫時可以裝上這樣的工具,但是對於像MongoDB以及Redis這樣的數據庫,可視化的數據庫管理工具卻是很少的,現在的DMS可視化操作工具已經和阿裏雲數據庫完全結合,可以支持SQLServer、PG、MySQL、MemCache、Redis以及MongoDB等所有的引擎,購買了阿裏雲的這些數據庫之後就可以直接以圖形化的方式進行管理了。而對於數據同步方面,對於如何輕松地將Hadoop中的數據同步到MongoDB中,或者對於兩個同構的數據庫如何進行數據同步以及如何實現增量同步的同時不影響業務而言,阿裏雲的整個數據同步工具是非常健全的,首先對於雲上雲下的同構的數據庫同步來說,阿裏雲數據庫都是支持全量 + 增量的,比如用戶在ECS上有MySQL和MongoDB數據庫,就可以直接選擇DPS實現全量和增量的數據同步,目前對於異構數據庫而言也是支持Oracle到PPAS的。數據同步這部分也是在迅速地發展,後續也會加更多的引擎進來,將會實現更多的數據庫的異構同步來打通數據庫的整體生態。

數據安全
下圖展現了阿裏雲數據庫可以從幾個維度幫助用戶構建事前、事中和事後的安全防範措施。在事前阿裏雲數據庫會使用VPC專有網絡形成隔離的網絡環境,另外還會要求用戶設置精細粒度的白名單,而且所有的數據庫都是要求強密碼認證的。在比如像MongoDB的黑天事件中,其實根源在於用戶將自己的MongoDB的IP地址暴露於公網之上,直接導致黑客有了入侵的機會,所以阿裏雲對於NoSQL的數據庫都需要強制用戶設置強密碼,並且不會暴露公網IP供外網調用,保證數據庫處於一個相對比較安全的網絡環境內。在事中還會使用SSL的網絡加密以及TDE的數據加密。在事後的防範中還使用了一整套詳細的審計日誌,當真正發生了問題之後可以將審計日誌調出來查看誰在什麽時間點對於數據庫進行了什麽操作。除此之外,最後還有一套克隆實例保證數據庫能夠實現數據秒級恢復。

9bfc1ffb3658e12dbd6ea4786a3f0e0a83366755


監控報警
下圖介紹的是阿裏雲數據庫的監控報警能力,目前阿裏雲RDS正在打造一套整體中臺,也就是內部的“天象”的指揮端的系統,這個系統能夠幫助用戶將流量從ECS上直接打通到RDS上去的所有網絡延遲監控下來並展現給用戶,使得用戶能夠了解RDS或者MongoDB在一定時間內的壓力負載究竟在哪,知道QPS反應比較慢的時候究竟卡在哪個鏈路上,到底是ECS出網口的問題、ECS到RDS鏈路的問題還是RDS引擎層面的問題,這些都會通過鏈路的監控圖展示給用戶。

c8deb5b3f21da730fb7bb5a170d65c767d417a24


性能优化
对于阿里云数据库的性能优化部分,可以分为如下图所示的资源分析、引擎分析、SQL分析以及专家系统这四大部分。

596abd8d5a21e5999596d01ee74b1125b17f34e6


四、ApsaraDB.解决方案

异地容灾解决方案

d621b44907656ef2eaff89dd7635f31184515fb6

第一個是在雲上實現異地容災的解決方案,比如在金融行業會需要考慮的一個可用區出現問題的場景下衍生出的服務就是異地容災,可能數據庫的主可用區在上海,而備可用區在深圳,當上海這個主可用區出現兩個機房都癱瘓或者城市發生了電力故障不能提供服務的時候,都可以通過一定容災模式保證服務的。而異地容災的架構是需要所有的阿裏雲產品進行配合的,但其中最難做並且最重要的還是數據庫。其實沒有數據的部分是很好做容災的,但是一旦涉及到數據就會很難實現。如上圖中的解決方案所示,其支持的是兩地四中心的概念,兩個節點在不同的可用區之內,兩個節點之間通過原生復制的方式實現數據同步,而自己搭建數據庫時異地復制就會出現困難,如何保證數據能夠追上並且RPO和PTO處於合理範圍之內都是難點。

混合雲解決方案

dbf567fe483cdd678811c3631767888aa6355ce1

對於混合雲的解決方案而言,其實實現混合雲架構的難點還是在數據庫,只要在有數據的地方實現多中心的同步都會比較困難。如上圖的架構中左邊所示就是如何將雲下機房和雲上機房進行數據互通和同步,而右邊則是如何將阿裏雲上的數據同步到雲下,這個場景都是真實存在於很多的金融場景中的,金融行業可能以雲上作為備份、雲下為主,還有一些新興的金融行業因為其業務是依靠雲發展起來的,而又因為需要合規所以需要將數據備份到雲下,所以采用了雲上做主、雲下做備的方式。這套混合雲解決方案還是依賴於整體的同步機制,雲下到雲上的的同步可以直接拽一個backup上去存儲到對端之後,再通過增量數據將兩部分數據一直掛同步和同載實現雲上和雲下的同步。而雲上到雲下的同步就是會將MySQL的Binlog或者MongoDB的OPlog直接開放權限給DTS服務,將數據通過通道傳輸到遠端的自建數據庫中,從而完成混合雲的架構。

快速部署解決方案

2f5fa88c7335ddc8ee53c9c5362e00d369f6feb7

上圖展現的是一個快速部署的場景。快速恢復的功能支持整體的克隆實例,可以基於備份文件將數據整體克隆出來,並進行快速部署。而Flashback功能是阿裏雲數據庫團隊的彭立勛開發的,目前已經整合到MariaDB版本中並成為了其中核心的功能,這個功能主要就是抓起Binlog文件。因為平時做數據恢復時需要保證一個全量的備份,而Flashback的開發直接將Binlog的數據收集到裏面,保證在很短的時間之內能夠將數據恢復出來。對於Flashback功能感興趣的同學可以到網上進行詳細了解。

實時計算解決方案

12abb2bc37d068cec4f23454a39b39e5355c711a

最後的場景展現的實時計算的解決方案,目前很多業務都要求LTP和LAP兩套機制。本身的一套數據庫系統可能是實現LTP的,也就是正常的增刪改查,還有一套系統需要將數據拉回來做LAP和分析,常規都是有一套LAP的數據庫每天定時將LTP的數據直接同步到LAP中,而這個同步也是非常痛苦的。實時計算的解決方案希望在一套架構中為用戶解決LAP和LTP的問題。阿裏雲的PetaData產品目前正處於邀測階段,預期會在三月底進行商業化,PetaData能夠通過一套存儲機制幫助用戶解決LAP和LTP的問題,大家有興趣可以關註一下。

延伸阅读

评论