深入浅出 ODP（一）：功能模块及特性详解

作者简介：致新，OceanBase 高级研发工程师。

引言

ODP，全称为 OceanBase Database Proxy，它是 OceanBase 数据库专用的服务代理。可能暂时你对它还没有感知，但当你涉及到一些高级特性和 OceanBase 数据库的分布式架构问题时，ODP 的原理就是一个避不开的话题。如果你想了解 OceanBase 的整体架构，如果你想进阶成为高级 DBA，那么 ODP 专题就非常适合你。

ODP 专题主要有九篇内容：

现在，我们将开启 ODP 的专题系列，深入浅出，一起学习 ODP，从全链路视角看分布式系统问题，掌握连接管理、数据路由、高可能容灾等重要知识点，了解 SQL 从 executeQUery 接口调用到返回结果的冒险经历，让你更好地驾驭分布式数据库！

今天我们将分享的是第一篇内容，ODP 功能模块及特性详解。

1 了解 ODP

OceanBase Database Proxy（简称 ODP）是 OceanBase 数据库专用的服务代理。用户的 SQL 会先发送给 ODP 节点，由 ODP 选择合适的 ObServer（OceanBase 数据库进程名）进行转发，并将结果返回给用户。首先，我们从整体架构看一下 ODP 的作用。

图中 APP 是业务程序，APP 前面有三台 ObProxy（ODP 的进程名叫做 Obproxy）。在实际部署中，APP 和 ObProxy 之间一般会有负载均衡器，如 F5 将请求分散到多台 ObProxy 上面，ObProxy 的后面就是 ObServer，图中有 6 台 ObServer。ODP 知道 ObServer 中的数据分布信息，可以将用户 SQL 高效转发到数据所在机器，这样执行效率比转发到没数据的节点执行效率更高。如表 t1 数据在图中 P1 内，表 t2 数据在 P2 内，表 t3 数据在 P3 内，红色表示主副本，蓝色表示备副本，对于insert into t1语句 ，ODP 可以将 SQL 转发到 IDC2 中含有 P1 主副本的 ObServer 机器上。

为什么需要发送到数据所在的节点？主要原因是性能影响比较大，原理类似于计算机系统的多级缓存机制，如 CPU 从寄存器拿数据的执行效率要远远高于从内存拿数据的执行效率。实际生产环境中，除了考虑数据分布，ODP 还会考虑机器的地理位置分布，避免请求跨机房、跨城等情况出现。路由策略很多，后续有专门章节介绍。

2 使用 ODP

在部署好 OceanBase 数据库集群（包含部署 ODP ）后，就可以使用数据库服务了。我们以 JDBC 访问数据库举例：

final String URL = "jdbc:mysql://127.0.0.1:2883/test?useSSL=false&useServerPrepStmts=true";

在建立连接时，需要先初始化相关的连接信息，上面 URL 包含了数据库的 IP、PORT、访问的库名 test、连接属性等信息。使用 ODP 访问和直接连接 ObServer 访问区别就是 IP 和 PORT 不同，其它信息不需要任何改动。后续使用时，ODP 对用户来说是完全透明的。

ODP 让用户像使用单机一样使用 OceanBase 数据库：

1. ODP 兼容 MySQL 协议，用户可以使用 MySQL 标准驱动

2. 从 MySQL 数据库切换到 OceanBase 数据库，用户访问数据库的代码无需改动

3. ODP 对用户屏蔽了后端分布式系统的复杂性：如机器的变更、机器宕机、租户的 unit 分布、每日合并等，保证客户端和 ODP 连接的稳定性

3 产品发展

从发展历史去看，我们可以更好的理解为什么 ODP 是现在的样子，可能是方案设计，可能是业务需求，还有可能是历史兼容性包袱等。因此和大家一起聊聊 ODP 的过去和现在。

3.1 发展历史

ODP 产品从 2014 年开始设计研发，至今已经有七年多的历史，在蚂蚁内部、专有云场景、公有云场景都有广泛的使用，在访问链路上承担了重要的作用。发展历史如下：

总结一下：

1. 2014~2018，围绕数据库内核 1.0 架构设计，ODP 提供了 MySQL 协议代理、高效转发、连接管理、数据路由和容灾管理等能力。这段时间主要侧重点是 MySQL 兼容性和分布式特性适配，业务方面在蚂蚁内部也得到广泛使用

2. 2018~2021，ODP 探索云原生的产品形态 DBMesh，支持 SideCar 部署、运维和管理；同时将 SOFA ZDAL（SDK）能力下沉到 ODP 中，如单元化架构的 sharding 能力；OceanBase 数据库内核进行 Oracle 模式研发（商业版本支持），ODP 研发支持 Oracle 模式协议、分区表路由、分布式场景下的 PS 协议、SSL 链路加密等功能

3. 2021～至今：随着 OceanBase 服务更多的客户， ODP 也有了更多挑战，同时不断完善产品，满足客户需求。配合 OceanBase 数据库内核一起支持更多复杂功能，并进行性能优化；进行易用性改进和产品化发展，给研发人员和运维人员提供好的产品特性和体验；拥抱公有云，探索和完善 ODP 资源池形态，和其它云产品适配结合，降本增效，提供更多产品能力服务客户

3.2 产品形态

对于中间件组件，一般有 SDK 形态和代理两种形态，ODP 也是一样的，它们各有优缺点，总结如下：

目前 ODP 产品是以代理形态提供，后续会提供 SDK 形态。对于 ODP 开发人员来说，支持 SDK 和代理模式的主要挑战是如何将代码复用，解决方案是将基础能力包装成库接口，并通过进程通信技术让业务代码和 ODP 代码相互调用。

