数据库连接和路由概述

连接

OBProxy 为用户提供了数据库接入和路由功能，用户连接 OBProxy 就可以正常使用 OceanBase 数据库。用户在使用数据库功能时，OBProxy 和 OBServer 进行交互，且交互流程对用户透明，连接管理就是该交互过程中的关键点之一。 数据库连接包括物理连接和逻辑连接。物理连接主要是指网络连接部分，逻辑连接主要是 ODP 与 OceanBase 数据库之间的 Session 部分。

特性

OBProxy 的连接管理有三个特性：

1. 代理特性：OBProxy 既是客户端，也是服务端，还需要保证交互行为符合 MySQL 协议规范。
2. 功能特性：OBProxy 实现了很多的连接功能特性，如访问不同集群、不同租户，再如支持物理备库、分布式下的 PREPARE Statement 功能，以及兼容 kill、show processlist 等命令。
3. 高可用特性：OBProxy 可以处理超时、机器状态变化、网络状态变化等问题，屏蔽后端异常，让用户无感知。

连接映射关系

OceanBase 不同于单机数据库，当你通过客户端与单机数据库建立一个连接时，你的客户端与数据库之间只有一个物理连接，如下图所示。

当你通过 OBProxy 与 OBServer 建立一个连接时，你的客户端与 OBProxy 之间存在一个物理连接，OBProxy 与 OBServer 可能存在多个物理连接，如下图所示。 其中 Client 与 OBProxy 的连接称为客户端连接，OBProxy 与 OBServer 之间的连接称之为服务端连接。

当你的客户端所访问的数据在不同的 OBServer 上时，OBProxy 会为你向 OBServer 建立多个物理连接并且管理复用这些连接，在客户端视角看来仅存在一个逻辑连接，OBProxy 基于此可以为客户提供许多功能特性，比如读写分离、分区表数据路由、分布式 PS、屏蔽后端异常等等。

连接功能特性

和单机数据库不同，OBProxy 将连接的映射关系改变为 M:N，因此有些连接功能需要做额外处理。 举例说明：用户通过 show processlist 查看连接数，此时希望看到的是客户端和 OBProxy 之间的连接数，而不是 OBProxy 和 OBServer 节点之间的连接数。

下面我们对常见的连接功能展开详细介绍:

• 连接粘性 OBProxy 还未实现所有功能的状态同步，如事务状态、临时表状态、cursor 状态等。对于这些功能，OBProxy 只会将后续请求都发往状态开始的节点，这样就不需要进行状态同步，而缺点是无法充分发挥分布式系统的优势。因此，OBProxy 将根据功能重要程度，逐步支持相关功能的分布式化。
• show processlist 和 kill 命令配套使用 show processlist 用于展示客户端和服务端之间的连接，对于 OBProxy 来说，show processlist 只展示客户端和 OBProxy 之间的连接，不展示 OBProxy 和 OBServer 节点之间的连接。kill 命令用于杀死一个客户端连接，客户端连接关闭后，OBProxy 也会关闭对应的服务端连接。对于 OBProxy 的 kill 命令，需要先获取对应的 ID（使用 show processlist 命令即可获取 ID）。
• 负载均衡影响因为 OBProxy 对 show processlist 和 kill 命令做了处理，所以 show processlist 和 kill 命令只有都发往同一台 OBProxy 才能正常工作。在公有云等环境，OBProxy 前面有负载均衡，负载均衡后面挂载多个 OBProxy 上，此时，如果执行 show processlist 和 kill 命令是两个不同的连接，负载均衡组件可能将请求发往不同的 OBProxy，在这种情况下，建议不要使用相关命令。

路由

路由是 OceanBase 分布式数据库中的一个重要功能，是分布式架构下，实现快速访问数据的利器。

Partition 是 OceanBase 数据存储的基本单元。当我们创建一张 Table 时，就会存在表和 Partition 的映射。非分区表中，不考虑主备时，一张 Table 对应一个 Partition；分区表中一个 Table 会对应多个 Partition。

路由实现了根据 OBServer 的数据分布精准访问到数据所在的机器。同时还可以根据一定的策略将一致性要求不高的读请求发送给副本机器，充分利用机器的资源。路由选择输入的是用户的 SQL、用户配置规则、和 OBServer 状态，路由选择输出的是一个可用 OBServer 地址。其路由逻辑如下图所示：

解析 SQL 模块使用的是 OBProxy 自己定制的 Parser 模块，只需要解析出 DML 语句中的数据库名、表名和 Hint，不需要通过其他复杂的表达式推演。

确定路由规则模块中，OBProxy 需要根据不同情况确定最佳的路由规则。比如：强一致性读的 DML 请求期望发到分区所属日志流的主副本 OBServer 上，弱一致性读的 DML 请求和其他请求则不要求，主副本和从副本均衡负载即可。如果 OceanBase 集群是多地部署，OBProxy 还提供了 LDC 路由，优先发给同机房的 OBServer，其次是同城的 OBServer，最后才是其他城市的 OBServer。如果 OceanBase 集群是读写分离部署，OBProxy 还提供了读 Zone 优先、只限读 Zone、非合并优先等规则供业务按照自身特点配置。上述的几种情况在路由选择中是组合关系，输出是一个确定的路由规则。

获取路由表是指 OBProxy 根据用户的请求 SQL 获取该 SQL 涉及的副本位置。OBProxy 每次首先会尝试从本地线程缓存中获取路由表，其次是全局缓存，最后才是发起异步任务去向 OBServer 查询路由表。对于路由表的更新，OBProxy 采用触发更新机制。OBProxy 每次根据路由表转发给 OBServer 的请求，当 OBServer 不能本地执行时，会在回包时反馈给 OBProxy。OBProxy 根据反馈决定是否下次强制更新本地缓存路由表。通常是在 OBServer 合并或者负载均衡导致切主时，路由表才会发生变化。

选择目标 OBServer 则是根据确定的路由规则从上一步获取的路由表中选择最佳的 OBServer，在经过黑名单、灰名单检查通过后作为最终的目标 OBServer 进行请求转发。