停课不停学,云数据库如何支撑好数千万学生上课–云惠网

avatar
avatar
云惠网小编
2077
文章
0
评论
2020年4月30日08:27:16 评论 39 次浏览 7438字阅读24分47秒
摘要

作者:钱颖(腾讯课堂研发团队)

作者:钱颖(腾讯课堂研发团队)

疫情停倮以来,腾讯课堂助力全国数百万老师和数千万学生在线教学、听课。已有3000多个线下教育机构申请入驻腾讯课堂。这背后,离不开腾讯课堂可支持百万人同时在线上课、网络延时低至百毫秒级、1080P直播高清视频、秒级扩容服务海量用户等优势。

腾讯课堂业务(包括核心业务、非核心业务)大量使用了云数据库,如果DB性能波动,对现网业务会存在很大影响。比如核心业务——用户进入直播间行为,当DB存在波动时,会导致现网大批量用户无法进入直播间学习,影响巨大。

疫情突发,还没等做好准备,就需要迎接上千万的流量考验。腾讯课堂的研发、运维和云数据库团队在业务发展过程中,持续优化DB的性能瓶颈问题。

简要总结下,主要的优化方法有以下九点:

1)扩容RO组

2)拆分主库

3)数据库压测

4)慢查询优化

5)连接数优化

6)主从同步延迟优化

7)高负载优化

8)监控与告警

9)借助腾讯云数据库智能管家进行主动巡检

以下是腾讯课堂对数据库的详细案例和方法总结。

1 扩容主库DB的RO组,紧急应对流量考验

RO组是指只读库,一般可以通过设置主从数据库实现读写分离,主数据库负责写操作,从数据库负责读操作,根据压力情况,从数据库可以部署多个提高“读“的速度,借此来提高系统总体的性能。

课堂主库DB的RO组从1个RO组增加到多个RO组。每个RO组分别提供给不同的业务服务模块读。

服务模块中,为了服务能够快速响应用户的需求,在业务进程启动时,将DB数据全量加载到内存。业务进程服务运行过程中,将DB数据增量更新到内存的服务。

疫情期间服务扩容,读取主库的主进程服务已经部署了数千台机器,这么多机器来拉取DB的数据,对DB来说无疑是压力巨大。因此,增加的RO组有一些是专门用来进行主进程服务数据的加载。另外一些RO组则专门用来处理现网业务读请求。避免主进程服务数据的加载影响到现网的正常请求响应。

1.1 增加RO组遇到的问题

一个DB的主数据库,并不是可以无限挂载多个RO组的。因为RO组增加过多,会增加主库的负载。多增加一个RO实例,主库需要多发一份BINLOG到备机上,等同于多了一个发送BINLOG的线程,对主库的CPU/内存/网卡/IO等都会有影响。

虽然从上面贴出的架构图中看,我们的RO组只增加至多个RO组,但是每个RO组下面会挂2-3个实例,实际上主数据库挂载了众多从机数据库。如果再增加新的RO组,对于主数据库来说负载可能会比较大,需要综合考虑主库的各种负载因素。

1、案例1

【问题发现】

部分RO组出现了主从同步延迟告警。

【处理过程】

(1)查看RO库负载飙高,网卡出现等待,存在全表扫描的SQL。

(2)该RO组是业务用来全量加载DB数据到服务缓存中,已被独立出来,不影响在线业务。

(3)去掉该RO组的主从同步告警。

1.2 拆分主库DB,分离DB压力

课堂的主库DB是历史包袱之一,主库DB里面包含了很多不同功能的DB表(资料侧、数据搜索等),导致各种业务请求都会读写主库DB。不仅不同功能业务之间会相互影响,同时DB负载也会很大。

在这次疫情期间,课堂的不同功能业务分批次从主库拆分出来,避免业务之间相互影响,同时保证主库的负载正常,核心业务功能稳定提供服务。

2 DB在业务高峰期遭遇的各种问题

