作者： 佐菲，網易個人郵箱數據庫負責人；長樂，網易個人郵箱服務端資深研發

前言

自1997年誕生至今，網易個人郵箱已在互聯網的浪潮中走過了二十餘載，憑藉着卓越的服務與技術實力，發展成為國內乃至全球極具影響力的郵箱品牌。網易旗下擁有六個獨具特色的郵箱域，分別為163、126、yeah、vip163、vip126和vip188，每個郵箱域都精準定位不同的用户羣體，滿足多樣化的需求。

經過多年的積累與拓展，網易個人郵箱積累了龐大的用户量，用户遍佈全球各個角落。其業務場景豐富且複雜，涵蓋了個人日常通信、商務往來、營銷推廣、信息通知等諸多領域。在如此龐大且複雜的業務體系下，對數據庫的性能、穩定性、擴展性等方面都提出了極高的要求。本文分享網易個人郵箱數據庫方案從分庫分表數據庫和MySQL升級到OceanBase的解決思路與技術實踐經驗。

一、數據系統現狀

上文提到網易個人郵箱包括163，126，yeah，vip163，vip126，vip188六個核心郵箱域，各域均構建了獨立的數據系統，支撐郵件收發，用户管理等OLTP業務及日誌分析，流量統計等 OLAP 場景。在多年高速發展過程中，數據規模持續增長，為充分挖掘技術演進潛力、構建更高效的數據架構，我們積極探索分佈式數據庫的創新實踐。原有系統在以下方面存在優化空間。

1. 存儲資源效率提升需求。

隨着業務數據規模突破 TB 級並保持高速增長，傳統數據庫在存儲資源優化上面臨新挑戰。尤其在實現高可用架構（如主從複製）時，資源複用能力需進一步增強。

2. 全局資源動態調度能力構建。

各郵箱域業務特性差異顯著，資源分配需兼顧安全隔離與彈性調度。如何實現跨域資源靈活調配，提升整體資源池利用率，成為架構升級的重要方向。

3. 水平擴展能力升級。

傳統架構在應對數據量激增時，單機垂直擴容效率面臨瓶頸。TB級庫表遷移需要較長時間窗口，亟需更敏捷的擴縮容機制保障業務連續性。

4. 高可用與容災自動化演進。

為滿足更高等級的系統可靠性要求，需構建秒級故障切換能力，並消除主從資源差異導致的切換風險。拓撲自動發現與連接無縫遷移能力也成為架構演進的關鍵目標

5. 實時分析能力建設。

當前數據分析鏈路存在時效性分層現象，部分場景需依賴 T+1 數據同步。構建業務庫與分析庫的實時數據通道，對提升決策敏捷性至關重要。

6. 運維自動化升級。

面對億級數據表的元數據變更需求，需突破 DDL 操作效率瓶頸。同時，多版本數據庫的統一管理、自動化變更流程的建設，對提升運維敏捷性具有重要意義。

二、引入 OceanBase 的原因與對比分析

（一）網易個人郵箱選型需求的調研分析

在調研選型階段，我們分析了 OceanBase 和 某同類型數據庫兩款分佈式數據庫解決方案，並根據網易個人郵箱的業務特點評估其在多個關鍵特性上的表現。最終選擇 OceanBase 作為數據庫升級的主要解決方案，以下是結合業務實際需求分析其符合選型預期的原因。

1. 數據可靠性與高可用設計。

• 數據強一致：OceanBase 基於分佈式共識協議（如 Paxos），確保多副本數據的一致性，可有效解決傳統數據庫主從同步中的潛在不一致問題，對於需要高可靠性和金融級數據安全的場景，符合需求。
• 智能容災：OceanBase 提供自動故障切換機制，在單點故障場景下能夠保障業務持續可用，這對支撐網易郵箱複雜、高併發的業務場景具有重要意義。

2. 多租户資源隔離能力。

• 資源精細管控：OceanBase 支持 CPU、內存和 I/O 的租户級別資源隔離，符合多業務域安全性和獨立性要求。
• 彈性資源調度：根據業務負載動態調整資源分配，提升資源利用率並保障系統穩定性，尤其適用於郵箱業務流量週期性波動的場景。

3. 數據存儲效率優化。

