京東11.11：數據庫運營實踐——智能化、自動化、平臺化
從2012年618訂單中心使用MySQL，到2013年618大促中MySQL數據庫已經支撐起了京東交易系統的半壁江山。目前京東的核心數據庫都已基本運行在MySQL上，規模十分龐大，日常的PV已達千億級別。這些年來，618、雙11大促數據庫的準備越來越精細，本文以最近4次大促為基點，從智能化、自動化、平臺化三個方面來談一談京東在MySQL數據庫方面的探索和實踐。
另，ArchSummit全球架構師峰會北京站將于2015年12月18日~19日在北京國際會議中心召開，大會設置了《 揭秘雙十一背后的技術較量 》專題來深入解讀雙十一背后的技術故事，歡迎關注。
這里不得不提下JMySQL，全稱是“京東MySQL數據庫智能管理平臺”，是開源數據庫運營部近4年來自主開發的數據庫管理平臺，集MySQL 監控系統、MySQL性能智能分析系統、MySQL自動部署系統、MySQL切換系統、MySQL備份恢復系統、MySQL故障智能處理系統、MySQL 日常運維管理系統、MySQL安全系統于一體的管理系統。既然是雙11專題，我就順勢舉例介紹下其中幾項功能在雙11中的作用。
MySQL性能智能分析
這是JMySQL智能管理平臺的重要功能之一，對于當前MySQL數據庫運行性能情況、壓力情況、瓶頸、潛在的風險進行分析、匯總，風險點一目了然，讓DBA知道立刻需要處理什么樣的問題，這個在平時數據庫管理中已發揮了重要作用，在大促前更是如此。
本次雙11數據庫是按照前端流量可能增加20倍進行備戰的，對于“抵擋”前端流量的數據庫來講風險非常大，算法上我們為這類數據庫確定了壓力倍數 A，負責后端處理的數據庫壓力倍數通常小于A，因為有中間一系列環節處理，它的壓力倍數被確定為B，有些系統壓力會增加的非常大，DBA從研發處得到可能增加的壓力倍數，則這個系統的特定壓力倍數為C，在當前性能指標的基礎上，可計算出性能是否滿足，需要增加多少，哪種方式增加。對于不同類型應用對數據庫的壓力也不同，如IO型、CPU計算型、網絡IO型、混合型等，會對數據庫及服務器產生不同程度的影響。一定要避免木桶效應，并考慮峰值，舉個簡單例子：假設一個數據庫別的指標都忽略，IO使用率均值是20%，但峰值達到30%，那這個數據庫就不是能再抗4倍壓力的，因為有峰值，如果確定壓力真的會再增加 4倍，那就要采取解決措施了。如果因為特定原因，不能進行數據庫改造，則一定要制定預案，一旦壓力上來，抗不住了，確保數據庫不被打死。
特別強調下對于核心數據庫不只是單純的先進行指標評估分析，然后擴容改造就行了的，還要盡量進行壓測，通過壓測進行把關，既：要尊重指標分析，但還要注重實際情況。
現在系統設計時大都會在應用和數據庫層之間加Cache層，對于“抵擋”流量的數據庫一定要考慮到Cache層被打穿或者關鍵時刻Cache層異常的情況，DBA這里會按照一個比例預留。基于資源考慮不可能為所有風險點無限制的改造，會按個比例進行，一旦異常情況超出壓力范圍，馬上采用預案，比如該限流的限流、該降級的降級，首先保證主要的核心服務正常，不被打死。這里并不是說只對核心服務這樣處理，時間允許、資源允許的話所有重要服務、服務都需要這樣做。
性能智能分析及故障自動處理技術都依賴著MySQL監控系統，這個系統會對所有MySQL數據庫進行監控。另外，SQL是影響數據庫性能的重要因素，系統會對慢查詢SQL進行分析，分析后的慢查詢自動發給相關研發和DBA進行優化。SQL優化是大促的必要準備工作，當然這個工作是平時需要持續做的。
MySQL自動擴容、部署
在平時，流量上來后數據庫的性能出現瓶頸時，要具體問題具體分析，不能盲目的進行擴容、拆分、硬件升級等，先要根據具體的SQL效率、性能，結合數據庫本身情況分析判定，也許調整一下索引，SQL語句做一下調整即可解決并發量上來后的性能問題。數據庫的擴容、拆分、硬件升級，是需要綜合考慮各項性能指標、業務量變化情況來判定，否則造成人力、物力等資源浪費。研發在開發的過程中，涉及到數據庫的，特別是重要系統，都會有DBA的參與，通過技術手段在上線前就確保性能情況。功夫要下在平時，不能光靠大促前的準備。
在雙11階段，因為流量突增，會有不少數據庫需要提前改造。如主從庫全部更換高IO硬件、增加讀庫、數據庫水平拆分、數據庫垂直拆分等情況，部分服務雙11后還需要縮回到之前規模。這么多年來MySQL數據庫擴容、部署系統已經比較成熟，功能也健全了，結合數據庫切換系統，改造工作已沒技術難度，只是量比較大，不能因為改造影響服務，往往需要在幾周內就要改造完成，改造的系統眾多，除了增加讀庫的場景外，其他的改造都會在流量低的時間段進行，DBA和研發緊密配合，自動化技術手段+改造方案。
為了防止機房毀滅性情況出現，增加了專門的機房可提供災備切換，為幾千臺的數據庫系統完成了跨機房同步庫的部署、同步。
MySQL本地、跨機房切換
在大規模部署中，數據庫在多個機房都會有從庫，再加上多中心雙活交易，會有雙活的寫庫，場景會相對復雜。數據庫宕機或網絡異常后的切換是DBA一項重要工作，在MHA基礎上DBA開發了自動切換程序JDSWITCH，在可接受自動切換的數據庫上部署，其他的數據庫因為業務原因會使用切換平臺進行切換。切換平臺也是JMySQL的一個重要功能，支持按單臺切換、按數據庫集群切換、按子系統集群切換、整個機房進行切換。在可連通情況下，切換時會自動掛同步關系，所有數據不需要重做，如連不通則切換后有程序檢驗數據情況，能補齊的補齊，如無法補齊用自動部署系統重做。一旦大促時機房異常，所有MySQL 集群可在幾分鐘完成跨機房切換，防止挖土機關鍵時刻的絕殺。
預案和壓測軍演
通過對故障的統計、分析，數據庫預案越來越多精細，會發生的故障都有相關的處理方案，有相關腳本、程序、平臺執行，并會多次演練，經受實踐的檢驗。
壓測、軍演是大促必不可少的組成部分，會進行多次軍演，發現潛在性能隱患進行處理。在穩妥、準備充足的前提下，不要怕軍演，現在不去真槍實彈，到了生死瞬間就只能祈禱了。好比模擬了老機房宕機，把核心數據庫切到新機房運行跑著，再把這些數據庫集群無縫切回去，這次軍演完成后信心更加十足了。
各種細節、小事情的處理
細節決定成敗，在一個真實的N個機房、大幾千臺規模的MySQL數據庫規模下，真不是以上這些做好大促就高枕無憂了，要重視和處理很多細節，往往這些細節和小事情會在關鍵時刻絕殺，讓人遺憾，有過大促經驗的朋友們應該很理解這點。每次大促我都在想，還有哪些細節、“小事情”沒考慮清楚，要盡快處理。
總結
618、雙11作為期中、期末2次大考，鍛煉了技術團隊，特別是開源數據庫運營部的DBA們，面對各種緊急情況早就成竹在胸了。大促推動了MySQL等開源數據在京東的發展，推動了MySQL運維自動化、自助化的發展。