【腾讯云 TDSQL-C Serverless 产品测评】Serverless集群高可用测评

2023-11-15 11:50:14 浏览数 (2)

【腾讯云 TDSQL-C Serverless 产品测评】Serverless集群高可用测评

在这里插入图片描述在这里插入图片描述

@TOC

一、前言

最近在CSDN看到腾讯云的 TDSQL-C ServerLess Mysql 数据库体验活动,作为云原生的Serverless数据库,还是很有兴趣的,看文档中TDSQL-C Serverless Mysql提供了集群高可用的功能,我们通过实际测试来验证一下它的可靠性,具体如何测试,请看下文!

二、Serverless介绍

大家都知道,随着互联网技术的发展,应用架构模式也在不断演进。Serverless作为一种新的架构模式,正在风靡IT界。

Serverless的核心思想就是:开发者不再需要购买和管理服务器实例,也不需要根据流量变化来进行弹性扩容缩容。而是通过代码触发事件驱动计算,系统会自动弹性伸缩基于使用量付费的计算资源。

比如,开发者只需编写业务代码,将代码部署上云,然后就可以访应用了。应用启动和关闭,计算资源的调度,都是由底层平台完全来完成。开发者完全摆脱了对硬件和基础架构的管理。

这跟传统的有服务器架构形成鲜明对比。传统架构要求开发者购买服务器,部署软件,开启和关闭实例,手动进行弹性扩缩容等运维工作。耗费大量时间成本。

Serverless做到"无服务器",开发效率得到大幅提升。且只为真实产生的请求计费,可以显著节省IT项目成本。这也是它为什么这么火。

下面是 Serverless 的一些应用场景:

在这里插入图片描述在这里插入图片描述

三、TDSQL-C Serverless Mysql介绍

随着Serverless技术的不断成熟, TDSQL-C Serverless Mysql 就是一款完全Serverless的数据库,它可以根据业务自行扩缩容,设计理念就是「无服务器」,由于他是Serverless架构,所以它也继承了 Serverless的所有优点

  • 计算资源可以由系统自动弹性伸缩,开发者无需管理服务器;
  • 数据存储使用分布式机制,自动进行数据分片与扩容;
  • 集群高可用,即使节点异常也能保证读写通过快速切换
  • ...等等

TDSQL-C ServerLess Mysql 的整个产品架构如下所示:

在这里插入图片描述在这里插入图片描述

因为 TDSQL-C Serverless Mysql 数据库拥有Serverless的众多特性,所以在很多领域都可以使用,类似于我们的自动伸缩业务,经常做活动,不希望晚上资源浪费等,以下常见常见都可以采用 TDSQL

在这里插入图片描述在这里插入图片描述

四、集群可用性测试

我们采用3节点的TDSQL-C集群,然后使用压测工具对写入节点进行高并发读写操作,期间会对只读节点进行移除和增加,也同时会对CCU的自动扩缩进行观察。本来是希望把节点部署到多个可用区域的,但是发现 Serverless 集群不支持多个可用区部署,也就是集群节点都在同一个区域,这个有可能是因为所有的节点都共享同一份数据的缘故。

4.1、集群搭建

在这里插入图片描述在这里插入图片描述

环境说明:

  • mysql8.0
  • 3节点 1写2读
  • serverless架构 集群版

直接购买下一步即可完成集群的搭建,非常方便,不需要我们像传统集群搭建,需要自己去配置网络以及协议等

进入集群详情页即可看到我们的集群情况,这里我们需要把读写实例和读写组的公网访问开启一下

在这里插入图片描述在这里插入图片描述

写实例的开启的逻辑很简单,因为作为数据的唯一写入入口,必须得暴露出来给上层使用,为什么读节点只需要开只读组呢?只读组会将只读节点全部统一成一个入口,也就是查询只需走只读组的入口,不需要我们再去应用层设置负载均衡,TDSQL-C Serverless Mysql 会自动进行转发,读数据使用读写组即可进行数据访问,中间的负载器会自动进行性能负载

  • 创建测试数据库

通过 DMC 进行数据库创建,DMC 是腾讯云为开发者提供的 Web 在线数据库管理平台,非常方便好用!

在这里插入图片描述在这里插入图片描述

4.2、测试环境准备

这里我们主要以 Sysbench 为出发点,对节点异常测试,作为一款广泛使用的开源模块化的、跨平台、多线程基准测试工具,sysbench主要用于评估计算机系统在不同负载条件下的性能表现。

  • 安装
代码语言:shell复制
curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.deb.sh | sudo bash
sudo apt -y install sysbench
  • 进行基础测试
代码语言:shell复制
sysbench --db-driver=mysql --mysql-host=gz-cynosdbmysql-grp-r3i3tnbl.sql.tencentcdb.com --mysql-port=25742 --mysql-user=root --mysql-password='a.' --mysql-db=abc --events=0 --table-size=50000 --tables=10 --threads=500 --time=300 --percentile=95 --report-interval=1 oltp_write_only prepare

