OceanBase 作为一款分布式关系型数据库，随着 Observer 集群的规模不断扩大，如果直连 ObServer，停机/上下线机器的概率也会随之增加， OBProxy 便是在这种情况下应运而生，以解决分布式数据库系统的 SQL 路由、高可用等问题。

OBProxy，全称为 OceanBase Database Proxy，是 OceanBase 数据库专用的服务代理。使用 OBProxy 可以屏蔽后端 ObServer 集群本身的分布式带来的复杂性，让访问分布式数据库像访问单机数据库一样简单。为此，我们筹划了高性能的数据访问中间件——OBProxy 专题，包括九篇文章，将从 OBProxy 的部署、原理、功能、架构、问题排查、最佳实践等方面一次性讲透，让你真正地对 OBProxy 知其然知其所以然。

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

今天我们将分享的是第一篇内容—— OBProxy 功能模块及特性详解，帮你更好地了解 OBProxy 是什么，有什么用以及怎么用。

1 什么是 OBProxy

术语介绍

在文章开始前，我们先对一些术语做个解释，方便大家后续阅读。

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

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

为什么 OBProxy 需要将 SQL 发送到数据所在节点？因为发到数据所在节点后，SQL 的执行计划可以在本地执行，没有了远程 RPC 调用，性能会更好。实际生产环境中，除了考虑数据分布，OBProxy 还会考虑机器的地理位置分布，避免请求跨机房、跨城等情况出现。路由策略有很多，后续我们也会有专门章节给大家进行介绍。

2 如何使用 OBProxy

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

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

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

因此，使用 OBProxy 会让问题变得简单，用户无需关心数据库系统的分布式架构，这样设计的好处有以下三点：

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

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

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

3 话聊 OBProxy 的 过去和现在

回顾发展历史可以帮助我们从方案设计、业务需求、历史兼容性“包袱”等角度更好地理解为什么 OBProxy 是现在的样子。让我们一起走近 OBProxy 的前世今生。

3.1 数说 OBProxy 发展历史

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

总结起来，OBProxy 的发展历程如下：

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

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

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

3.2 盘点 OBProxy 产品形态

对于中间件产品，一般有 SDK 形态和代理两种形态，OBProxy 也一样，它们的各自优缺点如下：

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

5 详解 OBProxy 功能模块及特性

5.1 功能模块

接下来，我们将对 OBProxy 功能模块进行解读，帮助大家体系化了解 OBProxy 的实现和功能。以下图为例，我们将 OBProxy 的功能分成了三层。

5.1.1 基础层

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

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

5.1.2 业务层

1. OBProxy 业务层最为复杂，提供了数据库业务相关的一些基础能力：

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

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

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

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

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

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

5.1.3 产品层

在不断发展中，OBProxy 将一些能力产品化对外提供服务，其产品形态主要是代理模式和 SDK 模式。Sharding 是 OBProxy 在蚂蚁的单元化架构下支持的分库分表能力。我们也在持续挖掘更多有用特性，丰富产品功能。

5.2 执行流程

对功能模块有了认识后，我们从 SQL 请求去看 OBProxy 的执行流程。

执行流程如下：

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

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

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

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

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

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

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

上面流程没有介绍异常情况下的容灾管理，可以参考上图。除了请求主流程以外，OBProxy 还有很多后台任务，这些任务也十分重要，本专题的后续文章会进行介绍。

5.3 盘点 OBProxy 关键特性

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

1. 高性能转发：OBProxy 是数据访问流程中重要部分，采用多线程异步框架和透明流式转发的设计，对关键路径代码做深入优化，同时确保了自身对机器资源的最小消耗

2. 协议支持：支持多种格式协议，如 MySQL 协议、Oracle 兼容协议和自研协议。目前在增强自研协议实现更多强大功能

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

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

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

6 OBProxy 未来规划及展望

通过前面的介绍，相信大家对 OBProxy 有了一定的理解。OBProxy 未来将如何规划？我们的出发点还是会落脚在满足客户的诉求，打造好的产品上。

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

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

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

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

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

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

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

7 总结

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

8 课后互动

出个小考题和大家做个交流，没有标准答案，欢迎大家畅所欲言，在问答区留言交流想法，我们下期一起讨论。

问题：使用 OBProxy 后，大家访问数据库的代码需要做哪些改动？