工作案例：消息积压

前言

• 验证码场景大家屡见不鲜了，基本在现在主流的登录场景中，基本都是手机或者邮箱加上验证码验证的形式直接进行登录和注册。

• 在编写验证码服务时，我们经常会使用MQ来进行一个消息发送和调用厂商接口之间的解耦。

  • 点击发送，调用发送接口，该逻辑负责直接生成验证码并且往消息队列中投递消息。
  • 有个消费者服务，消费消息队列中的消息，负责调用云厂商接口进行发送验证码的服务调用。

• 我们的做法也是这样的。但是这次国庆节就出现了一点小问题：

  • 国庆我们业务方进行了促销活动。在10月1号晚上慢慢的看社区里面开始出现很久才会收到验证码以及有部分时无法正常接收到验证码的反馈。
  • 线上验证码的数量开始疯狂消耗，一晚上不到50W条验证码出去了。

问题定位&分析

基本信息描述

• 我们的消息队列是NSQ，4C8G的集群部署。
• 之前的日新增用户量在5W以下，并且基本都是平滑流量，这次的促销行为导致突发流量剧增，还都是处于新增用户。
• 生产者服务数量：2个
• 消费者服务数量：2个

问题定位&处理

• 上面的描述和基本信息一看，有经验的基本上都知道发生了什么，消息队列内的信息无法被及时消费，导致消息堆积。
• 消息短时间内大量增加，消费端无法及时消费，导致业务出现问题。
• 处理方式也很简单：
  • 提高消费者服务的服务数量。于是我们临时将消费者服务的数量提高到了50个实例。短时间解决了该问题。
  • 为了长期处理该问题，简单的花费了部分时间对线上的代码进行了改造，在一个消费者实例内起了10个消费者携程进行消费，。

存在的问题复盘

• 前期消费者服务单个实例只有单线程在消费消息。但是消费端的消费速度是需要高于发送端的，一开始就需要在消费端较为充分的利用起来其资源。
• 监控&报警措施不完善
  • 对于NSQ的监控目前只做了对于基本的运行指标的监控：CPU，内存，负载
  • 并没有对于NSQ的处理进行监控，导致这次问题是由社区反馈发现，而不是内部的监控&报警平台预警的。
  • 如果有对该指标进行提前预警，那么这部分就不会发生问题。
• 所以预计在国庆后将对NSQ也增加相关指标的告警。
  • 包含:depth,Requeued,timeout

参考：

• NSQ文档