PolarDB 单实例多租户模式介绍（三）

租户CPU资源限制动态修改测试

此次测试中，我们创建多个resource_config，在租户执行sysbench 测试时，动态修改租户对应的resource_config，观察CPU以及QPS变化

# 创建多个不同的resource_config
create resource_config r1 min_cpu 0 max_cpu 1;
create resource_config r2 min_cpu 1 max_cpu 2;
create resource_config r3 min_cpu 1 max_cpu 4;
create resource_config r4 min_cpu 1 max_cpu 6;
create resource_config r5 min_cpu 1 max_cpu 8;

通过之前创建的租户tenant_1 下user_1进行 sysbench 测试

# sysbench 准备数据
sysbench oltp_read_only  --threads=512 --mysql-host=xxxx  --mysql-user=user_2@tenant_1 --mysql-password={password} --mysql-db=sbtest --tables=10 --table-size=50000   --report-interval=1 --time=7200  prepare

# sysbench 执行测试
sysbench oltp_read_only  --threads=512 --mysql-host=xxxx  --mysql-user=user_2@tenant_1 --mysql-password={password} --mysql-db=sbtest --tables=10 --table-size=50000   --report-interval=1 --time=7200  run

在sysbench 测试过程中，tenant_1 所绑定的resource_config 变化顺序为： r1->r2->r3->r4->r5->r4->r3->r2->r1 测试过程中，实例规格对应的CPU & QPS变化过程为： RW-CPU：

RW-QPS：

RO-CPU:

RO-QPS：

观察此次测试结果，可以看到PolarDB 单实例多租户模式能够通过调整租户所绑定的资源配置来达到动态调整资源限制的效果，这使得客户可以更方便的控制租户间的资源分配。

租户间资源隔离对比测试

此次测试中，我们在租户/非租户 两种模式下进行对比测试，以此来模拟比较在其他业务突发高流量时，关键业务QPS的变化情况。

1. 非租户模式下，某一user A 执行测试，另一user执行高线程测试，观察user A的qps变化过程
2. 租户模式下，user A在独占租户下执行测试，另一个租户下 user执行高并发测试，观察user A的qps变化过程

非租户模式下并发测试

1. 使用高权限账户进行 64 线程并发的 sysbench测试，此时观察到qps平均为230000

2. 在高权限账号在进行 64 线程并发测试的同时，在另一终端使用高权限账号进行线程为512的sysbench测试，观察到64线程并发测试的qps 由230000降低到50000 左右。

多租户模式下并发测试

1. 创建此次测试所需要的resource config

# 创建不同的resource config
create resource_config r6 min_cpu 2 max_cpu 2;

2. 通过文档之前提到的方式来创建租户以及租户下user a. tenant_1 与 tenant_2 租户都绑定resource config r6

3. tenant_1 下的user_1 执行sysbench 测试

sysbench oltp_read_only  --threads=64 --mysql-host=xxx  --mysql-user=user_1@tenant_1 --mysql-password=xxx --mysql-db=sbtest --tables=10 --table-size=50000   --report-interval=1 --time=7200 run 

4. tenant_1 下user_1 执行sysbench的同时，tenant_2 下user_1同时执行并发线程为512的sysbench 测试

sysbench oltp_read_only  --threads=512 --mysql-host=xxx  --mysql-user=user_1@tenant_2 --mysql-password=xxx --mysql-db=sbtest --tables=10 --table-size=50000   --report-interval=1 --time=7200 run

观察到 tenant_1 下的 user_1 的sysbench 测试性能有155000左右下降至134000 左右。

通过在租户/非租户两种模式下的比较，能够看出在租户模式下，通过分配给固定资源给关键业务，能够保证在其他业务突发高流量时，关键业务仍然能够有足够资源保持稳定处理能力。

共享租户资源隔离测试

共享租户执行测试，观察CPU以及 qps随着独占租户的增加，导致CPU发生变化的测试

1. 新建多个resource_config，用来控制独占租户的min_cpu

# resource_config r1,r2,r6 已经存在
# create resource_config r1 min_cpu 0 max_cpu 1;
# create resource_config r2 min_cpu 1 max_cpu 2;
# create resource_config r6 min_cpu 2 max_cpu 2;

create resource_config r7 min_cpu 4 max_cpu 4;
create resource_config r8 min_cpu 6 max_cpu 8;
create resource_config r9 min_cpu 7 max_cpu 8

2. 通过高权限账户（sys 租户使用共享租户的资源）执行sysbench 测试

sysbench oltp_read_only  --threads=512 --mysql-host=xxx  --mysql-user=xxx --mysql-password=xxx --mysql-db=sbtest --tables=10 --table-size=50000   --report-interval=1 --time=7200  run

3. 在高权限账户执行sysbench测试期间，通过修改租户tenant_1 绑定的resource_config 资源来观察共享租户的资源隔离情况，tenant_1的resource_config 更改顺序为r1->r2->r6->r7->r8->r9->r8->r7->r6->r2->r1

RW-CPU：

RW-QPS:

RO-CPU:

RW-QPS:

观察此次测试结果，可以看出共享租户所能使用的资源随着独占租户的资源变化而进行变化，这保证了独占租户使用资源的独占性，保证独占租户任意时刻资源不被侵占。

总结

PolarDB MySQL 单实例多租户模式的推出，使得客户能够以简单的方式使得多个租户在同一实例下共享计算/存储资源，同时保证各租户下的数据隔离，保证租户仅能访问到自己的数据，以及各租户下的资源隔离，确保租户间不会出现资源争抢，保障业务稳定运行。 PolarDB MySQL 单实例多租户模式解决了以下一些客户广泛存在的业务痛点：

1. Saas多租户业务场景需要为每个租户创建不同库/表，业务代码需要针对每个租户进行适配。
2. 关键业务在其他业务突发流量时无法保证资源分配，导致关键业务处理能力受到影响。