线上问题系列DB字段类型变更导致核心服务不可用

Posted jwentest

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了线上问题系列DB字段类型变更导致核心服务不可用相关的知识,希望对你有一定的参考价值。

背景

业务说明

接到一个业务需求,往DB表中某个字段里新增一些数据,该字段本来是text类型,发现根据业务需求来说,新增数据超过text类型的最大长度,因此需要对数据库表的该字段类型做变更,变更为了MEDIUMTEXT类型来解决业务需求;

数据流转

DB表的数据会通过数据处理转化到mongo中存储,然后mongo再加载到redis中,打点服务会从redis读取该数据,进行json encode,然后做业务处理;

问题过程

  1. 开发反馈打点服务sg、fk集群机器出现响应时间突增以及请求出现大量5xx,运维增加集群机器数量后发现响应时间以及5xx数量并未减少,观察到新开的机器以及旧机器的打点服务进程的go携程数以及占用的内存非常高,开发开始排查具体原因
  2. 运维开始将fk地区请求转到vg地区集群,fk地区的请求响应时间以及5xx下降,服务恢复正常,vg地区表现正常(因为vg的机器多,即使解析慢了还是够应付)
  3. 开发反馈上午某业务需求服务上线新功能会导致mongo中的campaign中的问题字段数据量变大,可能是此变动影响到打点服务,进行回滚相应变动后,观察到sg地区请求5xx的数量逐渐下降,运维开始新开机器并重启旧机器,服务逐渐开始恢复
  4. sg地区服务恢复正常,fk地区请求也迁回fk集群机器,打点所有地区服务恢复正常

问题原因

  1. 运营反馈ss素材报表ctr出现100%的问题,排查到是上线素材区分国家后导致
  2. 开发操作上线修复此问题,同时会导致mongo中的campaign中的某问题字段数据量变大,由于打点通过zeus redis获取campaign数据,并且会进行json反序列化操作,部分单子的该问题字段数据量增大到2M以上,导致打点反序列化效率下降,造成请求堆积,最终导致进程中的携程增加,占用内存资源不断增加,导致服务不可用

问题总结/改进

  1. 信息同步,核心系统出现问题首先在群里反馈该问题,看之前是否有其他项目上线(包括DB/配置变更)导致该问题;
  2. 业务流程梳理,对全流程进行梳理,知悉数据去向和使用,方便问题的定位分析,快速发现问题;
  3. 系统架构优化,打点服务解耦,反序列化效率提升, mongo中campaign信息的拆分,了解到目前有部分信息是独立表的,打点服务在启动的时候会去load数据到内存中;
  4. 个人觉得架构问题是大于流程方面的,但复盘会下来流程问题大于架构,不可否认流程问题得到解决可以避免类问题,但随着业务持续增长/迭代这些问题始终是要暴露出来的;

其他

  1. 咨询了之前UC的同事那边的打点服务,打点服务可以拆分为接受+处理两个模块,接受模块来解析接受请求,然后存储在中间件中(类似kafka,metaQ消息队列),然后处理模块消费处理,这样可以解耦,如果处理失败的话,可以从中间件中重复消费减少损失
  2. 公司的算法强依赖日志,因为日志的确实会导致算法模型训练不准;
  3. 由于公司之前的节约成本的考虑,目前的mongo数据是刚刚够用状态,如果不从成本考虑,mongo机器够多,打点服务就可以马上加机器应对这次事故;临时加mongo机器很慢,因为加了机器还是同步数据,一般加mongo机器大概是1个小时左右,因此出现事故的时候一般不会加mongo机器时间花费太久了;但如果mongo机器只是够用的状态,只加打点服务的机器的话,mongo数据库会顶不住,太多服务连接使用,所以在加打点服务机器的时候出现了服务起不来,因为把mongo弄挂了;
  4. 打点服务的使用方是SDK,SDK发现打点服务返回不是200的时候有重试机制,所以导致打点服务请求暴增,因此引起雪崩了;

以上是关于线上问题系列DB字段类型变更导致核心服务不可用的主要内容,如果未能解决你的问题,请参考以下文章

线上问题解决系列——记一次HTTP连接池导致的Java服务雪崩

一次线上数据库连接池故障复盘

订单导出的预发和线上的自动化对比工具

稳定性全系列——如何做线上全链路压测

滴滴稳定性系列2: 如何做线上全链路压测

通过jstack与jmap分析一次线上故障