『OceanBase』周贵卿：OceanBase Cloud助力企业降本增效

近年来，企业数字化变革的深入和智能制造、智慧城市、元宇宙等新兴产业的兴起，对云计算提出了更高的需求，传统云计算难以满足新兴场景的算力需求，整合资源、统一调度、一致服务的分布式云计算正在被越来越多的企业所接受，分布式云计算头部企业已在实践领域取得建树，为中国分布式云计算发展积累了宝贵的前期经验。

一直以来，全球分布式云大会作为中国的倡导者，致力于为中国分布式云计算的发展提供最优秀的技术和商业交流平台。本次全球分布式云大会，全球分布式云联盟携手阿里云、腾讯云、火山引擎、PPIO边缘云、亚马逊云科技等分布式云计算头部企业，展示分布式云计算阶段性发展成果，进一步普及和推广分布式云计算的商业应用！

在8月26日下午举办的【数据库专题论坛】上，OceanBase 解决方案架构师 周贵卿发表了题为《云上分布式数据库应用最佳实践》的精彩演讲，详细内容如下。

互联网的早期技术架构是单体架构，ALL IN ONE应用+数据库的模式就可以承载业务需求，当时的淘宝也是从“PHP+MySQL”的模式开始演进的。随着业务的增长，单体架构已经无法承载业务的容量，于是开始对架构进行模块拆分，出现了一些垂直架构。

2000年左右，互联网的井喷式增长，分布式架构初现雏形，研发人员会用到如Nginx、SLB等负载均衡框架，将后端的复杂应用屏蔽；此时如果对后端应用实例进行增减，整个业务都是无感知的，这就是Spring Cloud的架构。本质上，微服务架构是分布式架构，解决的是分而治之的问题，而加入一些分布式中间件，如zookeeper、ETCD，或基于PAXOS、Raft、Zab等协议，解决全局业务的协调一致性。

伴随互联网技术架构的发展，底层的数据库从单体数据库+高可用主从，到不同业务使用独立的数据库，再到分布式数据库。而随着业务体量的不断增长，单个数据库无法满足需求，基础组件会外挂很多中间件，如Sharding分库分表、zookeeper等分布式一致性组件，数据库架构是异构的，不止有分库分表，部分数据库依然是主从，对业务架构提出了很多挑战。

当前数据库架构——技术挑战

当前数据库架构基本上是MySQL一主多从架构，业务写入只能写到Master，在业务爆发式增长下，写入量激增MySQL单Master会成为瓶颈；日常备库资源水位偏低，当从库的存储已经达到90%+，但资源（CPU）利用率只有5%-10%。

读写分离架构是逻辑复制，由于业务量激增写入量变大，逻辑复制的性能消耗，加上多活、跨机房等原因，会出现binlog主从延迟，新写入的数据无法及时的被读取出来，导致业务受到影响。

在高可用架构上，MySQL主库Down机，HA架构存在数据丢失风险，且需要 DBA手工做主从切换，业务连续性无法保障。

Sharding分库，本质是由多个数据库组成，存在中间件瓶颈问题，跨库事务、一致性、关联查询等问题。

用户选择适应应用的数据库架构，就等于同时对运维提出了相应的要求，随着业务量的快速增长，也面临着规模化运维的问题。

DBA在日常运维时，磁盘或服务器的故障是小概率事件，但规模化运维时，故障就可能每天都在发生，导致DBA的工作变得碎片化，充满着性能调优、故障处理、宕机恢复等工作，影响业务正常开展。

通常来说，当故障发生时，DBA应当是企业数据库稳定性的最后一道保障，但他的日常工作过于琐碎，也缺乏良好的工具支撑，企业全局的业务连续性存在非常大的隐患。

数据库架构演进

数据库的架构演进，单机架构已经都到瓶颈，无法满足大多数业务应用的诉求；当前绝大数企业采用的是分库分表架构，架构理念采用的是PG数据库的PG XC架构，将分库分表、分布式一致性等中间件下移到数据库能力上，但依然是一套外挂架构，面对偏分析的场景可能会导致事倍功半；随着谷歌Spanner的发布，数据库进入分布式时代，并且Spanner实现了全球一致性。

蚂蚁集团从2010年开始探索原生分布式数据库领域；2014年的去IOE过程中，支付宝业务迁移到OceanBase，至今已有八年，扛过了一次又一次双十一“洪峰”，峰值一度高达6100万次/秒，同时也经过了大量金融场景的考验。到目前，OceanBase已经100%成为蚂蚁集团的数据库底座，总规模达到数百万量级。

