作者:易鸿伟 闫建良 王光树
在 TPC-C 标准定义中，测试系统分为 RTE(Remote Terminal Emulator)和 SUT 两部分。在实际的 TPC-C 测试流程中，不只是对 DB 端能力的考验，对链路 中的所有组件都存在极大的资源消耗和压力。以这次 6088 万 tpmC 测试结果看，我 们一共在 64 台 64C128G 的云服务器上运行了 960 个 RTE 客户端，来模拟总计 47942400 个用户 Terminal，后还需要基于这么多 RTE 统计结果进行一致性 和持久化审计验证。而 SUT 又拆分为三部分:WAS(Web Application Server)、 OceanBase Proxy(OBProxy) 和 OceanBase Server(OBServer)。RTE 的 请 求 到 WAS，然后 WAS 通过 OceanBase 客户端来访问 OBProxy，OBProxy 会将请求 转发到后端 OceanBase 集群中佳的 ObServer 去执行请求。WAS 和 OBProxy 是 RTE 和 OBServer 之间的桥梁，这个桥梁对于承载压力起着至关重要的作用。本 次 TPC-C 基准测试中，OceanBase 访问链路上主要涉及两个组件:
- ODBC 接口及驱动:TPC-C 测试中，WAS 请求 OceanBase 采用了 ODBC 接口。ODBC(Open Database Connectivity) 是 Microsoft 提出的 数据访问规范，ODBC 在大多数 DBMS 上都可以使用，OceanBase 也提供 了 ODBC 接口访问能力。感兴趣的用户可以查阅 ODBC API 说明 快速上手 使用，使用 ODBC 的用户可以直接使用该接口无缝迁移的访问 OceanBase。 ODBC 接口及驱动集成到 WAS 内部，作为请求 OceanBase 的客户端。
- OBProxy 代理:OceanBase 实现了 OBProxy 代理服务器来解决数据库链 路上的路由及容灾问题。OBProxy 会感知数据副本地址和分区规则，不参 与 SQL 引擎参与执行计划的生成调度，主要负责 SQL 路由和转发。这种架 构设计中，OBProxy 承担了基础的路由和容灾功能，而数据库的功能全部交
由 OBServer 实现。这样更加简单明确的分工可以各组件性能做的更加， OBProxy 也做到了完全无状态，只需要添加节点即可实现代理能力的水平扩 容，OceanBase 整体也能做到数据库的高性能。
TPC-C 基准 OceanBase 链路访问图
TPC-C 是一个非常严苛的基准测试模型，考验的是一个完备的关系数据库系统 全链路的能力，任何一个环节有瓶颈均无法发挥数据库的大性能，接下来本文会 分别在性能、成本及服务持续三个方面来说明下是如何优化 OceanBase 链路上的 组件。
链路性能优化
在 TPC-C 基准测试之 SQL 优化已经提到，从整个链路的角度来看，SQL 所 需要的执行时间是非常短暂的，大量时间花费在与客户端的交互过程中，造成资 源的浪费和耗时的增加，为此 OBServer 提供 Prepared Statement、存储过程和 ARRAY BINDING 能力。客户端和 OBProxy 针对该能力进行支持以使其真正发 挥作用。同时客户端本身也进行一些优化提升链路性能，接下来主要介绍链路性能部 分的优化点:
- 提供异步接口能力:通常使用数据库访问都是同步接口，同步接口开发方便， 但客户端受网络交互耗时影响大，并发能力受到限制。使用多线程的方式可以 帮助提升并发能力，但机器的线程资源是宝贵的，过多的线程会增加机器线 程切换的开销，限制了并发能力。为使 WAS 可以达到更高的吞吐能力，我 们基于事件驱动机制在 ODBC 接口内增加异步接口的支持。使用异步接口， WAS 单个线程内可以在发送请求后无需等待执行结果继续在其他 Session 上 发送请求，通过充分使用线程资源从而大幅提升吞吐能力。异步接口本身参 考 ODBC 接口规范，用户调用异步接口会立即返回，如果尚未执行完成则返 回 SQL_STILL_EXECUTING，用户可以轮询接口直到执行完成返回成功 (SQL_SUCCESS)或者失败(SQL_ERROR)，也可以基于网络事件驱动， 在有结果返回时再次调用接口获取结果。使用异步接口，可以在少量线程资源 下轻松支持大量的并发连接，极大的提升了 WAS 的并发能力，机器资源的利 用率也得到提升，大幅降低压测成本。
- 提 供 Prepared Statement 能 力:Prepared Statement 是 一 种 二 进 制 的 请 求交互协议，一次 PS SQL 文本传输，多次执行，OBProxy SQL 引擎会缓 存 PS SQL 文本以及解析结果，每条 PS SQL 只需要执行一次 Prepare 操 作，后续所有 Session 上的每次执行只需要传入对应的 Statement Id，就可 以从缓存中找到对应的 SQL 解析结果，结合传入的参数，可以很快的计算出 OBServer 的路由信息，转发性能更为高效。同时，作为代理层的 OBProxy 也很好的支持了 OBServer 的分布式特性，当 Client Session 需要切换 Server Session 时，无需再次发送 PS SQL 和 Execute 阶段时的类型数据， OBProxy 可以自行判断并决定是否需要同步 PS SQL 或加上类型数据。通 过 Prepared Statement 能力，可以有效减低系统间的交互成本，提升性能，相比普通 SQL 文本的交互方式，省去了大量 SQL 文本的传输以及请求文本 解析的 CPU 开销。
- 存储过程:对于存储过程，OBProxy 做了大量优化，存储过程通常包含多条 SQL，不同 SQL 通常需要路由到不同 OBServer 上执行，产生大量远程执 行。远程执行不仅会增加 RT，也会占用更多的 CPU 资源，因此，OBProxy 的 SQL 引擎会解析存储过程中的 SQL，计算优策略，将存储过程调用发往 合适的 OBServer 上执行，尽可能的减少远程执行次数。OBProxy 也会缓 存存储过程的解析结果和路由信息，用以省去每次硬解析带来的 CPU 开销。
- 复杂类型:我们在 OceanBase 原有传输协议上重新做了扩展，使得整个链 路支持复杂类型的传输。同时，OBProxy 新增了复杂数据类型的解析，能够 根据复杂类型数据来计算路由和分区裁剪。通过支持复杂类型，可以提高每次 传输携带的数据信息，有效减少交互次数，也能够根据复杂类型的数据计算 佳路由策略，尽可能的路由到分区更多的 OBServer 上，减少远程执行次数。 正是有了 OBProxy 对于数组等复杂类型的支持，才使得客户端可以更好的使 用存储过程和 ARRAY BINDING 的能力。
代理资源占用
OBProxy 代理采用多线程异步框架和透明流式转发的设计，保证了数据的高性 能转发(单核 5 万 QPS、转发 RT 30~50 us)，以及自身对机器资源的小消耗。 在 TPC-C 基准测试中，我们也采用了本地的形式部署到 WAS 端，这样可以大程 度的的减少客户端到代理层的网络开销。在本次测试中，OBProxy 代理层部署到 64 台客户端机器上，每台机器上使用到了 10 个 Core，一共占用 640 Cores，仅占整 体 CPU 测试成本的 7% 左右，几乎没有使用存储资源，资源占用比例小且支持水平扩容。
持续服务能力
OceanBase 提供了高可用的数据库服务，在出现机器不可用的场景下，不需要 有任何人工干预数据库依然能够持续提供服务，在本次 TPC-C 做 Durability 测试强 制断电操作中，OceanBase 就表现出无人工干预下的数据库持续服务的能力，大大 超出审计员的期望。
OceanBase 针对强制断电这种单机故障场景，OBProxy 有包含黑名单和灰 名单两种机制，用于处理 OBServer 错峰合并、升级、宕机、启动 / 停止，网络分 区等状态。黑名单采取定期刷新维护，由 OBServer 反馈哪些服务器节点不能提供 服务。灰名单则采取主动触发维护，当 OBProxy 转发请求给 OBServer，如果发 现 OBServer 返回特定的系统错误，或者 OBServer 在一段时间内有多次连续不 可用，则将该 OBServer 加入灰名单。黑名单中的 OBServer 不会被访问，灰名 单中的 OBServer 每隔一段时间会重试一次，检查是否需要洗白，以避免长时间将 OBServer 降级。通过 OceanBase 这样的机制，能够保障 TPC-C Durability 测 试过程中的数据库持续服务能力。
总结
OceanBase 链路层为客户提供了端到端的完整解决方案，其自研的传输协议 能够非常灵活的支持 SQL 特性和交互协议，实现了标准的数据库访问接口并支持 Oracle 兼容模式，可以达到数据库的易用性、高性能、服务持续的大平衡。后续 会持续优化传输协议以达到高的传输及交互效率，完善数据库访问标准接口，为用 户提供一个更为成熟的数据库服务。
