在《高性能数据拜访中间件 OBProxy（五）：一文讲透数据路由》中，咱们讲到了数据路由影响因素包含性能因素、性能因素和高可用因素。本文次要介绍高可用因素相干的内容。

 

相比传统的 IOE 架构，OceanBase 利用更低的老本实现了更高的可用性，为客户提供机器级别容灾、机房级别容灾和城市级别容灾个性，是 OceanBase 数据库的杀手锏之一，深受用户喜爱，因而，本文将对高可用个性开展具体的介绍。

从技术角度看，分布式系统的高可用波及的模块很多，每个模块都可能呈现故障，实现高可用个性是一件十分艰难的事件。即便艰难很多，OceanBase 数据库还是对外做了 RPO = 0、RTO < 30s 的承诺，这其中波及到的知识点很多，OBProxy 遇到的问题和 OBServer 也有很大不同，因为本文是 OBProxy 系列文章，所以次要从 OBProxy 的视角去介绍高可用的内容，但 OBServer 的高可用实现也十分精彩，大家也能够多多理解～

 

OBProxy 高可用的两个维度

 

理解 OBProxy 高可用个性的实现还得从高可用的概念讲起。“高可用性”（High Availability）通常指一个零碎通过专门的设计，从而缩小复工工夫，而放弃其服务的高度可用性。假如零碎能够始终提供服务，那么零碎的可用性是100%。如果零碎每运行100个工夫单位，会有1个工夫单位无奈提供服务，那么零碎的可用性是99%。

咱们都晓得，单点往往是零碎高可用最大的危险和敌人，应该尽量在零碎设计的过程中防止单点。从方法论而言，高可用保障的准则是“集群化”，或者叫“冗余”：只有一个单点，该单点挂了会使服务受影响；如果有冗余备份，挂了还有其余备份能顶上。为保证系统高可用，架构设计的外围准则是冗余，只有“冗余”还不够，故障每次呈现都须要人工染指复原肯定会减少零碎的不可服务实际。因而，咱们往往通过“主动故障转移”来实现零碎的高可用。

置信你曾经从上述内容中理解到 OBProxy 的高可用个性就蕴含两个维度：一是实现 OBProxy 服务高可用个性，产生故障后可及时复原 OBProxy 的服务；二是保障 OceanBase 数据库的高可用，如探测和辨认 OceanBase 数据库节点的故障并退出黑名单，通过正当路由对利用端屏蔽数据库故障，当数据库节点故障复原后及时洗白 OBServer 节点，充分利用每一台机器资源。

上面对这两个维度开展具体介绍。

 

维度一：OBProxy 服务高可用

 

OBProxy 服务的高可用是指 OBProxy 自身可能间断提供服务，升高故障对代理服务影响。但这会受以下三个因素影响。

  • 因素1：部署 OBProxy 的机器是否失常，比方该机器是否能够和其余机器失常通信、机器是否产生了宕机。
  • 因素2：OBProxy 过程是否能够稳固运行并失常提供服务，以及过程被误杀后是否能够及时拉起。
  • 因素3：OBProxy 依赖的第三方模块如 OCP 和 OBServer 是否失常提供服务，比方 OCP 是否能够失常提供 HTTP 服务。

 

因素1：部署机器异样

 

《高性能数据拜访中间件 OBProxy（二）：装置部署最佳实际》中咱们介绍了 OBProxy 的常见部署形式，咱们将通过剖析利用端部署和独立部署（OBServer 端部署相似）两种状况下的机器故障介绍 OBProxy 服务高可用，当初咱们来回顾一下之前内容。

图1是利用端部署的状况，OBProxy 和业务 App 部署在一台机器上。当业务机器呈现问题后，App 和 OBProxy 都会受到影响，须要业务层和 OBProxy一起实现高可用个性。常见的办法有：

  • 故障探测：通过第三方零碎进行探测、监控、巡检等发现业务服务异样，触发自愈流程后者 SRE 染指。
  • 弹性扩大：依据申请量做容量评估，思考是否须要弹性扩容，如果须要及时扩容，新的机器启动 App 程序和 OBProxy程序提供服务，因为业务 App 和 OBProxy 过程自身无状态，所以扩容个别都很快。
  • 流量切换：对故障机器做好隔离，切走流量，转发到其余衰弱节点服务，保障申请失常执行。

