作者：吳其朋，滴滴分佈式存儲運維負責人
滴滴出行（下文簡稱“滴滴”）作為涵蓋#網約車、#出租車、#順風車、#代駕 等業務的一站式多元化出行平台，擁有全球客户6.5億。自2024年應用OceanBase以來，已在多個場景落地並替換RocksDB、TokuDB，包括網約車增長服務、中台核心歸檔庫、代駕核心歸檔庫、EP、無人車服務等。本文以網約車增長服務、歸檔庫等核心業務為例，闡述滴滴的數據庫技術經驗以及新功能實踐。
滴滴出行的數據庫使用場景及技術方案
場景一：核心歸檔庫
滴滴的歸檔庫承載着線上業務的高訪問量，更接近於線上冷庫，而非冷數據歸檔。目前，歸檔庫的最大集羣為100TB，QPS（每秒查詢率）最高峯值達到八千（8000/s）。由於持續且高頻訪問的業務特徵，傳統的分表模式難以滿足快速擴容需求，因此我們認為，將核心歸檔庫遷移至OceanBase成為關鍵路徑。
現狀：使用大磁盤機型降低成本
得益於OceanBase先進的高壓縮比與原生分佈式架構，在100+TB數據量的歸檔場景中，相較於TokuDB分庫分表架構，存儲成本降低20%。另外，由於OceanBase可以使用更大磁盤的機型，進一步為我們節省了業務成本。
這裏涉及一個問題：為什麼TokuDB不能使用大磁盤機器呢？ 原因有二：
- 一是若TokuDB使用大磁盤的機器，它的實例就大，會導致備份與拆分的時間過長，進而影響服務可用性；
- 二是如果大磁盤機器部署過多的Toku小實例，一旦出現單機故障，影響範圍擴大的風險是成倍的。
相較之下，OceanBase依賴於Unit拆分的快速擴容模式，能夠在分鐘級完成節點的擴散、小時級實現Unit的拆分。這不僅極大提升了運維效率，也增加了服務的穩定性。
那麼，我們在使用大磁盤機器時，如何選擇合適的規格？
評估使用多大磁盤的機型，以單機故障恢復時長為依據，其中磁盤性能和網絡帶寬的差異都是影響恢復時間的相關指標，所以具體使用多大磁盤機型還需因地制宜。
舉個例子：以MySQL 3TB服務恢復時長為基準，在進行備份故障恢復時，大約需要 7~ 8 個小時。而選用OceanBase大磁盤機器時，就可以根據7~8小時的標準來制定大磁盤機器容量。
挑戰：百TB數據遷移延時高
由於歸檔庫數據量大，業務側擔心從TokuDB遷移至OceanBase會存在穩定性風險，包括性能、數據一致性校驗、遷移效率，因此我們進行了針對性的測試和驗證。
首先，在性能方面，為了確保響應延遲可控，我們進行了灰度測試，從上游歸檔庫的幾千張表中，對每張表選取一小部分數據進行數據遷移，速度快、成本低。但當業務側進行流量測試時，延時上漲了十幾倍甚至幾十倍。我們根據SQL分析發現，當面對幾千張表，SQL第一次訪問都會執行硬解析模式。那麼，如何避免這種情況？經過和業務側溝通，我們的策略是將上游的數千張表合併為下游的幾張表，業務側只需簡單修改後綴就能夠有效減少硬解析的次數。大大減少業務響應延遲，99分位保持在十幾毫秒以內。
其次，遷移效率與數據一致性校驗相關。我們以5TB數據測試遷移為參考值，判斷業務整體遷移節奏。但在遷移過程中發現，數據校驗非常耗時，幾TB的數據校驗長達幾天，極大地影響了遷移效率。隨後在OceanBase社區的幫助下，我們通過升級OMS並使用OMS數據校驗過濾表字段的功能解決了該問題。其本質是過濾大字段，而這些大字段通常都是非核心場景，對業務沒有影響，卻可以將數據校驗時長從天級別降低到小時級別。
還有一個小技巧，在OMS進行數據的全量與增量遷移過程中，多使用OMS Diagnose功能。該功能可以根據當前的遷移速度發掘遷移瓶頸，並依據系統承載能力給出合理的遷移方案，比如修改下游的併發數、提高上游的併發數，進而提升遷移效率。
場景二：網約車增長服務
現狀：百億數據高效率運行
網約車增長業務即俗稱的特徵庫。特徵庫的特點是表級別映射到業務線，導致其單表字段非常多，數據達百億。而且，因為單行寬度大，並且伴有特定範圍的數據查詢，線上QPS最高為2.5w/s。由於業務側依賴特徵庫進行數據聚合與數據分析，要求特徵庫的響應延遲控制在80ms內,因此，單SQL執行超過200ms時，業務會進行熔斷重試，以免出現故障進而造成更大的負面影響。
起初，我們計劃使用MySQL分庫分表支撐特徵庫的業務需求，不過，最終沒有落地。這是因為：
- 上文提到該業務伴有不同維度的範圍查詢，所以我們無法對單表進行拆分；
- 特徵庫單行過大，MySQL的性能不足，驗證不通過。
目前，特徵庫在OceanBase運行情況如下：
- OceanBase的日常響應延遲在30ms左右，滿足業務訴求。
- 秒級DDL可以滿足業務快速迭代的需求，極大地提升了業務的迭代效率。如果我們使用MySQL copy的方式，一個單表需要幾天才完成。
- OceanBase的分區表和全局索引功能非常好用，可以根據字段進行分區，增加單表的併發度，提高百億大表的訪問效率；全局索引可以在單表上滿足業務不同維度的範圍查詢，比如按司機查詢、按訂單查詢等。不僅查詢效率高，還降低了運維複雜度。
挑戰：高併發業務場景
特徵庫上游對接的業務線比較廣，各業務線會依賴它進行數據聚合+數據分析。當上遊業務線有一個分析需求時，特徵服務會對該需求進行模型拆分。例如，上游的一個查詢會被特徵服務拆成多個SQL併發訪問OceanBase，如此一來，處在下游的OceanBase其實是流量放大的。並且業務存在超200ms的熔斷重試機制，以滿足對上游的SLA保障。
然而在這樣的高壓場景中，風險是時時存在的，比如：
- 業務流量突增或波動，可能導致重試風暴，影響系統穩定性。
- 如何合理設定限流閾值，與系統在高併發時穩定運行息息相關。
- 根據 OCP SQL 診斷觀察，業務 SQL 模板高達幾千個，可能導致限流失效。
面對上述挑戰，我們採取了針對性措施。
1.業務重試邏輯修改。
我們的做法是，和業務側溝通，將重試機制調整為階梯式，從固定的200ms重試，設置為漸進的200ms、400ms、800ms。
舉個例子，假設一個SQL執行的正常時間是100ms，當它超時達到200ms，那一定是某個環節出現了問題：網絡問題、單機故障或其他問題。此時如果還在不斷進行200ms的重試其意義不大，只會給數據庫增加額外的壓力。反而，階梯式的重試能夠減少重試風暴帶來的壓迫感。
2.限流閾值實施。
解析業務高峯期 SQL audit，獲取併發度，設置合理閾值。同時也能發現那些超高併發 SQL，提前防患。
對於高併發業務線的SQL進行限流，多少閾值合適？
“拍腦袋”式的設置5或10，是沒有根據的。我們可以通過解析業務高峯期 SQL audit，獲取併發度。比如以30ms為區間，這是因為業務的日均響應延遲為30ms，就可以判斷該區間內單個SQL模板有多少併發。我們選擇以90%以上併發度的基準對業務進行限流。超過90%的併發度的SQL則通知業務側調整，降低其併發。
3.海量 SQL 優化。
開啓限流後，我們發現了一個問題：限流的模板達到上千個，影響限流效率。我們根據SQL分析，這些被限流的模板都有一個共同點，它們的訪問條件一致、訪問的數據一致，只是語法的順序顛倒而已。對於OceanBase的SQL限流來説，過多的SQL模板可能會導致限流失效。因此，我們通知業務側修改邏輯，將SQL模板從數千個縮減為100個以內，大大降低了限流失效的風險。
4.嘗試OceanBase4.3.5 bp3版本。
前面提到SQL模板級別的限流方案，其實只能防止服務因為某幾個問題SQL(慢查詢、流量突增等)，導致線程被大量佔用，最後造成整體服務不可用的情況。
舉個例子：我們有一個10C 50G UNIT租户，最大單機併發數可以達到40。當一個SQL的併發數限制為10時，最多能防止3條以內的問題SQL。當超過3條SQL時，線程依舊會被佔滿，仍舊無法保證整個服務可用性。
OceanBase4.3.5全新版本可以完美的支持庫、表級別限流。這樣我們就可以設置多層限流規則，以有效避免SQL級、表級出現問題，導致整個服務不可用的情況。
數據庫運維體系建設及實踐
1.監控告警定製化
其一，基於機型的閾值告警。在一個OCP管理多套OceanBase集羣的情況下，集羣中可能包含了歸檔庫或流量較高的高併發庫。對此，滴滴的策略是：在歸檔庫中使用計算資源少的大磁盤存儲；在特徵庫中使用計算資源較多的機型。
而這會面臨一個問題：若兩個業務的告警配置一致，會造成大磁盤機型的資源浪費。因此，我們需要根據不同的機型配置不同的告警，以實現資源的最大化利用。此外，在機型置換的過程中，也需要根據機型定製告警策略。
我們根據不同的物理機配置設置ob_server_sstable_percent_over_threshold 告警閾值，避免統一標準導致的誤報或漏報。例如大容量歸檔機型允許更高的 SSTable 佔比，而高併發特徵庫機型則設定更嚴格閾值，確保集羣穩定性。
其二，ZONE級交換機隔離告警。OceanBase是基於Paxos協議實現了多副本容災。當多數派出現故障時會導致業務的部分數據或整套集羣不可用。因此，我們針對不同ZONE內部署在相同 TOR 下的 UNIT，建立網絡拓撲告警機制。避免單一交換機故障引發部分業務數據失效的情況。此告警已經成為核心高優先級項，必須第一時間響應處置。
2.上線Binlog Server 4.x 高可用版本
在滴滴業務鏈路中，無論是SQL還是OceanBase，都需要把上游數據同步到下游的MQ或Kafka，以提供給不同的業務線或者業務場景進行使用分析，所以導致binlog同步鏈路對於某些業務來説是強依賴的。
在上線Binlog Server高可用版的過程中，我們驗證了其語法兼容、高可用性、數據一致性，均符合預期。不過在進行多次高可用切換時，會把所有的實例切換到一台機器上，雖然不影響高可用的鏈路，但可能會造成資源的不均衡，希望後續版本能夠改善。
3.SOP與防火演練
SOP是一個慢慢疊加、累積的過程，需經過故障的洗禮，以及在OceanBase官方人員的耐心指導下，增長運維經驗，進而沉澱為SOP。帶來的益處也是顯而易見的：不僅提升工作的一致性、效率和準確性，還為團隊運維提供了重要支撐。但是，僅有SOP不足以應對生產環境中的風險，還需要通過防火演練驗證SOP的可用性。二者相輔相成，不斷提高組織在面對各種緊急情況時的整體應急能力。
4.成立運維小組
你可能會質疑，有必要成立專門的運維小組嗎？
成立運維小組的意義在於：
- 避免單點風險。除了24小時告警外，當我們面臨重大故障時，希望能夠分工合作，快速止損。
- 幫助團隊增加技術儲備，更好地提供業務服務。
- 羣策羣力，助力 OceanBase 在滴滴的發展中走得更遠，飛得更高。
在小組中，我們會做幾件事：
- 定期組織架構解析會，比如內核技術解析、源碼解析、技術方案分享。
- 建立知識傳承機制，比如整理方案、故障覆盤，讓組內同學融入運維體系，快速成長。
- 線上故障模擬訓練。藉助SOP模擬線上環境的運維操作，不斷進行防火演練，才能在遇到故障的時候處事不慌，井井有條的解決故障。
- 參與重大變更實施。
尾聲：對數據庫的期待
在使用OceanBase的過程中，我們有兩個非常直觀的感受。
- OCP白屏化工具，大大降低了運維難度，讓從前複雜的操作變得簡單、便捷。即使在管理上百台物理機時，也能做到遊刃有餘。並且通過OCP接口，還可以快速實現一些定製化功能。
- Oceanbase數據庫可以滿足多維度的業務需求，使業務側得到了“既要又要”。
但數據庫升級方面，我們仍有期待。目前OceanBase基於OB Server滾動升級，並且無法長期保持每個OB Server版本不一致的情況，無法滿足我們對於重大操作的灰度運維標準。當然也可以依託主備庫或OMS同步鏈路的方式進行升級，這種方式雖然穩健，但如果一個集羣涉及上百台機器，會有較大的資源浪費。
因此，希望OceanBase不僅提供小流量灰度升級，還能支持回滾操作，便於用户在升級數據庫時萬一遇到線上業務不匹配或其它未知問題時，實施相應的止損手段。