经过上面的主库DB紧急扩容RO组,课堂DB抗住了日益增长的流量突增考,包括主库DB慢查询猛增,连接数猛增,主从同步延迟等。

2.1 慢查询突增,怎么定位和防治?

慢查询是DB运营过程中遇到最多的问题,同时慢查询也是最难定位原因的问题。

因为慢查询出现时候的表现都是DB突然慢查询增多,查询当时的慢查询日志,会有很多SQL都变成慢查询,然而这些SQL可能是被某个慢查询带起来的(正常情况下,普通执行SQL是不会变成慢查询的),也有可能是因为DB负载变高,出现很多慢查询,需要具体问题具体分析。

2.1.1 课堂每日压测中发现的DB慢查询问题

【问题发现】

课堂每天在业务低峰斯都会对业务进行全方位的压测,在压测时可以压出DB的性能问题,譬如慢查询飙高。

【处理过程】

(1)找出TOP的慢查询SQL。

(2)业务分析慢查询,进行优化。

【优化方法】

(1)【拆分DB】相对独立的业务DB从主DB中拆分出来,独立部署。

(2)【切换RO组】非核心流程Select语句,对主从同步延迟容忍较高,切换RO组,不影响主机负载。注意Update/Insert/Delete等修改语句不能切换到RO组,会引起主备不一致,如果RO组开了只读,则修改SQL在RO组操作会失败。

(3)【添加索引】可以进行添加索引优化的SQL,添加索引优化,注意添加索引不要在高峰期进行,避免对主机DB负载和主从同步有影响,需要在低峰期进行。

SQL优化的案例可详见各种优化方法。

课堂在疫情期间,专门跟进主库DB的慢查询SQL,推进开发处理解决。

2.1.2 一些课堂DB运营过程遇到的慢查询案例

1、案例1

【问题发现】

主机慢查询飙高

【处理过程】

(1)查找慢查询SQL,发现全是UPDATE/INSERT。

(2)KILL慢查询,但是业务还没有停掉,导致慢SQL一被KILL,又全部重新连上。

(3)业务停掉了UPDATE/INSERT大并发执行的服务后,DB慢查询和负载逐渐恢复。

【原因分析】

(1)找出慢查询TOP SQL, 以及发生问题时间段(包括出现告警之前)的慢查询日志。发现有一批更新在线课堂和和统计在线课堂的SQL请求。

(2)业务层面是大批量心跳DB操作失败,导致老师同一个时间点全部退房,然后老师狂刷上课请求,上课请求的DB操作很耗时,结果引发慢SQL雪崩。

核心问题:心跳SQL为什么在DB正常的时候,出现失败?

(3)分析慢查询日志发现在慢查询告警之前有其他慢SQL,执行10s+,扫描几百万行。当时的上课业务请求有出现超时。

(4)SQL的事务间有锁冲突。

【解决方案】

(1) 先暂时停掉非核心慢SQL。

(2) 分析一天内超过10s的慢查询,和具体业务模块负责人确认是否可以强Kill,确认OK后,设置自动Kill。使用select sleep(12); 验证是否可以自动Kill。

(3) 准备按正则Kill SQL的工具,类似上面的3个雪崩SQL,可以输入SQL正则停止。

2、案例2

【问题发现】

出现慢查询告警

【处理过程】

(1)查询慢查询日志,表现是:Select查询突增

(2)观察DB日志,发现根本原因是某条Update语句有死锁。统计发现Table_locks_immediate达到1K多。互相死锁的两个SQL都来自业务服务。

分析原因为:

· 功能:业务服务有定时任务,通过心跳刷新上下课时间和更新时间,来更新直播状态。

· 问题点:该模块下有几十台机器会同时执行定时器逻辑,会产生排它锁。

· 影响点:如果产生X锁,会导致Select也卡死,进而影响整个表和DB(影响比较严重,如果该表锁住,直播状态无法更新)

解决方案:

· 【服务拆分】将该服务拆分,有定时器的版本只处理对账逻辑,无定时器的版本处理现网功能

