在双11大促中的数据库服务器

首先我先说我所在的这家公司,他并不是像淘宝京东那样的,一线的综合性电商公司,但是他也是一家龙头企业,

我们先来看这家公司的数据库架构是什么样的,说起来这家公司的数据库架构呢,是很简单的,也是一家十分常见的

数据库架构,相信跟大多数公司,使用数据库架构是十分相似的,这家公司的所有的数据库呢,全都集中在一台服务器上,

而这种服务器呢,是由15个从所组成的架构,当初这个架构呢,这里的从服务器可能没有画这么多,但是也只是表示他

很多的意思,现在看到的架构呢并不是现在的架构了,就是双十一之前的架构,后来经过DBA和开发员的努力呢,给他进行了

一些修改,具体怎么修改我们下面回来谈的,但是我们先看这个架构会有什么样的问题,首先在这个主服务器和主从的一个集群

中,就存在一个master服务器,也就是只有一个主数据库服务器,没有任何高可用的主从复制文件,也就是一旦主服务器一旦出现了

故障

很难自动进行故障切换,我们必须由DBA手动的,从众多的从服务器中选择一台数据最多的从服务器,

手动的把它提升为主服务器,并且对其他的从服务器呢,再进行同步

然而这个操作过程是相当耗时的,我们的从服务器比较多,所以完成一次切换可能要耗费半个小时左右的

时间,而且这个从服务器,在这么大的业务量的时候

在这种业务量大的时候呢,对主服务器的容量也是一个比较大的挑战,而这个网卡的容量呢,也的确在

今后引起一定的故障

那么大家了解这个架构之后呢,我们就可以看看在双十一大促的时候,我们对数据库集群的一个监控信息,

通过监控信息,我们就可以了解到,具体是什么因素影响了我们数据库服务器的性能,首先我们来看这个监控图

显示了在大促时期的服务器QPS和TPS的数量,大家要注意的是,我这个监控图呢,只显示了一台主服务器上的监控数据,

这个主服务器的性能还相当不错的,当时还是比较好的服务器硬件了,大概是64核CPU,512G的内存,所以QPS和TPS的数量

还是相当不错的,大家可以看到,最高峰时QPS数呢,也就是每秒的查询数量呢,也超过了35万次,而每秒的TPS数呢,最高峰

也超过了5万次,将近10万次的样子,相信在大多数的应用环境当中,是比较高的吞吐量了,之所以能有这么高的吞吐量呢

是因为我们之前对这个服务器做了大量的优化,起码来说SQL性能是相当好的,所以QPS和TPS才可能达到这么高,

除了QPS和TPS之外呢,我们在看看下面一些监控图,这个监控图是对并发数量和CPU数量使用率来进行的一些监控

并发量是指数据库在同一时间处理的请求的数量,这个指标常常会和连接数想混淆,同时可以有上千或者几千个连接,

但是这里只有一小部分是在处理的,通常大量连接是处理sleep状态

从上面的这张图不难看出,这台数据库的并发请求呢,最大已经操作700,同时CPU也达到了百分百的程度,

这里要说的idle这个指标,这个指标是指的空闲的百分比,这个值超高就是使用CPU的空闲率越高,比如说

这个值如果达到90%,就是空闲达到90%,而不是繁忙度达到百分之九十,这个大家一定要注意

接下来咱们来看看磁盘IO的数据,这张图就是当时的读写,大家看到这个磁盘读写是相当高的,这里还要说明的一点就是,

当时这个服务器上的磁盘呢,使用的是fashion IO的设备,所以他的吞吐量要比普通的磁盘要大很多

从上面这张图不难看出,就是这么高的QPS和TPS,磁盘的IO能力还是很不错的,但是从上面这张图中呢,

我们也可以清楚地看到,磁盘的读有很高的峰值,发生在凌晨2点半左右的时间,这是什么原因呢,这个双十一

当时给我们带来了很大的恐慌,因为这可能意味着服务器性能的急剧的下降,则造成大量的阻塞

在当时呢我们对服务器及时的进行了检查,发现这个峰值是由于一个数据库备份的远程同步计划任务所造成的,

所以这就给了我们一个教训,最好不要在主库上进行数据库备份,或者在大型活动之前呢,先停止严重对性能的

影响的任务

最后

以上就是飞快歌曲为你收集整理的在双11大促中的数据库服务器的全部内容，希望文章能够帮你解决在双11大促中的数据库服务器所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。