通过上述办法，OBProxy 服务就能够及时复原。下面步骤工夫越短，可用性越高。

 

图1 利用端部署

和利用端部署不同，独立部署模式下，OBProxy 部署在独立的机器上，同时也引入了负载平衡模块，放在 OBProxy 后面，如图2。

 

图2 独立部署

这种部署架构下，OBProxy 的高可用和 App 的高可用做理解耦，有多个 OBProxy 提供服务，也就是后面介绍到的冗余。LB 会对 OBProxy 做健康检查，及时发现 OBProxy 的故障，并将故障的 OBProxy 机器拉黑，不再转发 SQL 流量到故障机器。故障后 OBProxy 机器少了，会导致其余 OBProxy 机器的负载减少，如果发现其它机器负载过高，能够增加新的 OBProxy 机器缓解压力。

比照独立部署和利用端部署，咱们会发现独立部署呈现高可用问题的概率更大，次要起因是链路变长了。举个例子，App 和 OBProxy 呈现了网络故障导致服务不可用。在利用端部署的形式下，因为App 和 OBProxy 走本地通信，这种状况简直不可能呈现；而在独立部署形式下，这种问题呈现的概率就会大很多。

 

因素2：OBProxy 过程异样

 

除了机器故障，OBProxy 过程异样对高可用的影响也很大。产生异样的起因有很多，如程序bug导致过程core、内存应用太多导致OOM(Out Of Memory)、运维操作误杀过程等。尽管起因很多，但最终的表现形式就是服务端口无奈提供服务。

对于这种状况，咱们通过 obproxyd.sh 脚本解决，你能够回顾《高性能数据拜访中间件 OBProxy（二）：装置部署最佳实际》，次要原理是通过 nc 命令拜访 OBProxy 的监听端口，如果TCP 建连胜利就阐明 OBProxy 过程存在，如果过程不存在 obproxyd.sh 脚本负责重新启动 OBProxy 过程，OBProxy过程能够在1秒左右启动胜利并提供服务。图3为实在环境的过程运行状况，其中的第二个过程为 OBProxy 服务过程，第三个过程为 obproxyd.sh 过程。

 

图3 OBProxy 过程运行状况

外围代码如下：

function is_obproxy_healthy(){echo hi |nc 127.0.0.1 $OBPROXY_PORT -w 2 > /dev/null 2>&1return $?}

当然，obproxyd.sh 能做的尽量复原服务，举个例子，如果程序bug导致一启动就 core，再怎么重启都是有效的，此时能够走机器异样的流程，由负载平衡组件进行解决。但对于概率很小的 bug，重启就能够及时复原服务，对业务的影响会很小。

 

因素3：OCP 模块异样

 

即便 OBProxy 一切正常，但如果依赖的第三方模块异样，那么，OBProxy 也无奈失常提供服务。此处咱们次要介绍 OCP模块异样。

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

如果 OCP 不可用（通过curl命令拜访 OCP 提供的 URL 能够确认），OBProxy 能够应用本地的 rslist 缓存文件提供服务。是否应用缓存文件通过配置项ignore_local_config管制，默认为 true 示意不应用本地缓存。

应用本地缓存能够解决 OCP 异样后的局部集群无法访问的问题，但也存在肯定的毛病：

  • 缓存中只保留了拜访过的集群的 rslist 信息，如果集群未拜访还是无奈提供服务。
  • 缓存信息具备时效性，如果机器的 rslist 变动后则无奈感知。

因而，咱们须要 OCP 本身是高可用设计的，并在呈现问题后及时修复，这样能力保障服务不受影响。

总的来说，通过负载平衡组件和 obproxyd.sh 程序，能够及时处理过程异样和机器异样的状况。OBProxy 在实现时也对程序启动流程做了大量优化，能够在 1 秒内实现初始化和配置加载，并对外提供服务。

OBProxy 尽量减少了对外部模块依赖，但无奈做到不应用 OCP 模块，OBProxy 会通过本地缓存的形式升高依赖水平，尽量进步可用性。

 

维度二：保障 OceanBase 数据库高可用

 

除了 OBProxy 服务的高可用，OBProxy 一个重要个性就是帮忙 OceanBase 数据库实现高可用个性，OBProxy 属于 OceanBase 数据库高可用体系中重要的一环。当 OceanBase 数据库呈现问题后，一方面须要数据库系统及时复原服务；另一方面须要 OBProxy 感知 OBServer 机器故障和服务变更。

