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

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

自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录入测试数据，参数：

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

复制代码

产品写入完成时5小时后24小时后稳定后数据某同类型数据库v8.1.151.3G51.3G51.3G51.3GOceanBase v4.2.5104.59G77.46G37.34G37.34G三、应用场景的技术实践
（一）从分库分表到OceanBase的迁移经验

目前，网易个人邮箱已在多个业务中试点OceanBase，在迁移过程中，我们总结了几点经验供参考。
1.分布式环境下唯一键约束的迁移治理。
背景： 在基于MySQL的分库分表架构中，由于历史多次迁移扩容，部分表存在跨MySQL实例的重复主键数据（如pid=1同时存在于不同实例）。数据接口的路由机制仅访问Hash匹配实例，导致重复数据长期隐匿，但迁移至OceanBase时触发唯一键冲突。
解决方案： 首先在迁移前执行分布式重复扫描：

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

来源：豆瓜网用户自行投稿发布，如果侵权，请联系站长删除