概述
我正在参加「掘金·启航计划」
在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，加索引，我就直接拍板了，因为那会是在抢时间，犹豫太久，只会让损失不断加剧。你应该也遇到过，一有线上紧急问题，就一堆人在那里急，讨论来讨论去，这样不好，得有人拍板和敢于担责。