· 【分离部署】对定时器的版本和无定时器版本的服务,分别单独部署服务器

3、案例3

【问题发现】

出现慢查询告警

【处理过程】

(1)查找慢SQL。

SELECT * FROM t_xx_info WHERE f_update_time>'2020-03-01 08:30:16' and f_trans_state=12 AND f_o_lock = 0 AND f_retry_nums < 5 ORDER BY f_update_time  limit 100 for update  

上一条语句的Select For Update 会加锁,容易造成锁等待。

【解决方案】

业务进行优化SQL处理。

· 【优先恢复】停掉服务。慢查询被Kill掉,但是服务请求存在,慢查询就会一直死灰复燃。

· 【SQL优化】优化for update语句,不进行加锁。慢SQL添加索引优化。SQL逻辑优化。f_update_time 范围目前为15day,可以缩短至3day。

· 【读写分离/拆分DB】业务能够容忍偶尔主从同步延迟的话,纯粹的Select语句改读备机,不影响主机负载。业务不能容忍主从同步延迟的话,可以单独从主库中切出,不影响其他业务。

2.1.3 DB慢查询处理和防治总结

【处理】

(1)【优先恢复】先快速KILL掉慢查询,如果是服务请求引起的慢查询,需要停掉服务,避免慢查询死灰复燃。

(2)【原因查找】定位引发慢查询的深层原因,需要具体问题具体分析。找出问题后,解决问题,避免下次出现同样事件。

【防治】

(1)【监控告警】DB慢查询实时监控告警。

(2)【自动Kill SQL】主库DB配置超10s的select查询SQL自动Kill, 因为DB出现严重慢查询的时候会出现雪崩现象,该策略主要是防止出现慢查询时,DB彻底被压垮。

(3)【拆分DB】相对独立的业务DB从主DB中拆分出来,独立部署。

(4)【切换RO组】非核心流程Select语句,对主从同步延迟容忍较高,切换RO组,不影响主机负载。注意Update/Insert/Delete等修改语句不能切换到RO组,会引起主备不一致,如果RO组开了只读,则修改SQL在RO组操作会失败。

(5)【添加索引】可以进行添加索引优化的SQL,添加索引优化,注意添加索引不要在高峰期进行,避免对主机DB负载和主从同步有影响,需要在低峰期进行。

(6)【业务优化】业务根据自身的情况,进行优化SQL

2.2 连接数猛增,怎么处理和防治?

DB连接数猛增的原因也是多种多样,例如服务在扩容时,一次性扩容很多机器,同时连接DB,就会导致连接数瞬间爆掉,又例如业务服务存在bug,DB连接泄露,也会导致DB连接数猛增。

幸运的是,连接数的问题要比慢查询容易处理很多。

2.2.1 一些课堂DB运营过程遇到的连接数案例

1、案例1

【问题发现】

主机连接数告警 & 大部分RO组主从同步异常

【处理过程】

(1)重启主库,恢复连接数和RO组的主从同步。

(2)原因:业务扩容了几百个服务svr,同时启动导致DB连接数爆掉。每个服务svr占用30个连接,主库DB的连接数最大值是8000,超过阈值。

(3)业务分批启动,主库连接数仍会爆掉。业务切RO组解决问题。

2、案例2

【问题发现】

主机DB连接数增多

【处理过程】

(1)SHOW PROCESSLIST,根据来源IP来查看DB的连接数。

select client_ip, count(client_ip) as client_num from (select substring_index(host,':' ,1) as client_ip from processlist  ) asconnect_info group by client_ip order by client_num desc limit 5

(2)登录TOP来源的机器上,netstat查看是哪个服务的连接数较多。使用root账户执行以下命令,可以看到是哪个服务连接DB较多。

netstat -nalp | grep 120:3319 

(3)业务评估该服务可重启,先手动重启服务恢复DB连接数。重启之后,DB连接数下降。但过了一会儿,DB连接数又上涨了,发现是服务代码存在DB连接泄露的问题。

(4)解决方法:

