微信号:greatops

介绍:高效运维公众号由萧田国及朋友们维护,经常发布各种广为传播的优秀原创技术文章,关注运维转型,陪伴您的运维职业生涯,一起愉快滴发展.

一次高频数据访问引起的业务生死告警...

2017-12-01 07:10 周小军


作者简介:

周小军
腾讯资深运维专家,拥有十几年的互联网IT运维经验,擅长互联网架构、云计算平台、运维自动化等领域。对跨行业的DevOps、云计算、技术架构和团队管理等均具有深厚兴趣。腾讯学院讲师,高效运维社区金牌讲师。在腾讯SNG社交网络运营中心负责社交业务运维管理,目前专注于运维AI、运维大数据和海量运维自动化的实践。

周三晚上21:51,正在家里看美剧《权力的游戏》“大麻雀”这一集的小董,突然接到语音电话告警:10.25.125.31的服务器发生网络流量告警。

小董是 DBA 团队本周的轮值员,对手机告警早有准备。家里的笔记本电脑已远程 VPN 连接在公司运维网络上。小董打开服务器监控视图,只见10.25.125.31服务器视图上的内网卡网络流量从300 Mbps陡涨到1Gbps,达到网卡流量上限。

几个 RTX 群头像同时在闪,不同的开发和业务运维在几个 RTX 群里找小董,十多个业务模调成功率小跌到98%,小比例用户的数据读写返回超时。

模调指模块间调用,其调用的成功率和延迟用来衡量业务服务质量。

因为分布式数据中的数据记录是分布到数据仓库内几百台数据存储服务器上的,一台数据存储服务器上通常都分布了十几个业务,这台流量高的数据存储服务器已经影响了十多个业务的访问质量。

只有一台存储服务器流量陡增,凭运维经验,多是有肥 KEY(指长度超大的记录)或热 KEY(短时间内访问量超大的记录)导致的。花了十多分钟,小董从接入服务器的监控数据上很快定位到是生活服务的 BID(业务表 ID)有热 KEY,每秒均有100多次的高频读取操作。

小董在 RTX 群里跟开发和业务运维同步了告警原因及处理手段后,打开数据搬迁工具,试图把10.25.125.31服务器上的其他业务数据搬迁到低负载的数据存储服务器上。

但这台服务器的网卡流量已经撑满,数据搬迁速度极慢,看来只能对生活服务业务限流,再启动搬迁。限流后,搬迁速度提升到100 Mbps,但将50多GB的内存数据搬迁到其他数据服务器也花了一个多小时。

转眼过去一个多小时,随着用户流量过去,网络流量降回正常水位。RTX 群开发陆续反馈,业务模调成功率已恢复正常。

此时已经接近零点,但接下来,小董还得继续定位出是哪些热 KEY 影响了业务。他打开访问日志,统计出几条访问量最大的记录,页面显示这几条热 KEY 的长度有七八百 KB。

他快速计算了一下,某条记录的访问为每秒约100次,带来的网络流量为:
700 KB ×100 × 8 bit = 560 Mb
这条记录就已经消耗了服务器一半的流量。

时间已经接近凌晨4点,明天再找开发人员一起看看如何优化问题。小董关掉显示器和台灯,带着满满的困意上床。此刻窗外宝安中心重重高楼上仍点缀着不少明亮的灯光。

第二天早上,打着哈欠的小董差点误了楼下8点20分的班车。眯眼小憩,班车在长车流中蠕动到腾讯大厦总部。

在腾讯大厦14楼食堂吃完著名的酸菜饼,时间快到9点半。打电话给开发和业务运维,一同到5楼楼道的白板边商议昨晚故障的优化措施。

小董把昨晚引起问题的几个大 KEY 告知开发人员。开发人员确认并解释说,该业务的 KEY 是生活服务的公众号。用户关注公众号后来使用该号的功能,这个 KEY 的字段将存储所有关注该号用户的 ID。

昨晚业务侧的公众号有营销活动,因为用户大量访问几个热门公众号,造成10.25.125.31这台数据存储机流量过载。

了解了事因,小董、开发人员和业务运维很快在白板上用黑笔草拟出几条优化措施。

首先最紧急的任务是确保业务安全。小董将确认的几个肥热 KEY 搬迁到一台独立的千兆存储机上,避免今晚再做营销活动时,肥热 KEY 影响到其他 KEY。

