更多相關(guān)文章閱讀
本文根據(jù) GOPS2017·上海站演講《餓了么異地雙活數(shù)據(jù)庫實(shí)戰(zhàn)》整理發(fā)布
作者簡介：
虢國飛，餓了么 DBA負(fù)責(zé)人
從事數(shù)據(jù)庫行業(yè)10+年，專注于MySQL、PgSQL、MSSQL等數(shù)據(jù)庫領(lǐng)域的管理、研究和平臺(tái)的研發(fā)等工作，目前負(fù)責(zé)餓了么數(shù)據(jù)庫團(tuán)隊(duì)的管理和數(shù)據(jù)庫維護(hù)方面的工作。
我今天分享是餓了么在數(shù)據(jù)庫和多活數(shù)據(jù)庫這塊的實(shí)戰(zhàn)經(jīng)歷，供大家參考。
主要分享以下五點(diǎn)：
1、多活當(dāng)中的難點(diǎn)
2、多活的架構(gòu)
3、數(shù)據(jù)庫改造
4、DBA 挑戰(zhàn)
5、收益與展望
我們先來看一下多活的第一個(gè)難點(diǎn)：要考慮做多活到底是同城的多活還是異地的多活，跨地域網(wǎng)絡(luò)延時(shí)是現(xiàn)階段很難突破的點(diǎn)，因?yàn)轲I了么面臨的是異地的多活，所以我們需要基于延時(shí)這個(gè)前提來考慮方案。
從北京到上海中間有30毫秒的延遲，這個(gè)會(huì)帶來什么問題？我們接下來會(huì)講。
上圖是同城和異地多活不同的點(diǎn)，復(fù)雜性和可拓展性對架構(gòu)的影響方面會(huì)有很大的不同。
我們挑幾個(gè)點(diǎn)講一下：
1、如果只是做同城多活的話，像30毫秒的延時(shí)不需要考慮，因?yàn)橥堑难訒r(shí)通常只有幾毫秒，跟同機(jī)房差不大。
2、如果是異地30毫秒的延時(shí)就需要重點(diǎn)考慮了，因?yàn)槿绻欠磸?fù)調(diào)用的應(yīng)用，放大的時(shí)間就不只是30毫秒了，可能是300毫秒、500毫秒，對很多應(yīng)用來說是不可接受的。
在可擴(kuò)展性方面如果做的是異地多活的話，你的可擴(kuò)展性理論上來說沒有太多的邊界。我們做同城多活只能在上海機(jī)房里面選，如果是異地多活，可能是全國甚至是全球都可以選。
還有一個(gè)比較難的問題，就是怎么保證數(shù)據(jù)的安全。多活數(shù)據(jù)可能面臨多個(gè)寫入點(diǎn)，可能會(huì)錯(cuò)亂、會(huì)沖突、循環(huán)復(fù)制、數(shù)據(jù)環(huán)路等問題，這種情況下怎么保障一致性。如果這些沒有考慮好之前，你是不能上多活方案的，多點(diǎn)寫入的風(fēng)險(xiǎn)對數(shù)據(jù)的考驗(yàn)是很大的。
綜合考慮下來我們選擇了異地多活，所以這些問題我們都需要克服，也意味著會(huì)面臨很多的改造。
如何解決跨機(jī)房延時(shí)對業(yè)務(wù)的影響，包括各種抖動(dòng)甚至是斷網(wǎng)的問題。怎樣有效區(qū)分我們訪問的流量，最大限度地保障用戶的訪問落在正確的機(jī)房，這個(gè)都是需要解決的難點(diǎn)。
我們采取了一些措施：
1、盡量把業(yè)務(wù)做成類聚的，讓一個(gè)用戶的訪問落在同一個(gè)地方。
2、不是所有的業(yè)務(wù)都有多活特性的，還可以有全局使用的業(yè)務(wù)（比方用戶數(shù)據(jù)），所以需要做業(yè)務(wù)類型劃分。
在服務(wù)劃分這一層怎么定義業(yè)務(wù)調(diào)用的邊界，還有我們基于什么對流量和用戶做劃分的呢，目前根據(jù)我們的業(yè)務(wù)特點(diǎn)使用的是地理圍欄（POI），用戶、商戶、騎手當(dāng)前所在的地理位置是我們?nèi)肟诹髁縿澐值囊罁?jù)。
再看看路由控制這一塊，除了入口流量這一層做了機(jī)房的劃分，還在內(nèi)部使用了虛擬的Shardingkey，ShardingKey會(huì)把全國流量分成多個(gè)部分，并且與POI標(biāo)簽綁定，這樣就可以把邏輯ShardingKey和物理位置對應(yīng)起來，切換的時(shí)候訪問就可以隨ShardingKey分流到不同的機(jī)房。APIRouter就是為了完成這個(gè)工作的，它會(huì)根據(jù)配置的規(guī)則把Shardingkey對應(yīng)的流量分到對應(yīng)的機(jī)房。
臟寫預(yù)防方面，為防止數(shù)據(jù)沖突，我們也需要業(yè)務(wù)配合做一些多活規(guī)則的改造，這些規(guī)則對業(yè)務(wù)還是有一些侵入性的。另外SOA-Route就是內(nèi)部跨業(yè)務(wù)調(diào)用的訪問路由。還有一個(gè)DAL，就是數(shù)據(jù)庫的代理層。
業(yè)務(wù)訪問在我們多層的路由控制下，理論上應(yīng)該能正確路由到合適的機(jī)房，如果超越規(guī)則或者沒有按規(guī)則改造的意外流量真正穿透到DAL這一層的時(shí)候我們是強(qiáng)制拒絕的，因?yàn)榈讓诱J(rèn)為這個(gè)訪問是屬于異常的調(diào)用，流量走錯(cuò)了機(jī)房，這時(shí)候就會(huì)拒絕。所以我們寧愿讓他失敗也不能讓控制之外的數(shù)據(jù)進(jìn)來，這樣才能保障規(guī)則和數(shù)據(jù)的可控性。
數(shù)據(jù)一致性方面我們有一個(gè)重要的DRC數(shù)據(jù)同步組件，數(shù)據(jù)庫這塊有一些自增的控制，DBA還研發(fā)了一個(gè)數(shù)據(jù)一致性校驗(yàn)的工具（后面會(huì)介紹）。
粗略過了多活的一些難點(diǎn)和我們的應(yīng)對方案后，我們現(xiàn)在來看一下整個(gè)多活的架構(gòu)。這個(gè)上面是我們從入口流量、分流控制、數(shù)據(jù)多機(jī)房同步，包括各個(gè)重要組件的架構(gòu)等。還有里面有g(shù)lobol zone這一項(xiàng)，它是我們剛剛講的需要全局依賴的業(yè)務(wù)會(huì)把它放在globol zone里面。
DRC這是做多活時(shí)相當(dāng)重要的組件，主要解決數(shù)據(jù)在多個(gè)機(jī)房當(dāng)中的同步復(fù)制。我們從北京機(jī)房寫入的數(shù)據(jù)，會(huì)同步到上海的機(jī)房。上海的機(jī)房寫入的數(shù)據(jù)也會(huì)通過DRC這個(gè)組件同步到北京的機(jī)房。大家可以看它其實(shí)包含三塊服務(wù)，Replicator、Applier和Manager，一個(gè)收集變更數(shù)據(jù)、一個(gè)將變更數(shù)據(jù)寫入到另一個(gè)機(jī)房，另外一個(gè)是做管理控制。
DB架構(gòu)這塊我們有兩類（準(zhǔn)確講還有一類是多推的，比較少），第一類是ShardingZone，不管是數(shù)據(jù)寫入還是訪問都是本機(jī)房提供，出問題的時(shí)候也只是流量的切換，并不涉及到底層的變動(dòng)，這個(gè)是真正多活的架構(gòu)。
還有一種是剛剛講的，有些沒有辦法做業(yè)務(wù)分區(qū)的，是globolZone的架構(gòu)，寫是集中在一個(gè)機(jī)房，讀在本地機(jī)房完成。大家可能會(huì)想到globalzone這種架構(gòu)會(huì)天然面臨一些剛剛講的數(shù)據(jù)延遲的問題，所以這塊我們的定義是一些寫入量不大，訪問量大，對數(shù)據(jù)延時(shí)是不那么敏感的業(yè)務(wù)就可以放到這里面來。
多活項(xiàng)目我們調(diào)研大概花的時(shí)間有半年左右，但真正做改造的時(shí)候時(shí)間是相當(dāng)短的。從啟動(dòng)這個(gè)項(xiàng)目到真正上線就用了三個(gè)月左右的時(shí)間。那時(shí)候時(shí)間是相當(dāng)緊的，大家可以看一下我列舉大的為配合多活數(shù)據(jù)庫所做的改造項(xiàng)目。
首先面臨的問題，就是我們要把數(shù)據(jù)全量的從一個(gè)機(jī)房導(dǎo)入到另外一個(gè)機(jī)房，這個(gè)不光有測試環(huán)境還有生產(chǎn)環(huán)境都要全量的同步。我們數(shù)據(jù)有幾百T數(shù)據(jù)，幾百套集群，有各種主從結(jié)構(gòu)需要搭建需要去搭起來，每個(gè)節(jié)點(diǎn)時(shí)間也很短。
我們剛剛講的DRC會(huì)做數(shù)據(jù)的同步，但同步的時(shí)候也會(huì)面臨數(shù)據(jù)沖突的問題，為解決這個(gè)問題我們需要在所有表上增加一個(gè)DRC時(shí)間戳字段，用來判斷哪一邊數(shù)據(jù)是最新的，這樣在數(shù)據(jù)發(fā)生沖突的時(shí)候，我們會(huì)選最新的數(shù)據(jù)作為最終的數(shù)據(jù)。
為防止多活主鍵沖突，數(shù)據(jù)庫做了一些自增的調(diào)整，自增步長放大后馬上就會(huì)面臨數(shù)據(jù)溢出的問題，所以我們需要把主鍵都從int調(diào)整為bigint。主鍵改完以后還有一些外鍵依賴的也會(huì)需要改造，所以整體會(huì)要做很多的DDL（幾乎是全量表），而在MySQL里面DDL其實(shí)是風(fēng)險(xiǎn)比較高的操作。
第二個(gè)大改造是因?yàn)閰^(qū)分了不同的業(yè)務(wù)類型（我們剛剛講了有g(shù)oloblZone這些），就會(huì)面臨各種不同類型的業(yè)務(wù)原來在同一套實(shí)例上的，現(xiàn)在需要拆分遷移到不同的實(shí)例上，這個(gè)我們也陸陸續(xù)續(xù)遷移50+的DB，現(xiàn)在還在有些在遷移。
下一個(gè)改造是我們現(xiàn)在用DRC做跨機(jī)房的數(shù)據(jù)同步了，所有的數(shù)據(jù)同步都是原生的改成DRC的模式，也會(huì)做很多的調(diào)整。
還有一個(gè)問題，就是賬號(hào)網(wǎng)段也需要做調(diào)整，因?yàn)槲覀冊瓉砘诎踩紤]會(huì)限制某些IP網(wǎng)段，現(xiàn)在網(wǎng)段范圍放大了，所有賬號(hào)都要面臨調(diào)整網(wǎng)段的問題，如果量比較多的話，調(diào)整賬號(hào)風(fēng)險(xiǎn)還是挺高的（很多歷史遺漏會(huì)使得主從賬號(hào)不一致，同名賬號(hào)不同網(wǎng)段等問題，如果出現(xiàn)不一致調(diào)整的時(shí)候主從會(huì)中斷）。
另外怎么保證全局參數(shù)的一致性，起碼要保證同一個(gè)集群，在各個(gè)機(jī)房參數(shù)都是一致的，這個(gè)是比較臟活累活的東西，但是很容易出問題，到處是坑。
另外HA也面臨改造，因?yàn)樵瓉碓谝粋€(gè)機(jī)房，現(xiàn)在有多個(gè)機(jī)房，怎么做到HA的可靠性也是一個(gè)問題。這塊我們也做了很多的改造。
改造完成之后，我們對比下改造前后在數(shù)據(jù)庫這端的變化。實(shí)例就翻了一倍，集群數(shù)量、Proxy配置、數(shù)據(jù)量、HA都會(huì)翻倍。這里特別列了一些DDL的變化，為什么會(huì)有變化，因?yàn)镈RC不做DDL同步這個(gè)事情，這個(gè)事情都需要DBA分開機(jī)房來做（后面會(huì)細(xì)講）。
機(jī)器故障每周也增加了，原來一周碰不到一臺(tái)，現(xiàn)在可能一周面臨兩到三臺(tái)這樣的機(jī)器故故障，所以必須要保證你的HA是足夠可靠的。
但是我們?nèi)藬?shù)是沒怎么增加，而且我們馬上要上第三個(gè)zone，維護(hù)的工作量會(huì)增加更多，不過我們沒有加人的計(jì)劃，之所以這樣是因?yàn)槲覀冊诎押芏嗟墓ぷ魍ㄟ^平臺(tái)、自動(dòng)化和項(xiàng)目的方式來推動(dòng)解決掉。
剛剛講了那么多的改造前后的變化。對DBA來講，除了業(yè)務(wù)在多活的時(shí)候做改造，架構(gòu)在多活時(shí)候的支持外，我覺得做多活改動(dòng)最大的就是DBA了，對DBA的挑戰(zhàn)真的很大。就像前面說的在集群數(shù)量很大的情況下，怎么有效保障數(shù)據(jù)一致性、HA、配置、容量，還有DDL等問題。
我們可以看一下。剛剛講數(shù)據(jù)這塊我們需要保證他不能錯(cuò)、不能亂，也不能說因?yàn)橛幸恍?shù)據(jù)的沖突，我們整個(gè)的數(shù)據(jù)流就停下來，這也不合理，否則多活就沒有意義了。
再一個(gè)即便是把前面流量的東西，都按規(guī)則走了，但你也不能保證各個(gè)組件不會(huì)出一些bug的問題，比如說DRC同步的時(shí)候就有bug，我們就要有兜底的檢測，把有問題的數(shù)據(jù)及時(shí)的發(fā)現(xiàn)，甚至是修復(fù)好。
所以我們DBA研發(fā)了一個(gè)DCP的平臺(tái)，DCP就是為數(shù)據(jù)一致性兜底的，它會(huì)全量的對比我們各個(gè)機(jī)房的數(shù)據(jù)，告訴DBA到底什么時(shí)候有數(shù)據(jù)不一致的問題，大概是多少，是什么樣的類型，怎么修復(fù)，不一致量大的時(shí)候還需要有合適的修復(fù)工具。
對DCP設(shè)計(jì)來說，因?yàn)槲覀冇泻芏嗵准?，變?dòng)很多，如果說一旦變動(dòng)就要人為調(diào)整的話，這個(gè)維護(hù)量也是很大的，也很難保證它的準(zhǔn)確無誤，所以它必須能自適配。它需要支持全量、增量、延時(shí)的控制校驗(yàn)和隨時(shí)手動(dòng)校驗(yàn)。
延時(shí)校驗(yàn)就是我們有時(shí)候跨機(jī)房的時(shí)候天然就面臨延時(shí)，這時(shí)候如果有延時(shí)數(shù)據(jù)肯定有差異，DCP需要知道到底是因?yàn)檠訒r(shí)導(dǎo)致的數(shù)據(jù)不一致還是數(shù)據(jù)真的不一致。
還有黑白名單機(jī)制，自定義規(guī)則，白名單有一些表我們不需要校驗(yàn)就可以跳過。自定義規(guī)則就是可以設(shè)定一些相應(yīng)的過濾條件來比較，濾掉一些不需要比較的數(shù)據(jù)。
DCP不光是支持對數(shù)據(jù)一致性的校驗(yàn)，表結(jié)構(gòu)不一致了也需要校驗(yàn)，甚至說多維數(shù)據(jù)也能提供校驗(yàn)支持，比如說一個(gè)訂單可能根據(jù)用戶做了拆分，也根據(jù)商戶做了拆分，這兩個(gè)數(shù)據(jù)是否一致是需要校驗(yàn)的。還有我們需要控制比較的時(shí)候它的延時(shí)、并發(fā)、校驗(yàn)的時(shí)長等，因?yàn)槟愕男ｒ?yàn)一直在跑，消耗過大，跑的時(shí)間很長勢必對生產(chǎn)會(huì)造成影響。
最后我們是需要提供靈活修復(fù)的工具和配套的腳本。這樣比出來的數(shù)據(jù)才能夠快速的恢復(fù)，否則你雖然知道數(shù)據(jù)有問題，但要找這些數(shù)據(jù)怎么樣不一致的，怎么去修復(fù)，再根據(jù)條件去把腳本寫出來，這個(gè)過程就很長了，等你修復(fù)說不定業(yè)務(wù)已經(jīng)影響比較大了。
DCP平臺(tái)上線以后，每天大概有400多套集群需要校驗(yàn)，日均校驗(yàn)的數(shù)據(jù)有60多億，分鐘級別的校驗(yàn)頻率。實(shí)際發(fā)現(xiàn)數(shù)據(jù)一致性的問題起碼有50+例。
不一致的原因可能是業(yè)務(wù)寫錯(cuò)了，DRC出BUG了，還有可能是各環(huán)節(jié)（包括DB）的配置問題，如果你沒有相應(yīng)數(shù)據(jù)校驗(yàn)的工具，其實(shí)你是很難知道到底數(shù)據(jù)是不是一致的，多活做的時(shí)候這個(gè)情況必須要能掌握，否則心里沒底了。
剛剛講的是數(shù)據(jù)校驗(yàn)DCP的平臺(tái)，還有一個(gè)HA的保障，集群數(shù)量翻番了，這時(shí)候你需要保證任何一個(gè)節(jié)點(diǎn)掛了都能盡快的切過去，同時(shí)如果你的節(jié)點(diǎn)有調(diào)整有下線等，你都需要保證HA配置能夠跟著變動(dòng)，否則HA的成功率就會(huì)得不到保證，800多套集群也不可能再依賴人肉去保證了。
所以我們做一個(gè)EMHA，他有什么作用呢？首先集群任何節(jié)點(diǎn)變動(dòng)都能夠自動(dòng)感知，當(dāng)然我們底層是依賴于MHA的，MHA的配置大家用過的話都知道它需要對SSH做互通，有任何一個(gè)調(diào)整需要把他從配置文件里面加進(jìn)去或者刪除，否則切換就有問題，所以EMHA新增了自動(dòng)感知配置保持的功能，自動(dòng)解決這些問題。
第二個(gè)重要的功能是變動(dòng)信息的擴(kuò)散通知的機(jī)制，因?yàn)槲覀兪峭ㄟ^DRC同步數(shù)據(jù)的，如果有一個(gè)master出問題切換了，這時(shí)候要通知DRC去連新的master，并且還需要提供相應(yīng)的位點(diǎn)信息，還有各種監(jiān)控也需要得到通知，要知道這個(gè)master掛了以后，新的master是哪一個(gè)，否則后面維護(hù)的信息其實(shí)都會(huì)錯(cuò)亂；
第三點(diǎn)我們的切換需要讓Proxy這一層自動(dòng)感知，如果不能自動(dòng)感知的話，每次切換Proxy都需要維護(hù)，這個(gè)可能會(huì)中斷生產(chǎn)的訪問，而且這個(gè)維護(hù)質(zhì)量基本也得不到保證，所以EMHA也會(huì)自動(dòng)完成與Porxy配置層信息的互通。
還有配置的保持也是比較麻煩的事情，我們在代理層的配置，如果節(jié)點(diǎn)變動(dòng)了也需要變（調(diào)整區(qū)別于切換，切換DAL可以通過EMAH自動(dòng)感知）。有各種參數(shù)，如果說調(diào)整不一樣了，也需要全局的同步的，這些東西都需要有很多自動(dòng)發(fā)現(xiàn)的手段，包括自動(dòng)處理的方式。
當(dāng)然我們現(xiàn)在有些也還沒有能完成做到自動(dòng)化（正在努力中），目前還有些是通過巡檢腳本來發(fā)現(xiàn)的，起碼保證能夠發(fā)現(xiàn)它然后解決掉。
容量這塊，現(xiàn)在是兩個(gè)機(jī)房，兩個(gè)機(jī)房的流量并不一定均衡，比如上海機(jī)房70%的流量，北京機(jī)房30%的流量，但流量會(huì)隨時(shí)切換，所以必須保證每個(gè)機(jī)房都能夠承擔(dān)所有流量。
當(dāng)然三個(gè)機(jī)房的話，不一定百分之百的冗余，但也一定要知道每套集群是不是能承載切換過來的流量，否則切換過來就面臨雪崩的效應(yīng)。所以對各項(xiàng)指標(biāo)我們都要有相應(yīng)的水位監(jiān)控，提前發(fā)現(xiàn)這些問題。
還有一個(gè)很大的困難是在DDL這塊，因?yàn)镈RC里面不方便做DDL這個(gè)事情，之前我們也嘗試讓DRC同步DDL操作，比如說我們做DDL的時(shí)候，一般是用PT工具來做，這個(gè)過程要拷貝整張表的數(shù)據(jù)，如果這個(gè)表比較大，DDL時(shí)兩個(gè)機(jī)房之間的流量就會(huì)面臨很大的沖擊，而且延時(shí)會(huì)相當(dāng)大，比如說100G的表在一個(gè)機(jī)房做完要同步到另外一個(gè)機(jī)房去，這沖擊業(yè)務(wù)影響是不可接受的。
所以DDL需要DBA在每個(gè)機(jī)房單獨(dú)做，我們開發(fā)了一套DDL發(fā)布工具。因?yàn)槲覀冇泻芏鄶?shù)據(jù)類型，有GlobalZone還有shardingZone我們還有大量Sharding 表。對單個(gè)業(yè)務(wù)邏輯表的DDL來說，實(shí)際上我們一套集群里面有幾百張表，這個(gè)表又分布在多套集群里面，所以實(shí)際業(yè)務(wù)一張邏輯表的DDL操作，實(shí)際DDL需要做一千張表，同時(shí)還有各種不同的業(yè)務(wù)集群類型，我們在發(fā)布工具必須要能自動(dòng)適配和識(shí)別這些情況（這個(gè)時(shí)候元數(shù)據(jù)維護(hù)相當(dāng)重要了，因?yàn)槿艘呀?jīng)識(shí)別不了啦，只能依靠工具）。
還有剛剛講DDL的時(shí)候大家普遍用PT的工具，我們用的時(shí)候也發(fā)現(xiàn)了很多問題，畢竟是它是同步觸發(fā)器的，一旦加上去之后，瞬間TPS很高的話，就把數(shù)據(jù)庫打爆了。
所以我們在這塊也做了大量改造，到現(xiàn)在大部分情況下我們已經(jīng)不用PT了，大家看這個(gè)圖上有好幾種工具可以選擇。我們基于開源社區(qū)的gh-ost做了一個(gè)二次開發(fā)改造，改造后的工具叫mm-ost，是一個(gè)跨機(jī)房的DDL工具，不僅解決了DDL的時(shí)候threadrunning不可控、主從延時(shí)不可控的問題，還解決了跨機(jī)房延時(shí)的問題，速度比gh-ost要快一倍。
我們是多機(jī)房，多機(jī)房和你做一個(gè)機(jī)房的DDL時(shí)完全不一樣的，因?yàn)槟愕臋C(jī)器可能有差異或者繁忙程度不一樣，可能這個(gè)機(jī)房DDL做完了，另外一邊要半小時(shí)之后才能做完，尤其是一個(gè)業(yè)務(wù)邏輯表的DDL對應(yīng)的是上千張物理表的DDL時(shí)，差異性就更大了，這樣造成的跨機(jī)房延時(shí)業(yè)務(wù)可能沒法接受，所以我們需要的不僅是能保證同機(jī)房DDL主從延時(shí)的可控，還要保證跨機(jī)房的延時(shí)的可控。
mm-ost現(xiàn)在就能夠支持到跨機(jī)房同步完成DDL的時(shí)差控制在3到5秒之內(nèi)。這延時(shí)對業(yè)務(wù)來說就沒什么感覺了，而且他可以支持暫停、探測到DDL數(shù)據(jù)延時(shí)的時(shí)候能夠減慢速度，能根據(jù)機(jī)器負(fù)載動(dòng)態(tài)調(diào)整DDL的速度等，所以現(xiàn)在DDL基本上對業(yè)務(wù)來說是沒有感覺的。
另外，大家可以看我們的發(fā)布平臺(tái)做的很復(fù)雜，它底層調(diào)用的是mm-ost，在發(fā)布平臺(tái)上我們也做很多控制，比如說DDL空間滿不滿足，各個(gè)主機(jī)是不是都滿足去做DDL的條件，主從我們需要控制的延時(shí)在30秒之內(nèi)，有鎖的時(shí)候需要減緩速度，還支持定時(shí)執(zhí)行（因?yàn)槲覀冇行I(yè)務(wù)的低峰是晚上4點(diǎn)，所以DBA不可能每次都是4點(diǎn)來做這個(gè)事情，這時(shí)就要定時(shí)功能的支持）。
另外系統(tǒng)還可以通過識(shí)別業(yè)務(wù)高低峰推薦什么時(shí)候做DDL比較合適，還有一些風(fēng)險(xiǎn)識(shí)別的控制，我們還要預(yù)估DDL的時(shí)長，如果開發(fā)問一個(gè)500G的表DDL大概多久能做完？你需要能大概告訴他，給他一個(gè)預(yù)期?？傊l(fā)布這塊是我們面臨最大的一個(gè)挑戰(zhàn)，我們在上面做了很多工作。
我們DDL數(shù)量相當(dāng)多，可以說在多活改造的時(shí)候，DBA發(fā)布的量是最多的。多活改造期間我們DDL基本上每周的工單都在四位數(shù)，四位數(shù)的工單數(shù)量，放到底層來講，可能一個(gè)邏輯表生成一千個(gè)DDL，就是最少是5位數(shù)DDL物理表的量了。
如果完全依賴DBA來執(zhí)行，也很難支持了，所以我們加了自動(dòng)發(fā)布功能，對于風(fēng)險(xiǎn)不高的工單是系統(tǒng)自動(dòng)執(zhí)行的，粗略的比例大概是8：2，絕大部分都是自動(dòng)發(fā)布了。風(fēng)險(xiǎn)性比較高的工單我們才需要人去處理，我們統(tǒng)計(jì)了一下半年大概有15000個(gè)工單。
大概的挑戰(zhàn)主要的方面已經(jīng)跟大家分享了。我們最后看一下多活做完以后收益有哪些。
做多活之前，我們也面臨過很多棘手的問題，比方我們之前面臨著整個(gè)機(jī)房出現(xiàn)問題（核心交換機(jī)出問題、網(wǎng)絡(luò)出問題），還有些機(jī)房因?yàn)樵跇I(yè)務(wù)沒有那么大之前你不可能預(yù)留特別多的機(jī)柜，但你現(xiàn)在說我業(yè)務(wù)漲的很快，現(xiàn)在要加一千臺(tái)機(jī)器、兩千臺(tái)機(jī)器的時(shí)候，發(fā)現(xiàn)你加不了，因?yàn)槟愕腎DC不能給你這個(gè)支持，他們不可能給你預(yù)留這么多機(jī)柜，這個(gè)時(shí)候你就面臨單機(jī)房沒法擴(kuò)容的麻煩，之前只能考慮遷移到一個(gè)更大的機(jī)房去，但也是個(gè)耗時(shí)費(fèi)力成本高的事情。
我們多活做了之后，首先打破了單機(jī)房容量的瓶頸，單機(jī)房不能擴(kuò)容的時(shí)候，我們現(xiàn)在可以在另外的機(jī)房擴(kuò)容我的機(jī)器，也可以分不同的流量來滿足負(fù)載，就不再受到單個(gè)機(jī)房容量的限制。
另一個(gè)，多活上線到現(xiàn)在我們流量切了有20次左右，有時(shí)候是演練，有時(shí)候是真實(shí)發(fā)生故障，現(xiàn)在其實(shí)就不再受到單機(jī)房故障的影響，甚至是單地域的影響，假如說上海哪一天全斷電了對我們影響也不大（當(dāng)然只是指技術(shù)層面）。
還有故障兜底，有的問題可能是比較麻煩的問題，一下子沒有辦法判斷或者解決，那時(shí)候可能影響很大，但只影響單個(gè)機(jī)房，這個(gè)時(shí)候就可以把業(yè)務(wù)切到另外一個(gè)機(jī)房，等我們把問題解決了以后再把流量切回來，這樣對業(yè)務(wù)就基本沒有損失了，所以多活之后對我們整體可用性也有一個(gè)很大提升。
另外一塊是動(dòng)態(tài)調(diào)整各個(gè)機(jī)房的流量，尤其是在做一些促銷活動(dòng)的時(shí)候，有些地區(qū)的流量明顯是不均衡的，這時(shí)候如果能動(dòng)態(tài)的調(diào)整機(jī)房之間的流量訪問，這是比較好的分擔(dān)壓力，像阿里雙11這種活動(dòng)，應(yīng)該會(huì)根據(jù)流量壓力來調(diào)整各機(jī)房之間的分配。
接下來在來講下多活這塊后續(xù)我們可能要做一些事情，一個(gè)是剛剛講的多個(gè)機(jī)房，我們現(xiàn)在正在準(zhǔn)備第三個(gè)機(jī)房，因?yàn)閮蓚€(gè)機(jī)房的代價(jià)比較高，冗余比較多，我們需要做第三個(gè)機(jī)房分?jǐn)傔@塊的成本，當(dāng)然一開始成本是比較高的，往后業(yè)務(wù)繼續(xù)上漲的話，可能不需要做太多的擴(kuò)容。而且現(xiàn)有百分之百冗余的機(jī)器資源，可以再做調(diào)配，這樣成本往后來看的話是會(huì)下降的。
另外一塊是數(shù)據(jù)的Sharding，這個(gè)我們還沒有做到，因?yàn)槲覀冊诟鱾€(gè)機(jī)房都是全量的數(shù)據(jù)，這也是我們后面努力的方向；
還有一個(gè)是自動(dòng)動(dòng)態(tài)擴(kuò)縮容，我們需要有更細(xì)的控制能力來自動(dòng)的完成這些動(dòng)作，尤其是在硬件資源利用率上能動(dòng)態(tài)調(diào)整；
最后一個(gè)點(diǎn)是希望能夠提供多機(jī)房數(shù)據(jù)強(qiáng)一致性的架構(gòu)方案，因?yàn)槲覀儸F(xiàn)在來講都是最終一致性的，怎么對一些非常重要的數(shù)據(jù)，提供各個(gè)機(jī)房數(shù)據(jù)及時(shí)強(qiáng)一致性，這塊也是我們接下來需要努力的方向。
更多相關(guān)文章閱讀
Python 編程中常用的12種基礎(chǔ)知識(shí)總結(jié)
青銅到王者，快速提升你 MySQL 數(shù)據(jù)庫的段位！
有贊數(shù)據(jù)庫自動(dòng)化運(yùn)維實(shí)踐之路
學(xué)好 Python、拿高薪、竟是如此簡單
快加入高維學(xué)院直通車成為認(rèn)證運(yùn)維開發(fā)工程師
只需要5天！
在5天內(nèi)集中向你傳授面向 DevOps 的運(yùn)維開發(fā)工程師所需要掌握的所有精華。
更有含金量的是，學(xué)習(xí)結(jié)束你還將擁有一張【運(yùn)維開發(fā)工程師認(rèn)證證書】
這份含金量超高的證書：
聯(lián)系客服