OBProxy 要实现下面性能，次要通过故障探测、黑名单机制和 SQL 重试三种伎俩。故障探测用于发现故障节点，黑名单机制影响 OBProxy 的路由，SQL 重试保障 SQL 尽可能执行胜利。

 

1 故障探测和黑名单

在讲故障探测前，咱们先阐明下故障的品种和探测难点。

首先，对于故障的品种，咱们次要分为以下两局部。

  • 机器和过程故障：如机器宕机、网络故障、过程core等机器硬件问题或过程问题。
  • 业务逻辑问题：指 OceanBase 数据库本身逻辑问题导致服务不可用，如 Paxos 选举失败导致无 LEADER 提供服务等。

目前，对于业务逻辑引发故障，与数据库的实现严密相干，很难去确定问题边界并解决所有问题，比方业务逻辑呈现死循环导致服务不可用，OBProxy 是无奈解决这种问题的。因而，OBProxy 的策略是在解决 OBServer 机器和过程故障根底上，依据一些已知景象去解决一些业务逻辑问题，如 OBServer 返回的特定错误码（如机器内存不足）、OBServer 长时间无响应等。

说完故障后，咱们再讲一下探测相干内容。在分布式系统中，故障探测的后果有三种：胜利、失败和超时。其中，超时是最难解决的状况。比方一个 SQL 执行了100秒依然未返回后果，咱们很难确定执行这个 SQL 的 OBServer 是否失常，有时候就是 OBServer 执行慢了，有时候的确是 OBServer 呈现问题了；另一方面，探测工作个别都是周期性的，在两次探测之间如果 OBServer 产生了状态变动，OBProxy 无奈做到实时感知，因而可能就会应用过期的信息去做一些路由抉择，但这样就可能会导致一些慢 SQL 或者 SQL 执行失败。

理解了故障类型和探测难点后，你能够一边往下浏览一边思考 OBProxy 的高可用个性能够解决哪些故障，不能解决哪些故障，以及存在的艰难是什么。

咱们晓得，故障探测的根底是节点状态定义，如定义衰弱和故障两种状态。但 OBServer 的状态要简单很多，次要是因为将状态定义更加精密能力实现更多的高可用性能，让客户体验更好。OBProxy 对 OBServer 定义了八种状态。

  • ACTIVE 状态：示意 OBServer 节点失常，能够提供服务。
  • INACTIVE 状态：示意 OBServer 节点异样，无奈提供服务。
  • UPGRADE 状态：示意 OBServer 节点正在数据库版本升级阶段。
  • REPLAY 状态：示意 OBServer 节点在进行数据库日志的回放阶段。
  • DELETING 状态：示意 OBServer 节点正在被删除，此时可能正在进行数据迁徙等操作。
  • DELETED 状态：示意节点曾经被删除，不再属于该集群。
  • DETECT_ALIVE 状态：示意 OBProxy 对 OBServer 节点探测胜利，认为 OBServer状态失常。
  • DETECT_DEAD 状态：示意 OBProxy 对 OBServer 节点探测失败，认为 OBServer状态异样。

看到了这么多状态，你是不是感觉记不住，其实只有从原理上思考就会感觉好记很多，如过程core（INACTIVE 状态）、节点下线被删除（DELETING 或者 DELETED 状态）、新增节点（REPLAY 状态）、版本升级（UPGRADE 状态）、过程hang 住（DETECT_DEAD 状态）。

那么依据什么条件设置 OBServer 的状态呢？前6个状态通过拜访 OBServer 的外部表取得，OBproxy会周期性（20s/次）从 __all_virtual_proxy_server_stat 和 _all_virtual_zone_stat表中获取集群的机器状态信息。如上面查问后果展现：

MySQL [oceanbase]> select * from __all_virtual_proxy_server_stat\G*************************** 1. row ***************************            svr_ip: xx.xx.xx.xx          svr_port: 33041              zone: zone1start_service_time: 1663664600100327         stop_time: 0            status: activeMySQL [oceanbase]> select * from __all_virtual_zone_stat\G*************************** 1. row ***************************               zone: zone1         is_merging: 0             status: ACTIVE       server_count: 1resource_pool_count: 1         unit_count: 1            cluster: ob9988.zhixin.lm             region: sys_region             spare1: -1             spare2: -1             spare3: -1             spare4:             spare5: ReadWrite             spare6:

OBProxy会通过status、start_service_time、stop_time定义OBServer状态。

状态7和状态8通过 OBProxy 的探测机制取得。另外，须要留神的是，产生状态变更后，OBProxy 会依据状态变更后果触发高可用相干的逻辑，许多内容和黑名单机制无关。

开展来讲，就是OBProxy 探测出 OBServer 的节点状态后，先批改黑名单，而后依据黑名单进行节点拉黑或节点者洗白操作。依据不同的探测机制，OBProxy 实现了状态黑名单、探测黑名单和活不可用黑名单三种不同的黑名单。

状态黑名单。状态黑名单依赖于 OBServer 的状态变更。因为历史起因，和状态黑名单相干的状态不蕴含 DETECT_ALIVE 和 DETECT_DEAD 两种状态，剩下的状态变更都能够通过拜访 OBServer 的外部表取得。

当通过周期工作取得 OBServer 最新状态后，OBProxy 会进行图4中的操作。

图4 状态黑名单下，OBServer 状态变更操作

探测黑名单。状态黑名单相当于从“他人”（OceanBase 的总控服务节点 RS）处取得信息，这种信息有时不能反映 OBProxy 和 OBServer 之间的状况。如图5， OBProxy 从 RS 处取得 OBServer1 状态为 ACTIVE，但 OBProxy 和 OBServer1 之间网络不通。

图5 OBProxy 和 OBServer 网络不通的案例

因而，在现有的状态黑名单根底上，咱们又实现了探测黑名单，通过给 OBServer 发送探测 SQL 来确定 OBServer 状态。OBProxy 会给 OBserver 的 SYS 租户发送探测 SQL select 'detect server alive' from dual ，并设置5s的超时工夫，当超时工夫内无后果返回时，会减少一次探测失败次数，当间断失败次数超过3次后，会认为探测失败，设置 OBServer 状态为 DETECT_DEAD。如果有后果返回，会将探测失败次数清零，设置 OBServer 状态为 DETECT_ALIVE。产生探测状态变更后，触发 OBProxy 行为如图6。

图6 探测黑名单下，OBServer 状态变更操作

这里阐明下为什么退出到探测黑名单后还会把该 OBServer 的相干连贯断开。咱们假如一直开和该 OBServer 的连贯，那么连贯会被始终占用无奈发送新的 SQL，在性能数据上会看到这段时间的这台 OBServer 的 TPS 为0，断开后，对于后续申请， OBProxy 会依据黑名单进行路由，不会转发给这台 OBServer，TPS 就能够复原。

活不可用黑名单。有了状态黑名单和探测黑名单，OBProxy 曾经能够很好地解决机器和过程故障了，但 OBProxy 能够更近一步感知每个 SQL 执行失败的起因，去解决更简单的状况，因而实现了活不可用名单。活不可用名单机制的外围是依据业务 SQL 的执行后果去定义 OBServer 的状态，触发拉黑和洗白操作。次要有以下四个关键步骤。

  • 失败：依据工夫点记录下一次失败事件。
  • 拉黑：在120s 内有 5s 失败记录则拉黑这台 OBServer。
  • 尝试：拉黑一段时间后，尝试再次往该 OBServer 发送 SQL。
  • 洗白：如果尝试的 SQL 执行胜利则进行洗白。

能够看到，活不可用名单的拉黑和洗白审慎了很多，次要是为了避免一次 SQL 执行后果产生误判。活不可用名单中更简单的就是对失败事件的定义，能够参考图7。

图7 活不可用名单下，OBServer 状态变更操作

能够看到，下面三种黑名单解决了不同维度的问题，少了任何一个都可能导致某种异样无奈解决。对于上述三种黑名单，你可能会想理解它们之间的优先级是什么？你能够认为它们没有优先级，只有 OBServer 在任何一个黑名单中，这台机器就无奈接管申请，当 OBServer 不在任何黑名单中才会接管到申请。

对于 HAProxy 等代理，个别只实现了探测机制对后端服务器做健康检查，但这种探测只能解决一些简略的问题。OBProxy 针对 OceanBase 数据库个性，做了更多的工作，如感知 OBServer 版本升级、日志回放、SQL 执行谬误等。这是一般代理齐全无奈做到的。

 

2 SQL 重试