其次,开发在逻辑层对肥热 KEY 做1分钟的缓存策略,减少逻辑层对后端数据层的访问压力。开发版本尽快在本周五前发布。

其三,小董写一段脚本,扫描生活服务号表的备份数据,统计肥 KEY 和头部肥 KEY 的占比及平均大小,提交给开发人员后续优化。

最后,开发人员将和产品共同沟通,看能否对肥 KEY 进一步拆分,譬如限制每条记录大小为100 KB,一旦超过此阈值就将记录拆成多条ID,在逻辑层进行记录合并。

快速沟通完几条优化措施后,小董回到工位上完成优化任务。他先快速翻看数据仓库的存储机列表寻找空闲的存储机,这时他欣喜地发现,仓库的 BUFF 还有几台刚申领的万兆存储机。于是赶紧找 Leader 确认,答复是可以申请一对万兆存储机临时使用两周。

小董马上通过织云运维平台将这对万兆存储机部署到仓库,并将几个肥热 KEY 的记录搬迁到这对万兆存储机内。

仅花20分钟结束了部署和记录的搬迁任务。

小董在他的开发环境 PC 上打开 JetBrains PyCharm 编辑器,编写备份文件分析代码。代码会扫描备份文件中的所有记录,分段汇总各大小区间的记录数量。代码只有几十行,30分钟就编写完成。经过测试,一切正常,提交到工具平台,开始远程在备份服务器中运行。

“等等,还有几个思路……”,小董盯着屏幕的脚本运行进度,脑里蹦出几个想法:应该对全网备份文件进行扫描,定期分析不合理的肥 KEY 来优化;

另外,可以添加针对热 KEY 的流量阈值自动诊断和自愈流程,诊断系统发现热 KEY 引发的流量超限时,就立即启动搬迁工具,取代人工进行诊断和搬迁。

晚上,临近10点,新一轮的业务营销活动开始。早有准备的小董在家里盯着万兆存储服务器的流量监控视图,他看着流量从100 Mbps逐步涨至1Gbps、1.5Gbps、2Gbps……终于在3.4Gbps停止,心里暗叫一声,“耶,搞定,完美撑住!”

此时窗外的深圳宝安中心灯光灿烂。

DevOps 三十六计之数据库运维:


如果您对其中内容表示质疑,欢迎指出并发表意见,一经采纳,您将成为内测版读者,《DevOps三十六计》在年末的第一批印刷将在第一时间送到您的手中。


想与周小军老师直接交流?请加入 DevOps 三十六计交流群

入群请加微信:gaoxiaoyunweiliuce


关注 DevOps 三十六计公众号

我们将长期发布 DevOps 三十六计完整内容

END


更多相关文章阅读

DevOps 标准体系发布及权威解读

阅后即焚,Python 运维开发99速成

IT 从业者必备的20个效率工具,亲测有效

腾讯赵建春:AI浪潮下的高效运维思考及实践

京东大规模数据中心网络运维监控之眼

AI运维、爱标准 | GOPS2017上海站精彩实录【附PPT】

Jenkins创始人带您探访国内首届Jenkins用户大会(附PPT)


高效运维社区2017年最后一季课程排期来袭

预报名请填写问卷

更多课程详情、企业内训或其他业务,可以咨询我们的课程顾问哟~

如果您在华南、华东、东北、港澳台地区,可以找TA 丛琳: 18811333909 (同微信)

如果您在华北、华中、西南、西北地区,可以找TA 杨文惠:13021086339(同微信)

点击阅读原文下载 GOPS2017·上海站演讲PPT(密码: egeq

 
高效运维 更多文章 在 Facebook,我是这样做运维的 阅后即焚,Python 运维开发99速成 DevOps 标准体系发布及权威解读 又误删数据?不怕不怕啦:mysqlbinlog 命令的15个实用玩法 IT 从业者必备的20个效率工具,亲测有效
猜您喜欢 PingCAP 将携 TiDB 核心技术亮相 2017 DAMS 峰 魅族pro6的几个问题 细数互联网产品的开放策略:微信与支付宝走上相反的路子 有种网发力“互联网+现代农业”,开创农业4.0模式 为小程序而生的小(jiao)手架