• 智能壓縮引擎：OceanBase 的存儲結構設計顯著降低了數據存儲空間佔用。實測結果顯示壓縮效率優於傳統架構，在 TB 級數據規模下有效減少存儲資源投入。
• 降本增效：通過壓縮技術和存儲結構優化，OceanBase 有效緩解業務數據規模增長導致的資源成本壓力。

4.擴展性與彈性設計。

• 在線無感擴縮容：OceanBase 支持節點的增減與數據均衡過程完全在線化，能夠保障遷移操作對業務透明化，減少擴展過程中可能的停機風險。
• 自動負載均衡：業務擴容後，數據流量可以智能分佈到新增節點，確保服務質量和業務連續性。

5. 一體化智能運維平台。

• 開箱即用的管理能力：OceanBase 提供全鏈路集羣管理平台（OCP），支持監控告警、備份恢復和部署管理的可視化操作。
• 運維範式升級：運維過程中複雜的人工操作可實現標準化管理，有助於提升網易郵箱在多業務場景下的維護效率。

6. 完整的MySQL生態兼容。

• 業務遷移成本低：OceanBase 兼容 MySQL 協議及語法，網易郵箱業務無需進行大規模應用改造即可完成平滑遷移。
• 生態無縫集成：原生支持 MySQL 生態工具鏈（如 Flink CDC），便於原有的工具鏈在新平台的無縫運行，從而提升分析鏈路的連通性和時效性。

7. 技術生態與服務支持。

• 活躍的技術生態：OceanBase 擁有由企業和開源社區共同推動的快速迭代能力，可持續增強其關鍵技術功能，確保長期的技術支持。
• 服務保障：開源社區響應與企業級服務結合，為關鍵業務提供了更全面的支持。

（二）Sysbench測試與兩款數據庫產品對比

為進一步驗證數據庫解決方案在網易個人郵箱場景中的適用性，我們分別針對 OceanBase 和 某同類型數據庫的不同版本進行了性能測試，並結合行業內其他數據庫產品進行對比分析。部分測試結論如下：

• 測試結果顯示，在純插入和純查詢場景下，OceanBase v4.3 的性能表現優於其他測試方案，適用於 AP 業務。在綜合增刪改操作場景中，OceanBase v4.2.5 的性能表現更為突出，適用於 TP 業務。
• 在多租户場景下，通過測試驗證了 OceanBase 在資源隔離能力方面的表現。在高併發寫入時，我們觀察到磁盤 IOPS 的限制與性能波動之間的相關性。
• 測試結果表明，OceanBase 在數據壓縮能力上具有顯著優勢。

具體測試過程及環境配置如下文所述。

1.性能對比。

我們選擇對比某同類型數據庫v8.1、OceanBase v4.3、OceanBase v4.2.5，測試環境配置3個48核384G的SSD，對比二者在select、insert、update index、update non index的性能表現。

• select：兩款數據庫峯值均出現在1200~1500線程範圍內，對比QPS和TPS，OceanBase v4.3是OceanBase v4.2.5的1.3倍；是某同類型數據庫v8.1的 1.7~1.9 倍
• insert：OceanBase峯值出現在 1800 線程，某同類型數據庫峯值出現在 1200 線程。對比OPS和TPS， OceanBase v4.3是OceanBase v4.2.5的1.3倍；是 某同類型數據庫v8.1的2.27 倍。
• update index：兩款數據庫峯值均出現在 2100 線程，對比索引字段更新下的QPS/TPS，OceanBase v4.2.5是 某同類型數據庫v8.1的2.7倍；是OceanBase v4.3的3倍。
• update non index：兩款數據庫峯值均出現在 2100 線程，對比非索引更新QPS/TPS， OceanBase v4.2.5是某同類型數據庫v8.1的1.66倍；是OceanBase v4.3的3.04倍。

2.資源隔離能力。

為了評估OceanBase在多租户場景下的資源隔離效果，避免租户間互相干擾，我們進行了關鍵對比測試。

首先，單雙租户壓測對比如下。

• 測試設計：同一集羣中，先後進行兩次同等條件的性能壓測：

  • 場景A：單一租户（配置：12核40GB）
  • 場景B：兩個租户（各配置：12核40GB）
