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