关于oceanbase:高性能数据访问中间件-OBProxy六一文讲透数据路由

62次阅读

共计 11158 个字符,预计需要花费 28 分钟才能阅读完成。

在《高性能数据拜访中间件 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>&1
return $?
}

当然,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: zone1
start_service_time: 1663664600100327
         stop_time: 0
            status: active


MySQL [oceanbase]> select * from __all_virtual_zone_stat\G
*************************** 1. row ***************************
               zone: zone1
         is_merging: 0
             status: ACTIVE
       server_count: 1
resource_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 数据库做好配合。

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

正文完
 0