![](https://img.alicdn.com/imgextra/i2/O1CN01eLSXN41fATad3QakU_!!6000000003966-2-tps-1080-539.png)

每年雙11，各個電商平臺的流量突增，全民都在喜迎這場購物狂歡。除了流量增長，各個平臺的交易資料也達到了全年的峰值。對於資料庫和運維人員也將迎來年度大考，支撐這場大考一切業務指標的背後，是底層技術體系不斷迭代升級。

**OceanBase**原生分散式資料庫**已經連續9年穩定支撐雙11，積累了很多關於大促期間的運維經驗。**所以，在雙11即將到來之際，《對話ACE》第七期邀請 OceanBase 解決方案架構師、前螞蟻集團資料庫團隊DBA專家白超，Oracle ACE 惠星星，一起就“**雙11如何保證資料庫穩定可靠**”這個話題展開了深入探討。

------

以下為對話實錄，歡迎大家閱讀、收藏！

**Q1**

### **您覺得該如何界定與保證資料庫的穩定可靠？**

**惠星星：**

資料庫的穩定性可以透過RTO（Recovery Time Objective）來界定，它是資料中心災難恢復方面的重要參考指標，表示業務從中斷到恢復正常所需的時間。保證資料庫的穩定可靠，在上線前需要做好“建轉運”以及執行期間的管理。

**首先我認為要對日常運維人員做好培訓**，因為人員穩定性、誤操作以及技能等各種各樣的問題都可能影響資料庫的穩定執行。在這裡借用恩墨學院的12大箴言：原理通透、思路清晰、操作嫻熟，做好人員的培訓以及夯實基礎能夠一定程度上來避免由於人員操作造成的資料庫隱患。

作為資料庫運維人員，有時候會認為自身的工作意義不大、重複性較多，創造性不高，但要結合到具體的業務場景中，自身價值就能夠體現出來，比如我維護的這套金融系統，正是由於基礎工作做得紮實才能保證銀行的日常業務順利開展，讓老百姓能夠正常的存取款，營業廳正常辦理業務。所以大家一定要有主人翁的意識，認識到自己工作的重要性以及對整個社會做的貢獻。

**第二，成熟的架構以及解決方案能夠保證系統的穩定****。**以Oracle資料庫為例，RAC 是相容高可用和高效能的一個資料庫架構，能夠有效提高整體的業務效能，消除單點隱患。在我維護的Oracle資料庫中，部分企業就有明確的檔案要求重要的系統必須改造成RAC架構，由此可見它的重要性。Oracle的儲存級軟體ASM，透過不同的冗餘程度去消除部分儲存級的隱患。在系統上線前，我們都會給其載入一定的業務壓力，來檢測是否能夠穩定執行，這個時候我們通常會挑選例如賬務的出賬收費、業務辦理等核心功能進行業務層以及特殊語句SQL的壓力測試，總之我們會透過不同維度的資料庫管理方法保證系統的穩定。另外，Oracle還會定期釋出PSU的補丁，來消除由於軟體造成的隱患。Data Guard作為Oracle備用資料庫解決方案，可以在不同的區域機房建設實現資料庫實時同步，幫助資料庫提高應對災害的可靠性。

**第三，規範的建轉運管理流程也是保證資料庫穩定執行的因素之一****。**在資料遷移以及業務系統測試無誤後，可以提交試執行以便提前發現軟體或效能問題。除此之外，執行期間要完善資料庫監控，包括儲存層伺服器層等監控，有條件的也對資料庫進行常態化的監控與最佳化，每天紮實最佳化一條sql，對整體的資料庫效能有很大的提升，當然應急預案的制定以及演練對於資料庫穩定執行也是必不可少。

因此，保證資料庫的穩定執行需要涉及到很多方面與細緻的工作，這也是作為DBA的價值所在。

**Q2**

### **OceanBase 支撐雙11已經九年了，在主從切換中，透過哪些途徑保持資料的強一致性？**

**白超：**

“如何保證主從切換資料的強一致性”這個問題，在雙11的交易支付場景中，要保障資料不能丟失，它的重要程度堪比銀行或者其他金融行業的核心業務。作為前螞蟻集團的DBA，我有很深的體會，當傳統資料庫架構中主從切換的過程中出現問題，會損害具體的業務。在螞蟻集團全面遷移至 OceanBase 之前，傳統的主備架構需要在資料的一致性以及可用性之間作出選擇。2015年螞蟻集團還有一部分核心業務存在於Oracle資料庫上，當時市政工程施工挖斷了電信光纜，導致資料庫的主例項與備例項處於無法通訊的狀態，因為考慮潛在的資料丟失風險，無法快速切換至備機房恢復業務。如果是普通的業務，在接受少量資料丟失情況下可以強行切換備庫。但對於螞蟻集團涉及資金的具體交易中，如果在未知的狀態下，強行切換可能導致無法估計的損失。

OceanBase 資料庫**基於無共享叢集的分散式架構，透過 Paxos 共識協議來保持資料的強一致**，它基於多數派的協議，保證在任一時刻，只有得到多數派的認可，一個節點才能成為主節點提供讀寫服務。如果三個當中的一個或是五個當中的兩個節點發生故障，也能實現業務資料零丟失。

為了保證資料一致性，OceanBase 還從設計的角度出發，對例如**面對資料的靜默錯誤**（因為硬體原因磁碟或記憶體發生位翻轉等導致）這類極端場景，都會**進行線上的事務日誌校驗與資料對比**，以確保不同的使用者在讀到不同副本上的資料都是一致的。除此之外，在沒有業務的場景下我們還可以選擇開啟後臺的任務對基線上的資料做比對，透過多個維度規避主從不一致的問題。因此在螞蟻集團或是支付寶業務切換到 OceanBase 之後。業務上徹底告別了過去因為切換可能導致資料不一致、需要人工修復以及訂正的情況。

**Q3**

### **您覺得雙11，資料庫的效能最佳化應做到哪些？**

**惠星星：**

在實際的運維過程中，可能會透過加記憶體或者升級伺服器這種硬體堆積的方式來提升整個資料庫的效能，但這種方式是比較簡單粗暴的，往往伺服器配置升上去後，業務響應依然達不到理想的效果。因此這也驗證了我剛才講到的維護資料庫一定要重視運維人員的技能提升。其實透過一條SQL的最佳化就能達到幾倍或是上萬倍效能提升的效果，如果只是簡單堆積伺服器，資料庫的效能和以前還是一樣。所以我認為，資料庫最佳化中，一定要分析根本原因來解決問題。

Oracle資料庫有很多可觀測的監控工具，例如ASH報告、效能收集等機制，以及基於資料庫的基礎統計資訊的監控工具，這些輔助工具加上運維人員基礎技能提升來定位到資料庫的根因，從而集中資源有的放矢來進行資料庫的最佳化，而不是透過簡單堆積伺服器這樣的方式來提升效能。

以雙11大促場景為例，我們可以根據歷史資料對特殊場景做提前的業務評估，在壓力測試的過程中去找到系統效能的瓶頸，是記憶體不足，是CPU不足，還是儲存效能不好或是SQL沒有寫好等等原因，因此用好資料庫也是非常關鍵的，不管是商用資料庫還是開源或分散式資料庫，一定要了解它的特性發揮出最大的效能優勢。

**Q4**

### **雙11，除了處理高併發，還要讓使用者有良好的的購物體驗，如何實現系統持續穩定執行？**

**白超：**

雙11電商大促是一個有計劃的高流量場景，最終目標為保障使用者的購物支付體驗，從整體來看需要保證從應用到資料庫再到底層儲存的一整條鏈路能夠達到“絲般順滑”，這對於一個大型的業務系統其實是一件非常困難的事情，尤其是面對雙11巨大的流量以及眾多的人口基礎。除了資料庫系統的穩定執行，還需要從業務設計的角度出發，才能為使用者提供更好的體驗。在支付寶，我們在業務層面中在整體上做了”單元化“的設計，相當於把所有的使用者業務的請求切分為若干個單元，每一個單元的業務的部署和資料庫部署都是自包含。任意單元故障不影響整體業務。**OceanBase 在單元化架構中的主要體現在於極致彈性**，意味著我們能夠在任一時刻將任意1%的流量劃轉到任意一個城市的機房，來解決某個單元或機房容量不足等異常的情況，由此可見流量的排程劃轉能力非常重要。OceanBase 的多租戶多副本設計為螞蟻單元化的架構提供了彈性、穩定的資料底座，保證了使用者體驗。

此外，為了保持資料庫系統的穩定執行，OceanBase 在SQL方面也做了諸多創新，除了在上線或大型活動之前對SQL異常的執行計劃或統計資訊問題做自動化巡檢，針對如何保證交易業務的極致穩定方面也做了特殊的設計。我們知道大部分的線上交易場景都是以相對簡單的SQL為主，追求快速、穩定的響應時間的，而當這類業務遇到一些隨機的彙總查詢，並積累到一定量級時，就可能會影響資料庫的穩定。對此 **OceanBase 引入了大查詢佇列的設計**，對傳送到資料庫上的SQL進行解析，當核心透過SQL ID的識別被判定為大查詢時，便會在下一次該請求發到資料庫時將這條SQL被放到隔離的大查詢佇列中，佇列有一組單獨的隔離資源，能夠保證在流量突然增高的情況下，也會讓大查詢在一個資源有限的佇列中排隊等待而不會過多的佔用關鍵的線上短交易，這個設計能夠很好滿足OLTP場景下對響應時間以及穩定性的嚴格要求。

除了資料庫的SQL角度，OceanBase 也從具體的高併發業務場景出發，保證資料庫的穩定執行。比如電商業務中，大促熱門商品的秒殺，大量使用者的搶購等場景中，需要對商品庫存做到及時的扣減，對應到資料庫中就是某一行的高併發更新；支付寶的業務中，商家大規模高頻轉賬交易也要求餘額及時更新，如果高併發場景不能滿足效能要求，就會直接影響商戶的交易總量以及整體系統的吞吐率。OceanBase 直面解決高併發場景下的問題，單行更新慢在本質上是持有鎖序列更新的問題，等待日誌完全提交再釋放鎖，是導致併發無法提升的關鍵因素。**OceanBase**透過工程上的巧妙設計實現，讓**解行鎖的時機提前，使解行鎖和日誌提交同步的過程非同步化，從而大幅度的提升單行併發的更新能力**，這個功能**可以讓同城部署的資料庫單行TPS提升至3-5倍，跨城部署的環境中提升百倍以上**。這對於螞蟻的雙十一以及高併發場景是非常優秀的特性。

結合 OceanBase 的核心能力和智慧化運維平臺，使得我們也可以很好的提升應對故障或者抖動的能力。當出現徹底的當機或是因為硬體問題導致當前及誒單資料庫徹底的不可用的情況，基於 Paxos 的分散式共識演算法可以在30秒內選舉出一個新的leader（在 OceanBase 4.0中這一指標可以做到8秒以內），並且對應用弱感知。對於因網路出現抖動、時而發生不穩定連線的場景，我們需要快速隔離異常流量，此時可以透過 OceanBase 有主選舉的方式將流量快速隔離到其他健康的節點上。將有主選舉的核心能力結合沉澱了專家經驗的故障感知系統，再配合決策執行模組，這就是螞蟻DBA打造的的故障自愈系統，透過將DBA專家的經驗轉化為一顆根因決策樹，再輔助機器學習的一些手段，我們可以將常見的抖動、當機或容量不足的問題透過這套自愈系統在第一時間做自動感知和恢復，所以從整體的體驗以及穩定性的提升來說，OceanBase 與內部的DBA平臺做了很多積累，由此才能在歷年大促中做到“如絲般順滑”。OceanBase 正是在嚴苛的環境中歷經挑戰，不斷在業務中打磨，才能在既具備高效能和極致彈性的同時，變得更加穩定可靠。

**Q5**

### **雲趨勢下，關於大促場景下如何保證資源穩定保障？**

**惠星星：**

在傳統行業中，雲資料庫有低成本、快速部署以及穩定等優勢，不同企業根據系統的業務特點以及企業管理的規範，資料有可上雲與不可上雲的劃分，可以儘可能地**將符合條件的資料上雲**以便我們有更多的精力維護更有價值的業務，**不可上雲的資源**便可以根據其業務特點提前**做好資源的儲備與擴充**，以確保在類似於大促的場景下滿足業務的需求。

**Q6**

### **針對不同的業務場景，OceanBase 是否具有不同的應急處理及相關預案？**

**白超：**

**首先是****針對異常SQL的處理預案**，我們都知道很多時候資料庫的異常來自於異常的SQL，比如一些業務中部分SQL由執行幾百次突然上升到一個小時執行上萬次，此時對其限流就需要依賴資料庫端的能力。針對這個問題，OceanBase 可以在核心層面限制相同SQL ID的SQL併發度，將其從每分鐘執行上千次降到數十次，甚至降到次實現對其“熔斷”，也就是說在應用側無法做降級和熔斷時，資料庫是有這個能力完成的。同時限流操作可以結合業務等級進行，負責應用業務的人員根據SQL的重要程度，在SQL洞察平臺中進行打標，當線上真正出現問題時，預先被打了標記可以被限流的SQL會由平臺自動做限流操作，同時DBA也可以在第一時間做處理，這就是OceanBase 在限流能力上建設的部分體現。除此之外，在 OceanBase 中，如果出現SQL索引選擇不合理或者表連線方式不正確等計劃相關的問題時，我們可以透過OUTLINE 繫結的方式，直接線上干預SQL執行計劃，限流與OUTLINE很大提升了我們應急處理的能力。

**其次針對異常流量的預案**，如果這些讀的流量來自應用層，它們非常關鍵不能限流，當面對突發的大流量時，OceanBase 作為一個多副本的資料庫，可以在單個副本流量不足時將讀流量打散到所有的副本上，讓叢集每一臺機器都參與到業務流量處理中，這就是我們內部講的“切弱讀”的方式，它能夠很大緩解異常流量或者是快取失效、雪崩的場景，為業務的穩定性提供有效保障。

螞蟻集團有上萬臺物理機，容器與例項數量更是數以十萬計，在這樣的規模下，在運維中偶然出現的“黑天鵝“事件積累到一定的程度就會變成必然事件：例如某些批次硬體的韌體出現問題對叢集產生影響，或是作業系統中罕見的bug觸發等。螞蟻集團**針對內部的核心叢集還設計了異構FO兜底方案**，應對最極端的故障場景。可以說，OceanBase 從微觀區域性到整體架構上都有相對完備的應急處理方案。

**Q7**

### **這種大促環境下，線上的告警和容災預案您覺得應該如何規劃？**

**惠星星：**

線上告警分為監控與告警兩部分。在監控方面，成熟資料庫廠商有多年的積累與眾多的服務客戶基數，他們的監控軟體能夠很大程度上幫助我們降低成本。除此之外，大家也可以根據自身的業務特性自主編寫一些監控項。在告警方面，一些無效告警會對日常運維工作造成影響，建議可以將告警進行不同的等級劃分，我們再根據不同的告警級別採取對應的應急措施。在業務層面，在最高等級的告警情況下我們可以透過業務層面進行隔離以確保核心業務的穩定。Oracle的容災預案也是比較成熟的，比如兩地三中心方案，在容災預案的建設過程中分為物理級與邏輯層，那我我個人更傾向於物理層這樣保障的預案。

**Q8**

### **關於雙11場景下，OceanBase 如何保證效能和成本的平衡？**

**白超：**

所有的企業在資料庫到了一定的規模之後都會關心如何增效如何降本的問題，螞蟻集團的業務規模較龐大，對應的成本最佳化的挑戰與要求也就越高，針對這個問題，OceanBase 在計算與儲存方面都做了很多的工作。

在**計算層面**，如何提升資源的利用率是一大問題。OceanBase 透過多租戶的模式在大叢集中實現資源的池化，相當於租戶之間的計算資源與儲存資源隔離。

在**儲存層面**，不同於Oracle或MySQL資料庫，刪除了插入的資料無法直接釋放對應磁碟空間，只有在重整表空間或是降低高水位後才能夠回收這一部分空間，而開啟壓縮又會降低效能。

OceanBase 在降低儲存成本方面，第一個層面的設計是透過**對LSM儲存架構的利用**，它的順序儲存特效能夠保證每個資料塊緊湊儲存，每日增量資料在做合併時都會將原來修改的塊重新寫一遍，天然規避了資料空洞的問題。

第二個層面，OceanBase 的**儲存引擎使用了編碼壓縮的技術**，能夠壓縮冗餘的行與列資料。

第三個層面，**LSM Tree架構儲存引擎的增量活躍資料都在記憶體中進行**，導致基線磁碟當中的資料不會被直接更新，因此我們可以在基線資料中使用一些高壓縮的演算法而不影響效能表現。

以上三個層面綜合起來，可以讓我們在儲存10TB的外部資料集檔案時在OceanBase 壓縮到3TB甚至更少。對於外部客戶，比如我們服務的銀行金融客戶，他們之前使用的Oracle例項較少做過高水位線回收或是重整表空間的操作，匯入到 OceanBase 中可能達到近90%的資料壓縮比，儲存成本壓縮能夠很好的量化。除此之外，OceanBase 中只用作事務投票保持資料一致性的日誌副本可以使用更低配置的機器，又能保持叢集的 Paxos 三副本或五副本成員列表的完整性與有效性，這也是降低成本的一個手段。

由於螞蟻集團的基礎設施規模非常龐大，所以我們在技術架構方面做了很多infra底層的工作，比如透過不同的機型，使用容器化結合OB多租戶的機制進行混部，以及使用儲存混部的技術等，從整體上不斷提升資源的利用率。

**Q9**

### **在國產資料庫蓬勃發展的浪潮下，商業資料庫的穩定性和商業價值兩者應該如何平衡？**

**惠星星：**

在我接觸的客戶中，企業的資訊系統按照重要程度劃分為不同的等級。隨著中美貿易戰、俄烏戰爭的影響，可以將自主可控提上日程，比如在業務允許的情況下給國產資料庫提供更多的應用場景與機會，類似於“備胎計劃”，從既不考核也不核心的系統中應用，經過實際業務的打磨最終達到核心系統的國產資料替換。類似於OB這樣成熟的資料庫以及多年來支撐雙11大促的業務打磨，肯定可以支援我們的資訊系統，我們也要以更開放的姿態給國產資料庫提供更多的應用機會，讓我們的業務逐步測試、接納以及應用它，最終依賴它！

**Q10**

### **雙11的容量會是平常的幾十倍，OceanBase 如何實現擴容並且能平滑實現雲端彈性操作？**

**白超：**

雙11資料庫的容量能力要求會成倍提升，在 OceanBase 誕生之前，我們需要歷經幾個月甚至半年做例如拆分擴容、壓測等儲備，不僅會耗費大量的人力，垂直水平拆分等操作也會面臨較大的風險，這些問題都在OceanBase 時代得到了解決，比如在大促前短時間內將某些機房的資料擴充套件到雲機房上，用雲機房的資源應對雙十一的流量，高峰期過後再快速縮容回日常規模。

由於 OceanBase 副本均衡能力對應用是近乎透明的，結合無狀態路由達到對應用近似無感知的狀態。比如從A機房將副本彈性到容量更充裕的B機房中，dba不用關心資料庫的資料複製、一致性校驗等問題，只需要在批次的遷移平臺上觸發任務，遷移完成後，OceanBase 透過前端proxy組建逐漸將新流量路由到遷移彈性之後的節點。整個過程是在後臺進行達到應用無感知的狀態，相比於傳統方案，DBA的幸福感也很大程度的提升。

面對規模化運維的難題，螞蟻的DBA團隊還推出了**規模化變更工具OMP平臺**，真正將螞蟻資料庫批次變更的能力提升到一個新高度。DBA只需要制定一個擴容或者配置變更，或者是彈性策略下發到平臺，OMP會自動灰度向目標機房執行變更。目前螞蟻集團SRE DBA規模不到20個同學，但能夠很好的支撐螞蟻全站所有資料庫運維的操作，包括大促期間的業務保障，都依賴於OB工具化與智慧化。

OceanBase 這樣靈活的彈性擴縮容方案，大促前快速擴容，大促後快速縮容，能夠為中小型企業有效降低成本，減少開支。

【對話ACE】第七期｜雙11，如何保證資料庫穩定可靠？

相關文章