阿里DTS消息堆积处理过程

586 阅读3分钟

概述


我正在参加「掘金·启航计划」

在2023年4月27日的中午,运维在值班群里发了一张截图,大意是说,数据库的负载突然变高了,因为这个时间刚好是饭点,大部分后端开发人员都在外面吃饭,我就让其中一个在办公室吃饭的A同事先去跟进一下。

等俺回来后,大概是下午一点半左右,A同事说,有慢sql,正在评估是否把索引加上去。但是他没说也没意识到影响面有多广,我也就暂时没有去管,直到线上bug群,有运营反馈,部分商品上架后,在小程序看不到。因为如果用户看不到商品,也就无法购买,会直接影响收入的。直到那一刻我才深入介入,一起去看这个问题。

在我之前写过的解决一个偶现的503 bug,花了俺不少时间一文里,曾经提过处理线上问题的大原则:

一定是先止损,优先【线下去处理故障】,而不是【直接在线上处理故障】。

也就是说,先还原系统,先让系统正常运转后,在【线下】去分析问题的原因。但是今天说的这个DTS问题,不一样,原因是:

  • 近期没有发版;
  • 系统流量也没有突增;

你只能硬扛,在线上把问题解决掉。

好了,我们回归正题。公司的商品同步技术,是使用阿里的DTS,只要旧的商品库的商品数据被更新,会自动同步到新的商品库。当时先让A同事到阿里的DTS管理后台,看看消息的堆积情况,不看不知道,一看吓一跳。

商品变更消息已堆积了接近10w条。

那会我都觉得自己是不是得跑路了,😂,于是火速做了如下操作:

  • 让运营停止商品信息更新,因为从运维给到的SQL可以知道,是运营在更新某种商品的类目;
  • 直接让运维把慢SQL给kill掉;

把慢sql kill掉的原因是,想加快已堆积的消息的消费速度,但是运维反馈,kill掉一部分sql,新的慢sql又来了,消息还在一直堆积。

没办法了,只能让A同事,立刻把表的索引加上,先确保消息能快速消费。果然,索引刚建立好后,瞬间堆积消息就消失了,mysql负载也下降了,之前运营反馈的没有展示的商品也都正常显示了。

这一步操作完后,我们还做了两个操作:

  • 一个是观察整个商品服务的核心接口,性能有无受到影响。因为当时是单独新增了A字段的索引,而A字段之前是有和其他字段建立联合索引的。单独新增了一个A字段的索引后,可能会导致其他联合索引失效。但还好,最后发现没有这个问题;
  • 手动将一些商品数据更新到新的商品库,因为刚才运维手动kill掉了一些sql语句,数据是有丢失的;

自此,问题得到解决。那么从这个故障里,还是能总结出一些经验教训的。

  • 一个是阿里DTS消息堆积,得监控起来,并把监控信息同步到告警群,让大家都能知道,而不是只靠运维去同步;
  • 处理线上问题的时候,除了优先止损外,最重要的一件事情是,评估影响面;
  • 要敢于做决策,像这个故障,kill掉sql,加索引,我就直接拍板了,因为那会是在抢时间,犹豫太久,只会让损失不断加剧。你应该也遇到过,一有线上紧急问题,就一堆人在那里急,讨论来讨论去,这样不好,得有人拍板和敢于担责。