网易个人邮箱数据库升级：可靠性与稳定性双突破

作者： 佐菲，网易个人邮箱数据库负责人；长乐，网易个人邮箱服务端资深研发

前言

自 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，都是我们努力的动力。