餓了么DBA經(jīng)理 虢國飛
　　CSDN：首先請您簡單介紹下自己、公司以及目前所負(fù)責(zé)的領(lǐng)域。
　　虢國飛：大家好，我叫虢（guo）國飛，網(wǎng)名“飛揚(yáng)過?！?，一直從事數(shù)據(jù)庫領(lǐng)域的工作，熟悉的數(shù)據(jù)庫產(chǎn)品有MySQL、MSSQL、PostgreSQL和部分NoSQL，先后在5173、新蛋網(wǎng)、滬江網(wǎng)從事過DBA方面的工作，現(xiàn)在“餓了么”公司擔(dān)任DBA經(jīng)理職務(wù)，主要負(fù)責(zé)餓了么數(shù)據(jù)庫的維護(hù)和數(shù)據(jù)庫團(tuán)隊(duì)的管理工作。
　　CSDN：您在數(shù)據(jù)庫行業(yè)多年，掌握著豐富的數(shù)據(jù)庫開發(fā)和設(shè)計(jì)經(jīng)驗(yàn)，那么您是如何保持對這份技術(shù)熱情的呢？
　　虢國飛：個人認(rèn)為，能夠在一個領(lǐng)域里面保持持續(xù)的熱情，主要取決于興趣、成就感和好奇心，只有熱愛這個行業(yè)、這份工作，才會不斷的想去學(xué)習(xí)、研究和思考，如果再能在此基礎(chǔ)上做出一些有意思的事情，取得一些成績，然后結(jié)交一些朋友，相信這份成就感會繼續(xù)支持你在這個行業(yè)里面走下去；還有需要保持一顆好奇心，樂于接受新的事物和技術(shù)，能打破自己已有的知識體系，融入新的思想，再從新組織起來，形成新的體系，這樣才能不斷豐富、提升自己。
　　CSDN：您能和我們分享下餓了么訂單從每天幾十萬單到如今的幾百萬訂單過程中，在數(shù)據(jù)庫架構(gòu)方面是如何調(diào)整變化的，以及每個階段面臨了哪些問題，又是如何應(yīng)對的呢？
　　虢國飛：我最初到餓了么的時候，那時候每天幾十萬的單量，但是因?yàn)轲I了么之前一直沒有專門的DBA，使得數(shù)據(jù)庫面臨的問題很多，包括磁盤空間不足、主從延時、連接數(shù)不夠、無規(guī)范、無規(guī)則、大量慢SQL等問題一應(yīng)俱全；我過去后做了三件事情：1. 先解決一些救火方面的問題，比方磁盤空間、延時、連接數(shù)等，2. 推動數(shù)據(jù)庫設(shè)計(jì)、開發(fā)的規(guī)則、規(guī)范和數(shù)據(jù)庫部署安裝的規(guī)范，3. 收集了數(shù)據(jù)庫運(yùn)行數(shù)據(jù)、加上了監(jiān)控報警；三項(xiàng)措施其實(shí)瞄準(zhǔn)了三個方向：穩(wěn)定現(xiàn)在、收緊入口、把控數(shù)據(jù)；尤其是把控數(shù)據(jù)方面，為我們后面的架構(gòu)調(diào)整和DB優(yōu)化提供了數(shù)據(jù)、指明了方向。
　　數(shù)據(jù)庫架構(gòu)調(diào)整大概經(jīng)歷了四個階段：硬件和DB升級、垂直拆分、sharding、異地容災(zāi)。
　　硬件和DB升級：
　　這個是最開始為解決磁盤空間、延時、SlowSQL等問題采取的一些救火措施，我們上了SSD盤、升級MySQL5.5到5.6、增加slave將不同業(yè)務(wù)劃分到單獨(dú)的slave上面 （做隔離，單個業(yè)務(wù)Slow SQL不影響全局 ）、同時還進(jìn)行了機(jī)房的搬遷，這其中遇到MySQL升級到5.6 業(yè)務(wù)代碼不兼容的問題（主要是時間和null值不兼容，前期測試也做得不完善），導(dǎo)致真正實(shí)施的時候排查了比較久。
　　垂直拆分：
　　隨著我們訂單量的不斷上漲，主庫的壓力增加明顯，我們通過之前收集的運(yùn)行數(shù)據(jù)，再對比我們壓測數(shù)據(jù)，發(fā)現(xiàn)原有的架構(gòu)下，訂單上升到200萬單左右，核心數(shù)據(jù)庫TPS就支持不了啦，同時Slave延時的問題還會繼續(xù)出現(xiàn)，連接數(shù)也不夠，于是我們將核心的主庫按業(yè)務(wù)和TPS的比例拆分成了五套集群，其他相關(guān)的業(yè)務(wù)庫也按照我們的運(yùn)行數(shù)據(jù)和壓測效果一一拆分，最終平穩(wěn)支持了300多萬單的沖擊；這個階段其實(shí)主要的問題在于，如何有節(jié)奏的推動開發(fā)人員配合我們來做DB的拆分，那在拆分之前我們會通過我們的數(shù)據(jù)來告知到老板和開發(fā)負(fù)責(zé)人我們DB會面臨哪些問題？瓶頸在哪里？不調(diào)整的話最多能支撐的訂單量是多少？我們會拿運(yùn)行數(shù)據(jù)、壓測數(shù)據(jù)以及我們拆分后的預(yù)期數(shù)據(jù)來展示給他們，有了數(shù)據(jù)的支撐和專業(yè)的對比分析，老板也會幫我們推動拆分的事；其實(shí)還沒完，等拆分完成后我們會拿實(shí)際運(yùn)行的數(shù)據(jù)和之前預(yù)期的數(shù)據(jù)做對比，做成分析報告發(fā)給老板和相關(guān)的開發(fā)人員，讓大家感覺到咱們做的事情是有效果、有價值的。
　　sharding：
　　這個階段，系統(tǒng)要求是10x容量設(shè)計(jì)，這個階段對DBA來講，其實(shí)比較痛苦，首先是方案的確定會比較麻煩，最重要的是依賴的因素太多了，很多事情DBA并不能把控，需要很多資源的投入；因?yàn)闃I(yè)務(wù)比較復(fù)雜，光討論sharding的切片方案就耗時1個多月，還有sharding的方案選型、實(shí)施方案、灰度方案、回滾方案以及業(yè)務(wù)代碼的改造等；最終我們將核心的DB拆分為兩個維度（用戶和商家維度），分了120個片（可以支持1024片），從一套集群變成了12套集群，引入了DAL層（對業(yè)務(wù)透明），改造后經(jīng)過壓測分析，可以支持到3000w訂單/天的量；當(dāng)然這種調(diào)整也帶來了新的問題，如sharding之后數(shù)據(jù)一致性（兩個分片）、DAL本身的容災(zāi)機(jī)制、DB維護(hù)量增加等；我們后面開發(fā)了數(shù)據(jù)差異對比和自動數(shù)據(jù)訂正工具來保障數(shù)據(jù)的一致性，同時也在DAL這一層做了冗余的災(zāi)備機(jī)制，DB維護(hù)我們也通過工具來簡化DBA的操作。
　　異地容災(zāi)：
　　這個是我們正在進(jìn)行的階段，異地災(zāi)備投入比較大，而且風(fēng)險也比較高，目前因?yàn)槲覀儾]有在MySQL源碼上面做一些工作，有沒有開發(fā)drc類似的工具（當(dāng)然這個是我們努力的方向），所以方案的研究和測試都是在考慮MySQL缺陷下進(jìn)行的，比如一開始我們就是基于切換的時候兩邊的數(shù)據(jù)有差異的前提下來討論方案的（當(dāng)然數(shù)據(jù)是不能丟的，我們需要知道哪些數(shù)據(jù)出現(xiàn)了問題），因?yàn)閿?shù)據(jù)的延時，帶來比較嚴(yán)重的問題是數(shù)據(jù)的沖突和業(yè)務(wù)數(shù)據(jù)狀態(tài)的一致性，對這些數(shù)據(jù)的丟失或者不一致問題，我們是通過業(yè)務(wù)方和DBA分別跑腳本來應(yīng)對的，即業(yè)務(wù)會負(fù)責(zé)業(yè)務(wù)數(shù)據(jù)狀態(tài)不一致的修復(fù)，DBA會負(fù)責(zé)修復(fù)數(shù)據(jù)的沖突（比方切換前自增列我們會統(tǒng)一將自增因子調(diào)大或者一開始兩邊就是奇偶遞增，避免新寫入的數(shù)據(jù)和老的數(shù)據(jù)沖突），等機(jī)房恢復(fù)后，我們再來通過腳本比對差異的數(shù)據(jù)，跟進(jìn)業(yè)務(wù)方案來修復(fù)，目前方案還在測試驗(yàn)證當(dāng)中。
　　CSDN：在您看來，您覺得數(shù)據(jù)庫技術(shù)接下來會面臨著哪些挑戰(zhàn)？它的發(fā)展趨勢又如何？
　　虢國飛：現(xiàn)在互聯(lián)網(wǎng)對數(shù)據(jù)庫的使用方式發(fā)生了很多變化，數(shù)據(jù)庫不再像過去那樣笨重，變成很輕的東西了，因?yàn)榇蠹覍?shù)據(jù)庫的吞吐量有更高的要求；而且現(xiàn)在硬件性能提升很快，數(shù)據(jù)庫以前的瓶頸以前說是在磁盤IO上，后面可能轉(zhuǎn)變到數(shù)據(jù)庫代碼能否將這些強(qiáng)悍的硬件性能使用好的情況。
　　個人感覺，數(shù)據(jù)庫技術(shù)會往三個方向發(fā)展，第一是提高數(shù)據(jù)庫本身的吞吐量，在保證數(shù)據(jù)的一致性的前提下，如何減少鎖或者提高鎖效率、提高并發(fā)度、細(xì)化管理方式和提示信息等方面，像MySQL這類開源數(shù)據(jù)庫，還是有很多地方可以繼續(xù)完善；第二是分布式數(shù)據(jù)庫技術(shù)發(fā)展，目前大部分公司在做分布式數(shù)據(jù)庫時都會依賴中間件，沒有能力做中間件的公司，要做數(shù)據(jù)庫的sharding會比較痛苦，開發(fā)人員需要改造很多代碼，而且升級、維護(hù)都會比較麻煩，不過中間件的引入會帶來新的問題，拖慢了效率，增加一個新的風(fēng)險點(diǎn)，增加了溝通成本，出問題時排查的路線也會更長；如果能讓數(shù)據(jù)庫本身實(shí)現(xiàn)中間件的機(jī)制，那對DBA來講會是很給力的支持，DBA完全能夠自己把控，現(xiàn)在有一些公司在做這個研究；第三是云數(shù)據(jù)庫，CDB目前發(fā)展也比較迅速，高配的CDB 越來越多，有豐富的工具支持，中小型的業(yè)務(wù)完全可以使用CDB，如果不關(guān)注狀態(tài)的業(yè)務(wù)也可以在多個CDB之間做災(zāi)備（比方發(fā)送短信的業(yè)務(wù)），不過數(shù)據(jù)量大、并發(fā)高、要求高的業(yè)務(wù)，還是推薦自己來維護(hù)。
　　CSDN：您在餓了么期間，有沒有很有意思的事情發(fā)生，讓您至今記憶猶新呢？
　　虢國飛：我覺得DBA最印象深刻的是故障，尤其是大的故障，我記得在餓了么經(jīng)歷了一個比較大的事故是int字段溢出的問題，碰巧的是我們業(yè)務(wù)代碼之前就有對這個表的插入失敗情況，于是拋出的錯都被業(yè)務(wù)丟棄了，當(dāng)時正是業(yè)務(wù)高峰期，訂單狀態(tài)都不輪轉(zhuǎn)了，我們的各項(xiàng)監(jiān)控指標(biāo)都在安全水位，而且沒有錯誤日志，大家都找到問題；后來還是一位熟悉業(yè)務(wù)的架構(gòu)師發(fā)現(xiàn)這個現(xiàn)象后，再對表進(jìn)行測試才找到原因；這個事情讓我感受最深的是做DBA很多事情不能停留在表面，我們對各種性能指標(biāo)都有監(jiān)控，但是這個還是不夠的，還必須深入到業(yè)務(wù)，才能真正在問題出現(xiàn)時及時定位；現(xiàn)在我們的監(jiān)控會加入對業(yè)務(wù)對數(shù)據(jù)的監(jiān)控，這需要深入了解業(yè)務(wù)的特點(diǎn)，這樣我們才能制定有效的監(jiān)控指標(biāo)，有的放矢，自證清白（即便故障時沒有業(yè)務(wù)代碼的錯誤信息，我們也能知道DB到底有沒有問題）。
　　CSDN：以您對數(shù)據(jù)庫技術(shù)的多年研究，如何才能更好的掌握數(shù)據(jù)庫這門技術(shù)呢？
　　虢國飛：個人認(rèn)為有幾點(diǎn)：感興趣、愛學(xué)習(xí)、多動手、勤思考、善總結(jié)，先深入學(xué)習(xí)某一款數(shù)據(jù)庫，再擴(kuò)展到其他，搭建T型知識體系，最終能形成一套自己的維護(hù)管理DB的方式方法。
　　CSDN：在本次SDCC數(shù)據(jù)庫峰會上分享的話題是？
　　虢國飛：“餓了么數(shù)據(jù)庫架構(gòu)變遷”，希望和大家分享下我們在業(yè)務(wù)快速增長下是怎么來調(diào)整數(shù)據(jù)庫架構(gòu)的，同時和大家探討下各種架構(gòu)的優(yōu)劣。
　　CSDN：您最期待在本次SDCC數(shù)據(jù)庫峰會上聽到哪些內(nèi)容？
　　虢國飛：數(shù)據(jù)庫架構(gòu)和技術(shù)發(fā)展上面其他同仁的一些新的想法和實(shí)踐，還有遇到過的問題。
?

普通下載普通下載

相關(guān)電子資料下載

• 常用于緩存處理的機(jī)制總結(jié) 如何避免緩存雪崩問題？ 24
• 觸發(fā)器的基本原理、應(yīng)用場景及優(yōu)缺點(diǎn) 83
• AI大模型對數(shù)據(jù)存儲技術(shù)的發(fā)展趨勢 64
• 訪問控制中PIP的典型流程和關(guān)鍵點(diǎn)思考 60
• 物證管理系統(tǒng)|智物證DW-S404是一套成熟系統(tǒng) 44
• Python 梯度計(jì)算模塊如何實(shí)現(xiàn)一個邏輯回歸模型 93
• TinyDB ：一個純Python編寫的輕量級數(shù)據(jù)庫 58
• mysql經(jīng)典面試題及答案 63
• 人大金倉獲評“2023年度軟件和信息技術(shù)服務(wù)名牌企業(yè)” 100
• 人大金倉亮相第40屆CCF中國數(shù)據(jù)庫學(xué)術(shù)會議（NDBC 2023） 119