有了黑名单当前，咱们就能够实现 SQL 重试性能，SQL 重试的目标是让 SQL 实现执行，而不是简略把谬误抛给客户端。能够进行重试的一个重要准则是不能产生预期外的行为。举个例子，用户执行了 SQL insert into t1 values (c1 + 1, 1)，OBServer 很长一段时间没有响应，此时不能从新发给另一台 OBServer，否则有可能导致c1 变成了 c1 + 2。咱们要牢记，谬误的重试危害更大！

OBProxy 的重试产生在两个阶段，一个是给 OBServer 转发前，一个是给 OBServer 转发后，上面咱们来做具体介绍。

转发前重试

咱们以 OBProxy 架构图来解释转发前重试，图8的红色局部即为转发前重试的产生地位。

图8 OBProxy 架构图

以一个一般的 SQL select * from t为例阐明转发前的重试逻辑。假如 t 为非分区表，表的 partition 的 LEADER 散布在 OBServer1 下面，OBServer1 的 observer 过程 core 掉，RS 发现该机器 core 掉设置外部表状态为 INACTIVE。

依据主正本路由策略，在数据路由阶段抉择了 OBServer1 ，而后进行容灾治理查看，发现 OBServer1 在状态黑名单中，此时就进行路由重试，不再走主正本路由，而是走租户内路由，从租户的机器列表中抉择机器路由，而后再进行容灾查看，直到容灾查看通过才进行转发。

和所有故障一样，越早发现问题并解决效率越高，转发前重试只产生在 OBProxy 外部，疾速的解决了问题，业务简直无感知。

转发后重试

转发前重试很美妙，但依赖黑名单的准确性（参考后面说到的探测难点时效性问题），在分布式系统中，咱们无奈实时感知机器状态，因而在进行转发前，咱们可能还不晓得机器产生了问题。此时依据转发的后果能够进行肯定水平的重试。

这里你能够想一下，转发后果有哪些？常见后果有两种，一种是 OBServer 机器故障导致 TCP 连贯失败，如果无非凡限度（思考下事务路由），此时能够抉择新的机器进行空虚；另一种是 OBServer 执行失败返回错误码。因为错误码太过于细节此处就不作具体介绍了，你能够参考 OBProxy 的开源代码ObMysqlTransact::handle_oceanbase_server_resp_error去梳理，举个例子， OBServer 返回错误码 REQUEST_SERVER_INIT_ERROR，此时阐明 OBServer 初始化失败，就能够进行从新转发，后续逻辑和转发前重试逻辑很像。

通过转发前重试和转发后重试，OBProxy 解决了大量的 OBServer 问题，整个过程对用户齐全通明，用户可能都不晓得产生过故障。其中，转发前重试效率高，但依赖黑名单机制；转发后重试是转发前重试一种补充，尽可能地屏蔽后端异常情况。

总之，故障探测、黑名单和 SQL 重试是 OBProxy 高可用个性十分重要的三个性能，三者也有肯定的关系。比方转发后重试和活不可用黑名单都依赖 OBServer 的反馈信息，转发前重试依赖黑名单机制。

通过下面三个高可用性能， OBProxy 解决了大部分的 OBServer 异样，如网络故障、OBServer 过程异样、机器宕机等；同时，OBProxy 也进一步辨认 OceanBase 数据库自身的一些逻辑异样，如版本升级、日志回放等，让 OBServer 做的更加的好用。

 

3 和 OceanBase 高可用关系

OBServer 的高可用和 OBProxy 不同，OBServer 基于 Paxos算法，保障在多数派失常状况下就能够失常提供服务，容忍了少数派节点异样。但 OBServer 的高可用可能会导致服务节点从 A 切换到 B（切主操作），因而须要 OBProxy 更快更准的找到失常服务节点。所以两者之间相互配合，对用户提供稳固的服务。
更多 OceanBase 数据库高可用介绍，请参考文档～

 

高可用测试

 

高可用听起来是一个高大上的名词，但你也能够通过测试感受一下，当然咱们无奈在跑业务压测时把机房电源关掉。但对于 OceanBase 数据说的 RTO体现，你也能够用 sysbench 工具（上面测试基于 OBServer 4.0 版本）。办法非常简单，先将 sysbench 压测失常跑起来，而后利用kill -9/-19/-18 操作 OBserver 或者 OBProxy 过程，察看 TPS 的变动。

