ODP 服务高可用

ODP 服务的高可用是指 ODP 本身能够连续提供服务，降低故障对代理服务影响。但这会受以下两个因素影响。

• 因素 1：ODP 进程是否可以稳定运行并正常提供服务，以及进程被误杀后是否可以及时拉起。

• 因素 2：ODP 依赖的第三方模块如 OCP 和 OceanBase 数据库是否正常提供服务，比如 OCP 是否可以正常提供 HTTP 服务。

接下来分别就这两个因素介绍 ODP 服务的高可用。

ODP 进程异常

除了机器故障，ODP 进程异常对高可用的影响也很大。产生异常的原因有很多，如程序 bug 导致进程 core、内存使用太多导致 OOM（Out Of Memory）、运维操作误杀进程等。虽然原因很多，但最终的表现形式就是服务端口无法提供服务。

对于这种情况，可以通过 obproxyd.sh 脚本解决，主要原理是通过 nc 命令访问 ODP 的监听端口，如果 TCP 建连成功就说明 ODP 进程存在；如果进程不存在，obproxyd.sh 脚本负责重新启动 ODP 进程。ODP 进程可以在 1s 左右启动成功并提供服务。

当然，obproxyd.sh 能做的只是尽量恢复服务，举例说明，如果程序 bug 导致一启动就 core，此时无论如何重启都是无效的。对于这种情况，可以选择走机器异常的流程，由负载均衡组件进行处理。但对于概率很小的 bug，重启就可以及时恢复服务，对业务的影响会很小。

OCP 模块异常

即使 ODP 一切正常，但如果依赖的第三方模块异常，可能造成 ODP 的配置无法及时更新等影响。本节主要介绍 OCP 模块异常。

OCP 为 ODP 提供了中心化的配置服务，OCP 保存了一些关键配置信息，如集群名和集群 rslist （OceanBase 总控服务 RS 的机器 IP 列表）的映射关系。当 ODP 从 OCP 拉取到 rslist 信息后，会保存本地 etc 目录下的 obproxy_rslist_info.json 文件中。

如果 OCP 不可用（通过 curl 命令访问 OCP 提供的 URL 可以确认），ODP 可以使用本地的 rslist 缓存文件提供服务。是否使用缓存文件通过配置项 ignore_local_config 控制，默认为 true 表示优先使用 Config Server 的配置；为 false 时表示优先使用本地缓存配置。

使用本地缓存可以解决 OCP 异常后的部分集群无法访问的问题，但也存在一定的缺点，如：

• 缓存中只保存了访问过的集群的 rslist 信息，如果集群未访问还是无法提供服务。

• 缓存信息具有时效性，如果机器的 rslist 变化后则无法感知。

因此，我们需要 OCP 自身是高可用设计的，并在出现问题后及时修复，这样才能保证服务不受影响。

总的来说，通过负载均衡组件和 obproxyd.sh 程序，可以及时处理进程异常和机器异常的情况。ODP 在实现时也对程序启动流程做了大量优化，可以在 1s 内完成初始化和配置加载，并对外提供服务。

ODP 尽量减少了对外部模块依赖，但无法做到不使用 OCP 模块，ODP 会通过本地缓存的方式降低依赖程度，尽量提高可用性。