· 临时方案:安装服务的定时重启脚本,每隔20min重启一次,当连接池泄露的时候重启,重启后DB连接恢复。

· 根本方案:解决服务代码的连接泄露问题。

2.2.2 DB连接数处理和防治总结

【处理】

(1)【SHOW PROCESSLIST】SHOW PROCESSLIST查看连接数最多的业务来源,停掉服务或者其他处理,避免连接数增加过多

(2)【DBA处理】当DB连接数爆掉的时候,需要运维介入,重启恢复。 【防治】

(1)【监控告警】配置DB连接数的告警,有异常及时发现并处理。

(2)【扩容注意】业务扩容非线上紧急,低峰期进行。线上紧急扩容,需要全面考虑存储层、服务调用上下游链路、机器性能等方面的影响。

(3)【连接池】服务代码需要考虑DB连接的数量,尽量使用DB连接池,不要使用短连接。使用短连接的话,服务请求量突增,会导致DB连接数猛增。同时,使用连接池也需要根据DB连接数的配置大小,合理设置服务连接池的大小。

(4)【切换RO组】如果主机的连接数已经无法满足业务需求,可以考虑把Select等只读的请求切换到RO组。

连接上DB之后,可以使用下面的命令查询DB连接数的配置大小。

show variables like 'max_connections';

2.3 主从同步延迟,怎么处理和防治?

主从同步延迟疫情期间,并没有成为DB运营中最头疼的问题,出现的主从同步问题基本对线上业务无影响。

2.3.1 一些课堂DB运营过程遇到的主从同步延迟案例

1、案例1

【问题发现】

主从同步告警

【处理过程】

(1)DBA帮忙查找SQL

DELETE FROM t_xxx_day WHERE ETL_STAMP='2020726736_20200312';   
DELETE FROM t_xxx_day WHERE ETL_STAMP='2020726736_20200312';  

(2)业务有定时TDW任务,每天早晨执行,因为不影响线上业务同时业务需要TDW任务,未进一步处理。

2、案例2

【问题发现】

DB的备机主从同步延迟

【原因定位】

(1)备机上日常的备份会产生全局读锁。备份快结束的时候会获取一次锁。这个锁正常会很快结束的,但如果这个DB上有很多慢查询,就会导致锁一直等待。所以延迟就会越来越大。

(2)数据库里面有很多MyISAM表,每次备份都需要全实例锁定备份,备份期间从库不能更新,导致主从会有延迟,这也是个比较大的风险点。

(3)备份资源是有限的,实例比较多,实例发起备份之后需要排队,而且每次分配的备份机器性能有差异,性能差的备份机器可能会出现主从延迟。

【备机主从同步预防方案】

(1)【使用RO组】将数据实时性要求较高的查询放在RO组,而非DB的备机。 大查询放在冷备机不太合适。会一直阻塞备份获取锁。每天的备份失败风险也比较高。

(2)【MyISAM引擎->INNODB引擎】数据库表的存储引擎考虑INNODB。备机上MyISAM表比较多,备份时持有锁的时间长,也会导致主从同步延迟一直较高。INNODB表的查询效率没有MyISAM高,但差别不会很大。

业务从MyISAM->INNODB时需要注意,大表操作需要在低峰期进行。

1)修改期间主库会锁表。

2)修改期间主从会有延迟,包括RO库。

2.3.2 主从延迟处理和防治总结

【处理】

(1)【DBA处理】需要DBA介入,帮忙恢复主从同步延迟。

(2)【业务处理】主从同步延迟来源自业务的SQL操作,停掉服务或者其他处理,避免主从同步延迟产生影响。

【防治】

(1)【监控告警】RO组主从同步监控告警

(2)【SQL操作谨慎】主库避免在业务高峰期进行大量数据的Delete/Update/Insert/创建索引/添加字段等操作。课堂主库使用的MySQL版本数据库,修改操作在主库是并发执行,然而在RO组是串行执行,这会使得RO组追上主库花费的时间更多。

