记一次大量499http状态码问题出现与处理

目录

问题描述

问题分析

问题解决

总结思考

---

问题描述

1 19:38 DBA 发现加解密数据库 DTS 出现延迟，查看数据库监控，发现 ALI 机房出现大量写入。

2 19:41 架构组研发查看 cat 监控，发现加解密服务、消息中心服务等一些其他的服务出现总共 2万多的499状态码。

3 19:43 加解密数据库 DTS 恢复正常，加解密数据库的 ALI 机房不再有大量写入。

4 20:00 加解密服务研发发现流量主要来源是消息中心服务，马上联系消息中心服务的负责人，了解业务情况。

5 20:27 加解密服务研发分析业务日志发现加密数据都是非手机号码，马上将情况同步给消息中心服务的负责人。

6 20:37 消息中心服务负责人联系业务人员，问题定位是运营人员推送的时候把50万的 studentId 当成手机号码发出去了。

名称说明：

DTS：Data Transmission Service，数据传输服务，是阿里云提供的实时数据流服务。

499状态码：客户端向服务端发起请求，服务器端处理的时间过长，超出了客户端的超时时间，客户端主动断开连接。

为什么需要 DTS，由于加解密服务是双机房，两个机房之间需要通过 DTS 进行数据同步。

问题分析

针对上述描述，我们进行了如下分析：

1 加解密数据库出现 DTS 大量延迟时，研发为什么不感知？因为 DTS 这块延迟报警没有添加给研发。

2 为什么加解密数据库 DTS 出现大量延迟？因为加解密数据库 ALI 机房有大量写入。

3 为什么加解密数据库 ALI 机房有大量写入？查询流量来源于消息中心服务，与消息中心研发沟通，流量与平常一样。

4 消息中心服务的流量与平常一样，加解密服务为啥会有大量写入？本次的流量是没有加密过的 studentId，经过加密后会有大量的写库操作。

5 平常都是加密手机号码，这次为啥加密 studentId？运营人员手误，将 studentId 当做电话号码发送。

6 即使运营人员手误，为啥还能将 studentId 当做电话号码发送？ 消息中心未对电话号码进行参数校验。

7 加解密数据库的 ALI 机房的大量写入对服务有什么影响？

 数据库的大量写入会导致数据库连接打满， 加解密服务请求出现堆积，响应变慢。客户端主动断开连接，出现大量 499 报错，出现暂不可用的情况。

8 加解密服务暂不可用是否对 PX 核心链路有影响？

PX 核心链路有登录环节，登录环节需要对电话进行加密，如果是提前进教室的，则不会受影响；如果是在事故时间段进行登录，会出现暂不可用的现象。

9 加解密服务出现大量 499 状态码，研发为什么不感知？针对 499 这块研发没有添加监控。

问题解决

1 DTS 出现延迟添加报警给研发。

2 研发这块添加499状态码报警。

3 加解密服务接入限流组件对消息中心服务进行限流处理。

4 运营配置后台前端、后端对加密参数进行校验，避免误操作。

总结思考

1 加解密服务作为底层服务，稳定性和可用性需要加强，上游永远都是不可信任的。

2 研发做系统的时候应该，更好的考虑系统的健壮性，因为你永远不知道，用这个系统的人的使用姿势。

3 给非专业人士提供的系统，越简单、越傻瓜式越好，最好的是不要让别人动脑子，这样就能更好的避免出现问题。