这个命令是使用sysbench工具执行OLTP(联机事务处理)的读写基准测试。解释如下:

  • --db-driver=mysql: 指定使用MySQL数据库驱动程序。
  • --mysql-host: 指定MySQL数据库的主机名或IP地址。
  • --mysql-port: 指定MySQL数据库的端口号。
  • --mysql-user: 指定连接MySQL数据库所使用的用户名。
  • --mysql-password: 指定连接MySQL数据库所使用的密码。请将password替换为实际的密码。
  • --mysql-db=abc: 指定要在MySQL数据库中使用的数据库名称。
  • --table-size=50000: 指定每个表的数据量大小,这里设置为50000。
  • --tables=10: 指定要创建的表的数量,这里设置为10。
  • --threads=500: 指定并发线程数,这里设置为500,表示将使用500个并发线程执行测试。
  • --events=0: 指定要执行的事件数量,这里设置为0,表示不限制事件数量。
  • --time=300: 指定测试运行的持续时间,这里设置为300秒(5分钟)。
  • --percentile=95: 指定报告中的百分位数,这里设置为95,表示将计算并报告第95百分位的响应时间。
  • --report-interval=10: 指定报告输出的时间间隔,这里设置为10秒,表示每秒输出一次测试结果。

我们执行后将使用500个线程在10个表上执行写入操作,每个表的大小为50000行数据,持续时间为300秒(5分钟)。测试结果将包括第95百分位的响应时间,并每10秒输出一次报告。

在这里插入图片描述在这里插入图片描述

但是在开始执行的时候发现了一个错误,这里主要是最大连接数量太小了,我们去TDSQL参数那里配置一下即可:

在这里插入图片描述在这里插入图片描述

这里要注意,因为我们是3个节点,所以每个节点的最大连接数都需要修改,不能只修改读写节点的,修改完这个参数后,我们执行预测试命令

在这里插入图片描述在这里插入图片描述

通过 DMC 我们可以看到它帮我们建立10个表,每个表中5w条数据

在这里插入图片描述在这里插入图片描述

然后我们要进行集群可用性测试了,我们的流程是这样,两台安装了 sysbench 的服务器,一台进行写测试,一台进行读测试,然后我们将手动关闭掉一台读节点,观察集群稳定性,再次期间我们还会重新把移除的节点重新加入集群中,看看是否能正常负载

4.3、可用性监测

  • 第一台 sysbench 服务器执行(要注意这个是可写的host)
代码语言:shell复制
sysbench --db-driver=mysql --mysql-host=gz-cynosdbmysql-grp-r3i3tnbl.sql.tencentcdb.com --mysql-port=25742 --mysql-user=root --mysql-password='a.' --mysql-db=abc --events=0 --table-size=50000 --tables=10 --threads=500 --time=300 --percentile=95 --report-interval=1 oltp_write_only run
  • 第二台 sysbench 服务器执行(要注意这个是只读组的host和port)
代码语言:shell复制
sysbench --db-driver=mysql --mysql-host=gz-cynosdbmysql-grp-ne3hquxn.sql.tencentcdb.com --mysql-port=25741 --mysql-user=root --mysql-password='a.' --mysql-db=abc --events=0 --table-size=50000 --tables=10 --threads=500 --time=300 --percentile=95 --report-interval=1 oltp_read_only run

run 的时候可能还会出现这个错误:

在这里插入图片描述在这里插入图片描述

我们也将可预编语句最大值修改一下 max_prepared_stmt_count

在这里插入图片描述在这里插入图片描述

两个节点同时运行测试:

  • 写测试 在这里插入图片描述在这里插入图片描述
  • 读测试
在这里插入图片描述在这里插入图片描述

4.4、观察集群CCU扩缩情况

在这里插入图片描述在这里插入图片描述

这里因为只读节点还没使用超过 0.5 的CCU,所以没有在进行自动扩缩,不过可以看出读写节点已经开始扩缩了

4.5、观察集群性能的负载均衡情况

  • CPU:
在这里插入图片描述在这里插入图片描述
  • 内存 在这里插入图片描述在这里插入图片描述读方面的分流是比较均衡的,每个只读节点承受的压力都差不多4.6、观察移除1个只读节点负载情况

因为没有办法直接销毁节点,所以这里我选择直接 重启,重启会断开这个实例的所有链接,我们就观察断开的那瞬间流量是否有j进行重新负载

在这里插入图片描述在这里插入图片描述

这里因为没有销毁,所以我一直在重启,看的效果不是特别明显,但还是能看出大概

在这里插入图片描述在这里插入图片描述

其中整个读测试 err 都是 0,整个服务没有受到一点影响

在这里插入图片描述在这里插入图片描述

测试总结

最终根据测试结果显示,三个节点的CPU内存利用率都进入安全的可控范围内,性能的增加 CCU 也随之扩容,也体系了自动扩缩特点,当节点异常下线时,系统会自动切换到其他节点,读写依然持续正常;当节点增加时,系统也会自动将读节点进行负载,使得整个系统性能达到平衡。因为整个集群共享同一份数据,所以也未发生数据不一致情况。

总结

希望TDSQL-C Serverless Mysql 可以考虑让用户自己去选择增删只读节点,控制性更强,不过整体体验还是非常高效的!

通过本次测试,我们可以看到TDSQL-C Serverless集群在高并发下的出色表现,即使节点发生故障也能保证服务高可用。它完全实现了无需DBA的理想状态。此外,在使用 TDSQL-C Serverless Mysql 的过程中,我发现它除了高可用很牛逼外,还有很多其它的优点,例如:

  • 性能出色,单节点支持数百万级QPS
  • 存储超大,支持PBPB海量数据量
  • 功能兼容MySQL,无需修改源代码就可以轻松迁移
  • 安全可靠
  • 成本低,按实际使用流量收费,不消费不付费

总而言之,它可以完全释放了DBA的管理成本,是业务系统一个很好的数据库选择方案,大家可以根据自己的业务情况酌情挑选。如大家对文章有疑问请随时指出,我将尽量解答。也欢迎大家一起来讨论 TDSQL-C Serverless Mysql 数据库。

0 人点赞