4 术语介绍

对一些术语做些解释，方便后面阅读

5 整体介绍

5.1 功能模块

介绍 ODP 功能模块，让大家整体了解 ODP 的实现和能做的事情。以下图为例，将 ODP 的功能分成了三层。

5.1.1 基础层

基础层实现网络通信、线程管理等基础框架和基础工具库，对上层提供支持。

网络通信库支持 tcp 协议、SSL 协议和 RDMA 通信，并封装易用接口供上层使用；异步事件框架完成线程创建、管理和任务的分发调度；基础库对一些基本能力做封装，为写代码提供好用的接口。

5.1.2 业务层

业务层是最复杂的，提供数据库业务相关一些基础能力：

1. 数据库协议实现 MySQL 模式、Oracle 模式协议和自研协议等，协议支持让 OB 产品可以做好兼容，以及开发更强大的功能

2. 连接管理处理客户端和服务端连接，并提供连接保持、异常处理等高级能力

3. SQL 解析用于感知 SQL 语义，从 SQL 提取表名、分区键等路由关键信息

4. 数据路由用于将请求分发到后端执行效率最高的 ObServer 节点，能否准确路由对性能影响很大

5. 容灾高可用可以保证及时发现服务有问题的 ObServer，或者在选择了有问题的 ObServer 后进行重试

6. 事务状态管理用于管理连接上事务状态，事务状态会影响 ODP 的路由转发

5.1.3 产品层

产品化在不断发展中，ODP 将一些能力产品化对外提供服务。产品形态主要是代理模式和 SDK 模式。sharding 是 ODP 在蚂蚁的单元化架构下支持的分库分表能力。我们也在挖掘更多有用功能，满足业务需求。

5.2 请求流程

对功能模块有了认识后，我们从 SQL 请求的整个流程去看，ODP 都做了哪些事情。

请求流程如下：

1. 客户端和 ODP 建立 tcp 连接，ODP 通过 epoll（网络通信库中实现）处理套接字的读写事件

2. 从 tcp 读取字节流保存到 buffer 缓冲中，并进行 MySQL 协议报文解析，先解析报头再决定是否解析后续内容

3. 从报文中读取 SQL，进行 SQL 解析

4. 根据表名和 location cache（表分区信息）找到表数据分布，选取有数据节点

5. 从数据库连接中找到对应的 ObServer 连接，并做 ObServer 的容灾管理检查

6. 使用选中的连接，通过高性能转发框架和后端 ObServer 进行交互

7. 将从 ObServer 收到的数据进行协议层处理，并返回给客户端

上面流程没有介绍异常情况下的容灾管理，可以参考上图。除了请求主流程以外，ODP 还有很多后台任务，这些任务也非常的重要，本系列后续章节会介绍。

5.3 ODP 关键特性

从 5.1 部分我们了解到了 ODP 的功能模块，从 5.2 部分我们了解到执行一条 SQL 时 ODP 的主要工作，总结一下， ODP 的主要关键特性如下：

1. 高性能转发：ODP 是数据访问流程中重要部分，因此采用多线程异步框架和透明流式转发的设计，保证了数据的高性能转发，同时确保了自身对机器资源的最小消耗

2. 协议支持：MySQL 协议兼容让 OceanBase 融入了 MySQL 生态；自研协议支持更多强大功能

3. 连接管理：保持客户端连接稳定是非常重要的事情，直观感受是业务不报连接错误，ODP 会去屏蔽后端的问题，保持和客户端连接的稳定

4. 数据路由：数据路由影响性能和高可用，和部署架构、数据分布等关系密切，对 SQL 执行有很大影响，路由正确也是大家非常关心的点

5. sharding 能力：是现有金融云解决方案的重要组成部分，c 语言版本也有更好的性能

6 展望未来

通过前面的介绍，相信大家对 ODP 有了一定的理解。ODP 未来是怎么规划的？出发点还是满足客户的诉求，打造好的产品。

ODP 从蚂蚁走出来，服务更多客户，某些场景下也出现了“水土不服”的现象。在一次次的版本迭代中，我们也一直让产品变得更加好用。从一个个需求和问题中去提炼总结，我们认为未来主要方向包括：

1. 基础能力：根据客户需求和 ObServer 的功能迭代，做好和数据库内核联动适配和新特性支持，持续完善和增强 ODP 内核稳定性和性能

2. 平台适配：支持更多平台，如 k8s、docker、云平台、arm 机器等，并深度做好平台适配，使用平台能力提供更好的产品体验

3. 生态对接：一方面和现有开源项目适配，如给 skywalking 提供监控数据；另一方面支持开源项目和 OceanBase 数据库对接，让开源项目更好的使用 OB 数据库

4. 产品化：根据 ODP 特性，打造成熟解决方案为客户服务；不断完善文档内容；打磨功能的易用性

5. 驱动：和更多语言驱动做好适配，同时提供代理和 SDK 两种产品形态，提供好的产品体验

未来充满了机遇和挑战，ODP 会和 OceanBase 数据库内核一起不断进步，为大家提供好的产品、文档和服务。

7 总结

因为 ODP 大部分时间对用户来说，存在感不强，所以大家不太了解。但涉及到一些高级特性和 OceanBase 数据库的分布式问题时，ODP 的原理就是一个避不开的话题。后续，我们会提供更多有趣的内容，比如数据路由、全链路问题排查、连接稳定性、分布式系统高可用等。这些内容也会帮助大家更好理解 OceanBase 数据库，希望通过系列文章，大家能学到知识，深入浅出了解 ODP，获得成长！