• 驗證目標：觀察雙租户壓測時，單個租户性能是否因資源競爭而顯著低於單租户場景，從而判斷資源隔離有效性。
• 結論：對比結果顯示，在相同資源配置下，單個租户的壓測性能在多租户並行運行時未出現明顯下降。這證明了OceanBase對計算與內存資源的有效隔離能力。

其次，集羣資源極限分配壓測如下。

• 測試設計：將3節點集羣的資源全部分配給3個業務租户。同時對這些租户施加不同線程數（24~2400+）的多場景混合讀寫壓力。

• 驗證目標：

  • 探測租户在資源極限分配下的性能邊界（QPS/TPS）及資源使用飽和度。
  • 評估高負載下OBProxy的穩定性。
  • 監控系統租户（sys） 在高負載下的受影響情況。

• 結論：

  • 租户性能飽和。所有租户的QPS/TPS在併發線程數達到1500~2400區間後趨於穩定，表明達到性能峯值。繼續提升併發則導致延遲上升，資源已被充分利用。
  • OBProxy穩定。OBProxy CPU使用率隨壓力提升平滑增長（峯值約75%），內存佔用啓動後即到高位並保持平穩，未見異常。
  • sys租户無干擾。系統租户（sys）的CPU和內存資源使用率在全局高壓下保持穩定，未出現明顯波動，證明了關鍵系統服務的隔離保障。

3.數據壓縮能力。

同樣對比OceanBase與某同類型數據庫這兩款數據庫。使用Sysbench錄入測試數據，參數：

--time=60 --threads=16 --report-interval=10 --db-driver=mysql --rand-type=uniform --tables=16  --table-size=10000000 oltp_common  prepare

三、應用場景的技術實踐

（一）從分庫分表到OceanBase的遷移經驗

目前，網易個人郵箱已在多個業務中試點OceanBase，在遷移過程中，我們總結了幾點經驗供參考。

1.分佈式環境下唯一鍵約束的遷移治理。

背景： 在基於MySQL的分庫分表架構中，由於歷史多次遷移擴容，部分表存在跨MySQL實例的重複主鍵數據（如pid=1同時存在於不同實例）。數據接口的路由機制僅訪問Hash匹配實例，導致重複數據長期隱匿，但遷移至OceanBase時觸發唯一鍵衝突。

解決方案： 首先在遷移前執行分佈式重複掃描：

SELECT pk FROM tb GROUP BY pk HAVING COUNT(*) > 1;

其次，依據業務規則修復數據：

• 保留最新版本數據；
• 對無效冗餘數據執行安全刪除；
• 特殊場景改造主鍵結構（如增加業務前綴）。

成效： 保障OceanBase強約束環境平穩遷移，奠定數據質量基石。

2.多語言字符集兼容性實踐。

背景： 網易個人郵箱的用户遍佈全球，存儲數據的文字語言多樣，部分比較老舊的程序依舊使用GBK，其字符集僅支持中、日、韓等有限語種，舊業務系統採用GBK字符集處理郵件地址，存儲泰文等非GBK字符集字符時，使用MySQL 5.7會靜默截斷至首字節有效字符，導致數據丟失。

而使用OceanBase時，嚴格執行字符集規範，卻拋出錯誤。

解決方案： 應用層對不兼容的文字進行轉碼；統一升級為UTF-8字符集存儲。成效： 消除雙寫系統字符集兼容風險，支持全球郵箱地址規範存儲。

3.海量表分區與索引優化策略。

在遷移數據量較大且讀寫大的表時，我們會考慮將其改為分區表，合理規劃分區和索引能發揮數據庫的最大性能。

我們在規劃分區時，會盡量讓高頻sql走分區鍵，而部分無法走分區鍵的sql則選擇加上索引。OceanBase的分區索引也分為局部索引和全局索引，根據網易其他同事的壓測結果發現全局索引會導致寫操作性能下降，最大QPS會降低約20~50%。因此，一般情況下對全局索引儘可能不用或者少用。

（二）OBKV落地實踐及注意事項