下一代数据库架构——OceanBase

OceanBase的主要特性有以下几点：

1 多云架构

·支持多云部署，裸金属/公有云/私有云均支持部署

·不依赖专有硬件，基于普通X86/ARM提供金融级别高可用

2 原生分布式 多副本强一致性

·数据自动分布对应用透明，无需中间件分库分表

·全对等节点，读写多活

·多副本，Paxos协议副本间强一致性

3 极致水平扩展 线性高性能

·集群在线横向扩容/缩容，不停服务

·性能线性扩展，单集群超过 1000 台服务器，单库数据量超过2PB，峰值处理6100万次/秒

4 多租户模式

·支持多运行模式， 高度兼容Oracle/MySQL数据类型、对象、函数、SQL语法、过程语言

·单一OceanBase 集群灵活支持多个Oracle/MySQL租户

·租户间资源隔离，且可以在线动态调整

5 平滑高可用 容灾切换

·表/表分区级的高可用，自动故障/灾难切换

·少数副本故障，RPO=0（不丢数），RTO<30s（自动内部平滑切换）

核心优势 1：极致水平可扩展

在线扩容（应用无感知），面对洪峰场景，在线扩容增加每个高可用域（Zone）的OceanBase 节点的数量，数据库租户也增加资源单元，系统自动将表/表分区的各个副本重均衡分布到新增加的OceanBase 节点，采用物理拷贝，每节点性能>500MB/s，无需重新 Hash 每条记录，同时，应用无感知，无需像分库分表那样对应用配合大量改造。该方法同样支持在线缩容的操作。

核心优势 2：平滑高可用/容灾切换

OceanBase内部自动切换、无需人工干预和复杂决策流程，基于Paxos协议的典型多副本(三副本或以上)部署，能够实现数据强一致性、持续可用，主备自动切换，对上层业务透明。一旦发生单机、机房、城市级故障，OceanBase 内部自动故障切换，不影响服务（RTO < 30s），不丢任何数据（RPO = 0）。

核心优势3：计算资源整合和存储成本下降

一方面，OceanBase 通过DBaaS能力，多租户隔离，例如在一主两从架构下，通过多租户能力，主可用区提供写入，下一位租户就可以置入下一个可用区，让机器资源充分利用，按需分配调整资源（快速升降配），读写能力都可以放在从节点上。

另一方面，OceanBase自主研发的存储引擎，通过数据编码机制以lsm存储架构，无性能损耗，存储成本至少省 80% 以上。

从金融走向千行百业、走向全球

2020年，OceanBase开启商业化进程，两年来，积累了400多家客户，不仅是金融场景，在运营商、石油化工、电力、旅游出行等千行百业均有应用，同时也在海外市场取得了优异的成绩。

OceanBase Cloud整体架构

显性成本之外，运维是数据库使用过程中的隐性成本，没有良好的工具支撑，就会变向增加运维的成本。OceanBase Cloud中，集成了一系列完善的工具，将蚂蚁集团多年的运维经验积累的能力赋能给用户。

案例：助力携程旅行实现高质量客服业务服务质量

在该案例中，携程客服大规模的业务流量，数据存储达到MySQL存储极限，只能保证两个月数据的存储；MySQL主备架构，无法通过横向扩容扩展存储性能；采用MySQL机房间主备方案，在机房故障条件下无法保证数据强一致和快速业务恢复能力。

针对上述痛点，OceanBase都一一予以解决。

针对存储极限问题，OceanBase替换MySQL，获得接近85%的数据压缩能力，同样的存储配置情况下即可获得存储一年数据的业务价值。

针对扩容问题，采用OceanBase提供的横向扩容能力，通过OCP一键式白屏操作，加减机器即可应对业务的扩所容，保证业务的服务质量。

针对高可用问题，基于OceanBase多副本一致性保证，保证RPO=0 ，RTO<3分钟。

整个迁移过程非常平滑，OMS数据迁移和同步能力，保证了数据库切换过程的平滑稳定。迁移后，携程在同等硬件投入前提下获得超过一年的数据存储能力，满足业务需求；自动的故障切换，提高针对机房，机器故障的快速恢复能力，保证SLA；同等应将投入前提下，通过技术升级，得到强数据一致性保证，降低数据丢失风险。