《大规模分布式存储系统》第11章 质量保证、运维及实践【11.1】
第11章 质量保证、运维及实践OceanBase系统一直在不断演化，需要在代码不断变化的过程中保持系统的稳定
性。因此，合理的质量保证体系关乎系统的成败。为了保证系统质量，OceanBase做
了大量工作，在RD（指开发工程师）开发、QA（指测试工程师）测试、上线试运行
各个阶段对系统质量把关。
系统的性能和稳定性得到保障后，还需要具备良好的可运维性。OceanBase借鉴
了Oracle数据库中的“系统表”机制，将表格Schema、监控数据、系统内部状态等信息
保存到内部系统表中，从而能够基于系统表构建监控界面、运维管理界面以及运维
工具。
最后，系统只有通过上线使用才能证明自己并发现设计和实现上的不足。本章
首先介绍OceanBase的质量保证体系和运维体系，接着以收藏夹、天猫评价和直通车
报表为例介绍OceanBase系统的使用情况。最后，笔者总结了实践过程中的经验教
训。
11.1 质量保证
互联网基础产品的质量保证不只是QA的事情，从RD设计、编码开始，系统提
测，直至最后上线，每个环节都需要重视质量保证工作。OceanBase的质量保证体系
如图11-1所示。
图 11-1 OceanBase质量保证体系
一个新版本需要经过开发=＞单元测试＆快速测试=＞RD（开发工程师）压力测
试=＞系统提测=＞QA（测试工程师）接口、功能、容灾、压力测试=＞兼容性测试=
＞Benchmark测试才能最终发布，其中，RD压力测试和兼容性测试是可选的。发布的
新版本还需要经过业务压力测试或者线上流量回放才能上线试运行，试运行一段时
间后没有发现问题才能最终上线。
11.1.1 RD开发
系统Bug暴露越早修复代价越低，开发工程师是产生Bug的源头，开发阶段主要
通过编码规范、代码审核（Code Review）、单元测试保证代码质量。另外，系统提
测前RD需要主动执行快速测试（quicktest），从而避免返工。
1.编码规范
编码规范规定了函数、变量、类型的命名规则，保证统一的注释和排版风格。
除此之外，为了避免C/C++服务器端编程常见缺陷，OceanBase编码规范还制定了一
些规则，如下所示：
1）一个函数只能有一个入口和一个出口。不允许在函数中使用goto语句，也不
允许函数中途return返回。
如图11-2所示，左边的代码中途调用了return，在OceanBase编码规范中是不允许
的，可以修改为右边的方式。这条规定有一定的争议，很多优秀的开源项目都允许
函数中途return。之所以这么规定，是为了确保函数执行过程中申请的资源被释放
掉。对于分布式存储系统，代码稳定运行的重要性远远高于代码写得更漂亮。
图 11-2 单入口单出口
2）禁止在函数中抛异常，谨慎使用STL、boost。C/C++编程的麻烦之处在于资
源管理，尤其是内存管理。STL、boost库接口容易使用，能够提高编码效率，但是
内存管理混乱，不易调试，且大多数开发工程师不了解其内部实现，不适用于高性
能服务器的开发。
3）资源管理做到可控。所有的内存申请操作都需要经过OceanBase全局内存管
理器，不允许直接在代码中调用new/malloc申请内存。另外，系统初始化时启动所有
线程，执行过程中不允许动态启动额外的线程。
4）每个可能失败的函数都必须返回错误码，0表示成功，其他值表示出错。调
用者需要仔细、全面地处理调用函数返回的每个错误码。
5）所有的指针使用前都必须判空，不允许使用assert 语句替代错误检查。这条
规定是为了保证程序执行过程中出现异常情况时能够打印错误日志而不是core
dump。
6）不允许使用strcpy/strcat/strcpy/sprintf等字符串操作函数，而改用对应的限制
字符串长度函数：strncpy/strncat/strncpy/snprintf，从而防止字符串操作越界。
7）严格要求自己，编译时要开启GCC所有报警开关，例如：-Wall-Werror-
Wextra-Wunused-parameter-Wformat-Wconversion-Wdeprecated。代码提交前需要确保
解决所有的报警。
2.代码审核
OceanBase开发时要求所有代码提交前至少由一人审核，对于关键代码改动，例
如，紧急修复线上Bug，需要架构师和各个小组的技术负责人参与。
代码审核工作主要包含两个部分：编码风格审核，比如是否符合编码规范，接
口设计是否合理，以及实现逻辑审核。其中，实现逻辑审核是难点，要求理解每个
代码实现细节，并给出建设性意见。每个刚刚加入团队的新人都会分配一个师兄，
师兄的其中一项职责就是审核新人的代码，与新人一起共同对代码质量负责。
OceanBase采用开源的ReviewBoard（http://www.reviewboard.org/）作为代码审核
系统，如图11-3所示。
图 11-3 OceanBase ReviewBoard
3.单元测试
OceanBase采用google test以及google mock进行单元测试。单元测试的关键点在于
系统接口设计时考虑可测性，并提高每个开发人员的单元测试意识。
OceanBase单元测试已接入一淘网内部开发的Toast平台，每天晚上会自动回归所
有的单元测试用例。Toast平台说明文档见：
http://testing.etao.com/book/export/html/285。
4.快速测试（quicktest）
快速测试选取所有测试用例的一个子集，这个子集中的每个用例执行都很快，
从而做到快速回归。快速测试部署成定时任务，每天自动回归，RD提交某个功能的
代码之前也会主动运行快速测试，从而使得主干代码保持基本稳定。
5.RD压力测试
（1）分布式存储引擎压力测试
分布式存储引擎压力测试工具包含两个：syschecker以及mixed_test。
在syschecker工具中，多个客户端并发读写一行或者多行数据，并对读取到的每
行数据进行校验。对于每行数据，其中的每一列都对应一个辅助列，二者数据之和
为0。假设某列数据出错，syschecker能够很快检测出来。
syschecker写入速度很快，能够发现分布式存储引擎中的大部分问题，然而，
syschecker只校验单行数据，不校验多行数据之间的关系。因此，syschecker无法发现
某行数据全部丢失的情况。mixed_test正是用来解决这个问题的，它不仅对每行数据
进行校验，还校验多行数据之间的关系，能够检测出某行数据全部丢失的情况。当
然，mixed_test写入速度较慢，syschecker和mixed_test两个工具总是配合使用，各有优
势。
（2）数据库功能压力测试
数据库功能压力测试工具包含两个：sqltest以及bigquery。
●sqltest工具测试时将指定一些SQL语句，sqltest工具会将这些语句分别发送给
MySQL以及OceanBase数据库。如果二者的执行结果相同，则认为sqltest测试通过；
否则，测试失败。
●bigquery工具是sqltest工具的补充，专门用于测试OLAP并发查询功能。
bigquery中每个查询涉及的数据往往跨多个子表，能够触发OceanBase的并发查询功
能。当然，bigquery灵活性不够，只能执行特定的SQL语句，而sqltest能够执行
OceanBase支持的所有SQL语句。因此，bigquery和sqltest两个工具也是配合使用，各
有优势。
OceanBase早期测试资源严重不足，因此，要求开发在提测前必须运行一遍压力
测试。然而，这些压力测试工具的维护非常耗时。2013年开始，RD压力测试工具逐
步废弃，其中的测试用例逐步融合到QA压力测试工具中。
C语言中的宏定义，如果传入条件不成立，程序直接core dump退出。
11.1.2 QA测试
RD提测新版本后，进入QA测试阶段。QA首先快速执行一次快速测试，如果快
速测试失败，则通知RD修复问题后重新提测。否则，进入后续的接口、功能、容
灾、压力测试。如果系统设计变化较大，还需要执行专门的兼容性测试。需要注意
的是，OceanBase开发模式逐步走向敏捷化，QA往往在正式提测前就已经完成了一
部分测试用例的执行。
1.接口、功能、容灾测试
（1）接口测试
使用者通过JDBC/MySQL C客户端库访问OceanBase。由于OceanBase访问协议兼
容MySQL协议，因此，直接将MySQL数据库的官方测试工具和部分官方测试用例移
植过来测试OceanBase。
（2）功能、容灾测试
OceanBase包含很多功能，例如每日合并、负载均衡、新机器上线、主备同步、
主UpdateServer选举等。功能测试会构造场景触发这些功能，并引入各种异常，如阻
塞网络、杀死服务器进程、模拟磁盘故障等来验证系统的容灾能力。
OceanBase的接口、功能、容灾用例都实现了自动化和文本化。自动化的好处在
于无须人工介入，文本化的好处在于方便添加和维护测试用例，从而适应系统快速
开发的需要。下面是UpdateServer其中一个主备切换测试用例：
#部署一个OceanBase集群
deploy ob1=OBI(cluster=1211);
deploy ob1.reboot;
sleep 10;
#连接到其中一台MergeServer(ms0)
deploy ob1.connect conn1 ms0 admin admin test;
connection conn1;
#执行DDL(建表)以及DML语句(insert/update/delete)
create table t1(pk int primary key,c1 varchar);
insert into t1 values(2，'2_abc')，(3，'3_abc')，(4，'4_abc')，(5，'5_abc');
update t1 set c1='5_UPDATE'where pk=5;
delete from t1 where pk=2;
#读取表格内容
select*from t1;
#获取原有的主UpdateServer的地址并记录为$a
let$a=deploy_get_value(ob1.get_master_ups);
#关闭主UpdateServer并等待30秒
deploy ob1.stop_master_ups;
sleep 30;
#获取新的主UpdateServer的地址记录为$b
let$b=deploy_get_value(ob1.get_master_ups);
#读取表格内容
select*from t1;
#比较$a和$b，看二者是否不同
if($a！=$b)
{
--echo success
}
deploy ob1.stop;
执行步骤如下：
1）部署一个OceanBase集群，集群名称为ob1。
2）连接到其中一台MergeServer（ms0）。
3）执行DDL（建表）以及DML语句（insert/update/delete）。create_table语句创
建了一个包含两列的表格t1，其中，pk列为主键。DML语句对表格t1执行增、删、改
操作。
4）读取表格t1中的内容；获取原有的主UpdateServer的地址并记录为$a。
5）关闭主UpdateServer并等待30秒。正常情况下，OceanBase将自动发生主备切
换，主UpdateServer的地址会发生变化，且仍然能够正常读取表格t1中的内容。
6）再次读取表格t1中的内容；获取新的主UpdateServer的地址并记录为$b。
7）比较主备切换前后的主UpdateServer地址，看二者是否不同。
每个测试用例对应一个预期结果文件，OceanBase的测试框架将执行该测试用例
并生成一个运行结果文件。如果运行结果文件和预期结果文件完全相同，则测试用
例通过；否则，测试用例不通过，测试框架将输出预期结果文件和运行结果文件的
差异。
2.压力测试
分布式存储系统中很多问题只有在高并发或者大数据量的情况下才会出现。
OceanBase压力测试的原理是持续不断地写入数据，并在这个过程使用大量客户端读
取并验证数据。假设线上的数据量为2TB，查询次数为每秒10000次，那么，只要测
试环境的数据量为4～10TB（线上数据量的2～5倍），测试环境的读压力为每秒
20000～50000次（线上读压力的2～5倍），那么，基本可以认为系统是稳定的。
QA压力测试工具融合了11.1.1节中提到的RD压力测试工具的测试用例，且支持
自动持续回归和测试用例文本化，从而降低维护成本。另外，QA压力测试工具还支
持容灾操作，例如杀死某个服务器进程，发起主备切换，等等。
3.Benchmark测试
Benchmark测试是具有代表性的SQL语句，例如读写一行数据，读写一批数据但
不排序，读写一批数据且排序，计算count/sum/distinct，等值连接，等等。测试团队
定期发布Benchmark测试报告，如果发现系统性能相比前一次有明显提升或者下降，
需要开发团队说明其中的原因。另外，每个版本正式发布时需要提供一份Benchmark
测试报告。
4.兼容性测试
OceanBase开发过程中保证兼容应用以前使用的接口，如果系统做了较大的设计
重构，需要执行兼容性测试确保使用过的接口不会出现问题。
另外，OceanBase支持主备两个集群，系统升级时往往先升级备集群，如果没有
发现问题，才会升级主集群。升级过程中两个集群会部署不同版本的程序，兼容性
测试需要确保这种部署方式能够正常工作，且新版本出现问题时，需要能够回滚到
老版本。
11.1.3 试运行
互联网产品开发的理念是“小步快跑，快速试错”，QA测试阶段不可能发现所有
的Bug，很多问题需要等到系统上线试运行阶段才能发现。试运行部分有如下几步。
1.业务压力测试
业务第一次上线时，无法执行线上流量回放测试，此时，应用方往往会和
OceanBase团队一起对业务进行一次压力测试。OceanBase测试人员首先将应用初始
数据导入到一个模拟环境，应用方会选取几个经常使用的业务场景，对OceanBase系
统进行压力测试。
2.线上流量回放
系统试运行之前，往往需要构造环境模拟线上请求。OceanBase测试人员会将线
上环境的数据导入到一个模拟环境，并在模拟环境回放线上的读写请求。线上流量
回放工具支持回放任意倍数的线上请求，从而发现各种问题，包括接口使用、性
能、负载均衡等方面的问题。线上流量回放是OceanBase上线试运行的最后一道防
线。
3.灰度上线
系统通过了所有的测试环节便可以上线试运行了，这个过程又称为灰度上线。
如果应用从别的数据库迁移到OceanBase，那么，灰度上线阶段会同时写两份数
据，一份写到之前的系统，一份写到OceanBase，这个阶段应用方还会对两个系统的
数据进行数据比对。如果没有问题，则将读流量逐步切入到OceanBase。
如果应用从OceanBase老版本升级到新版本，那么，灰度上线阶段会首先升级备
集群到新版本，并将读流量逐步切入。如果没有发现问题，则将备集群切换为主集
群，由新版本提供读写服务，最后再升级原先的主集群到新版本。备集群切换为主
集群的风险较高，如果发现问题，需要立即切换回老版本。整个升级过程需要通过
之前提到的兼容性测试模拟
页:
[1]