[ 13s ] thds: 400 tps: 190.00 qps: 3431.03 (r/w/o: 2700.03/380.00/351.00) lat (ms,99%): 1938.16 err/s: 0.00 reconn/s: 0.00[ 14s ] thds: 400 tps: 452.00 qps: 8034.99 (r/w/o: 6234.99/885.00/915.00) lat (ms,99%): 2045.74 err/s: 0.00 reconn/s: 0.00[ 15s ] thds: 400 tps: 464.00 qps: 8466.98 (r/w/o: 6591.98/945.00/930.00) lat (ms,99%): 1304.21 err/s: 0.00 reconn/s: 0.00[ 16s ] thds: 400 tps: 404.00 qps: 7723.98 (r/w/o: 6036.98/865.00/822.00) lat (ms,99%): 1280.93 err/s: 0.00 reconn/s: 0.00[ 17s ] thds: 400 tps: 515.99 qps: 8798.78 (r/w/o: 6818.83/971.98/1007.97) lat (ms,99%): 1479.41 err/s: 0.00 reconn/s: 0.00[ 18s ] thds: 400 tps: 546.01 qps: 9694.12 (r/w/o: 7528.10/1071.01/1095.01) lat (ms,99%): 1149.76 err/s: 0.00 reconn/s: 0.00[ 19s ] thds: 400 tps: 555.99 qps: 9973.84 (r/w/o: 7746.88/1109.98/1116.98) lat (ms,99%): 861.95 err/s: 0.00 reconn/s: 0.00[ 20s ] thds: 400 tps: 551.02 qps: 10089.34 (r/w/o: 7873.26/1121.04/1095.04) lat (ms,99%): 846.57 err/s: 0.00 reconn/s: 0.00[ 21s ] thds: 400 tps: 267.00 qps: 4857.99 (r/w/o: 3763.99/534.00/560.00) lat (ms,99%): 831.46 err/s: 0.00 reconn/s: 0.00[ 22s ] thds: 400 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,99%): 0.00 err/s: 0.00 reconn/s: 0.00[ 23s ] thds: 400 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,99%): 0.00 err/s: 0.00 reconn/s: 0.00[ 24s ] thds: 400 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,99%): 0.00 err/s: 0.00 reconn/s: 0.00[ 25s ] thds: 400 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,99%): 0.00 err/s: 0.00 reconn/s: 0.00[ 26s ] thds: 400 tps: 0.00 qps: 211.00 (r/w/o: 90.00/0.00/121.00) lat (ms,99%): 0.00 err/s: 0.00 reconn/s: 178.00[ 27s ] thds: 400 tps: 3.00 qps: 1765.86 (r/w/o: 1531.88/10.00/223.98) lat (ms,99%): 6594.16 err/s: 0.00 reconn/s: 174.99[ 28s ] thds: 400 tps: 449.03 qps: 10079.67 (r/w/o: 8246.55/935.06/898.06) lat (ms,99%): 7895.16 err/s: 0.00 reconn/s: 2.00[ 29s ] thds: 400 tps: 612.00 qps: 10188.00 (r/w/o: 7714.00/1268.00/1206.00) lat (ms,99%): 816.63 err/s: 0.00 reconn/s: 0.00[ 30s ] thds: 400 tps: 550.03 qps: 10166.58 (r/w/o: 7971.46/1084.06/1111.06) lat (ms,99%): 831.46 err/s: 0.00 reconn/s: 0.00[ 31s ] thds: 400 tps: 571.96 qps: 10246.31 (r/w/o: 7956.46/1139.92/1149.92) lat (ms,99%): 831.46 err/s: 0.00 reconn/s: 0.00

如下面的数据，TPS 稳固值为500左右，21s ～ 27s 产生了上涨，过程花了7s 左右，对应的就是 RTO < 8s 复原了服务。

 

结语

 

OBProxy 的高可用个性次要包含 OBProxy 服务高可用和保障 OceanBase 数据库高可用两局部，波及的模块也比拟多，任何一个模块出问题都可能牵一发而动全身，可见分布式系统的复杂性。本篇文章也是 OBProxy 路由的重要补充，路由的性能正确性、高性能和高可用都是十分重要的话题。随着 OceanBase 自身架构的演进，高可用个性也须要一直调整，和 OceanBase 数据库做好配合。

从系列文章看，连贯治理、路由和高可用彼此关联，相互依赖，你能够花工夫多看几遍，这些对了解分布式系统的原理和进行分布式系统设计十分有帮忙。