在KV存儲場景，網易個人郵箱主要使用Redis，對於一些冷數據也會採用Tendis和Pika進行存儲。我們計劃探索將 OBKV-Redis 作為持久化緩存數據庫的備選方案，以滿足業務對數據存儲的高壓縮和高可用需求，原因是：

• 兼容Redis協議。支持大部分業務Redis命令（cluster模式暫未支持）。
• 可有效釋放磁盤存儲空間。OBKV-Redis底層存儲架構壓縮能力較強，能夠釋放磁盤存儲空間，節省很多內存資源。
• 高可用。業務的連接方式和Redis單節點一致，且OBKV-Redis底層已經做好多副本容災。
• 一體化運維。由OceanBase的運維平台OCP進行統一管理。

目前，OBKV-Redis已經在一個業務中穩定運行了一段時間，數量達百億個key，整體延遲不超過 10ms，在業務高峯期 QPS 達到 2w 時實際業務延遲仍舊保持在 10ms 以下。

待改進兩部分：其一根據我們的觀察，OBKV-Redis並不會對所有Redis命令都兼容，特別是遍歷類的基本不支持（如key、scan)，部分支持的命令可能會有問題，如執行monitor時可能會出現中斷。上線業務前需要進行嚴格測試；其二，OBKV-Redis的監控依賴於OCP平台。因為OCP正處於快速迭代階段，對QPS命令的監控支持只包含主要的set、get……如果業務執行setex則無法監控到。

此外，當業務寫入string類型key時，錶行數跟key數量一一對應，而當寫入hash key時，會發現佔用的空間非常高，並且在OCP平台顯示統計的錶行數超出了key的數量。

通過MySQL連接進入查看錶數據時會發現hash key會將key放大，key名會填充到固定長度的字符串，並且每個field佔用一行。進而在OCP平台最終顯示的數據是將以上key統計成2行，因此，key數量不能完全參考OCP的表統計。

基於上述經驗，我們認為OBKV-Redis處於高速迭代階段，將其應用於線上業務前應該對每個操作進行充分的測試驗證。

四、數據庫升級效果：穩定可靠，降本增效

本次數據庫升級後，網易個人郵箱解決了傳統架構中的部分問題，同時在性能優化、成本控制和數據可靠性方面取得了相應的成效。

其一，性能與穩定性突破瓶頸。通過OceanBase的單機分佈式一體化架構，在高併發場景下QPS顯著超越單實例MySQL。吞吐量大幅提升，且連續多月運行無抖動。

其二，存儲成本優化。OceanBase 基於 LSM-Tree 的存儲架構，通過壓縮技術有效降低了數據存儲空間需求。實際業務中，原MySQL主從兩副本3.2T數據遷移至OceanBase三副本後，總存儲空間降至900G，存儲成本節省72%，單副本壓縮能力高達80%。

其三，實時數據處理革新。基於OceanBase對MySQL生態的完整兼容性，數據分析體系實現從T+1到實時集成的跨越式升級。配合4.3.5版本原生HTAP特性，分析型負載在執行復雜查詢時可複用OLTP數據副本，在保證事務處理性能的同時，將分析時效性壓縮至亞秒級。

其四，數據可靠性升級。通過多副本強一致性機制消除主從架構數據不一致風險。故障轉移與快速恢復能力，保障服務連續性，較傳統架構容災能力實現質的飛躍。

其五，實現智能化運維。OCP平台支持租户資源動態調整和在線擴縮容能力，配合全鏈路追蹤、診斷等能力，運維敏捷性顯著提升。

通過數據庫升級實踐，網易個人郵箱在系統性能優化和業務能力提升方面取得了初步成效。後續將繼續探索更多技術方向，包括向量索引和全文索引的應用，並嘗試在部分分析處理（AP）類業務場景中進行落地，以進一步推動業務發展。

最後為大家推薦這個 OceanBase 開源負責人老紀的公眾號「老紀的技術嘮嗑局」，會持續更新和 #數據庫、#AI、#技術架構 相關的各種技術內容。歡迎感興趣的朋友們關注！

「老紀的技術嘮嗑局」不僅希望能持續給大家帶來有價值的技術分享，也希望能和大家一起為開源社區貢獻一份力量。如果你對 OceanBase 開源社區認可，點亮一顆小星星✨吧！你的每一個Star，都是我們努力的動力。