(2)【连接数】主库的连接数控制在合理范围。如果主库连接数爆了,RO组和主库通信的BINLOG进程也断开连接,将会出现主从延迟问题。

(3)【使用RO组】对于数据延迟非常敏感的业务,建议放在主库进行读取。对于数据延迟不是很敏感的业务,可以放在RO组进行读取。不建议使用DB的备机来读取。

2.4 DB CPU居高不下,怎么办?

2.4.1 现网案例

【问题发现】 DB CPU飙高

【处理过程】

(1)慢查询日志查找TOP SQL和来源IP。

SELECT t_x FROM t_xxx WHERE (t_x = '' OR t_x IS NULL)  ORDER BY  t_updatetime DESC LIMIT 10

这个SQL较多,且未命中索引。 手动执行速度不慢。

(2)猜测: DB存在缓存: 业务将这些Limit 10的数据从物理盘load进到内存了,所以我们手动执行其实读的是内存,所以快。 是否因为表太大,导致Select变慢,需要分库或者分表?

但是DB表的数据量每天增长正常,

实际原因为有一条手动执行的SQL,一直执行了9w秒左右,导致cpu一直很高。

2.4.2 DB CPU处理和防治总结

【处理】

(1)【SHOW PROCESSLIST】如果DB CPU一直居高不下,大概率影响的SQL还在,可以SHOW PROCESSLIST查找到,并Kill

(2)【慢查询日志】如果CPU飙高了一下就恢复,可以通过慢查询日志看CPU飙高的时候有没有大量慢查询

【防治】

(1)【监控告警】DB CPU告警监控,及时发现问题

(2)【自动Kill SQL】Select SQL超过10s,自动Kill

3 DB运营总结

DB运营中业务可进行的处理有以下几种:

下面的思维导图总结了上面提到的DB慢查询、连接数、主从同步延迟、CPU问题处理和防治方法。

4 DB监控告警

4.1 DB监控指标

课堂在疫情期间主要监控了DB的连接数、慢查询数、主从同步时间、CPU负载,如果上述指标存在异常,则会告警提示。选择监控上述指标的原因,是DB出现问题时,这些指标能够及时感知。

4.2 DB监控方式

DB监控方式主要来自下面几种:

1. Grafana监控

2. 云数据库监控

3. 服务器监控

4. 定时脚本拨测

4.2.1 Grafana监控

将DB的连接数、慢查询数、主从同步时间等指标,通过Grafana展示。

4.2.2 腾讯云数据库监控

使用腾讯云上的数据库监控页面和视图进行展示。

4.2.3 服务器监控

业务逻辑的服务器CPU等指标监控,通过云监控获取,并推送到企业微信群。

4.2.4 定时脚本拨测

用于连接数、慢查询数、RO组的主从同步的拨测监控。此外,还帮助完成了自动Kill超时SQL的存储过程监控。

4.3 告警方式

4.3.1 企业微信机器人

Grafana监控以及数据库监控和定时脚本拨测等,都采用了企业微信机器人的告警方式。

4.3.2 微信

5 腾讯云数据库智能管家-DBbrain

业务通过智能管家对所有数据库进行巡检,监控和问题诊断。

业务可以在大盘里巡检得分较差的数据库实例,下钻到该实例,了解评分差的因素,譬如CPU使用率高,或者慢查询因素。可以继续分析慢查询的详细日志,提取出问题SQL,对其进行SQL优化。

上图,智能管家提示的慢查询事件,及详细说明,包括实例、发生时间、时长、与CPU负载对照、SQL语句等。

上图,智能管家给出优化建议

腾讯云618
avatar
万物皆可云,我们为云计算助力!- 云数据库

万物皆可云,我们为云计算助力!-

9月阿里云高校计划为高校同学们准备了首次千人ECS7天训练营和视觉人工智能训练营,为来自全国高校的同学们学习云技术和云计算助力。精心准备的训练营让同学们进一步体验了ECS和视觉人工...
腾讯云618
匿名

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: