一 发生的情况

25,26两天连续有同事反馈天枢系统数据要么没数据要么数据没更新,经过排查是xxl-job挂了,25号手动重启了,26号还是挂,手动增加内存了,虽然崩溃的次数少了但是丢失的数据确确实实存在.

二 问题的发生

近期接入快手和抖音相关数据,数据和计算量变大,导致xxl-job不堪重负,查看xxl-job,大量的内存溢出和http线程池不响应导致相关定时任务没有去拉取或者汇总数据导致数据的丢失.

三 开始着手问题的处理

3.1 分而治之

V1版本是一个xxl-job媒体数据和用户数据一起使用,同生共死

V2拆分成媒体xxl-job 和 用户xxl-job

好处:

1. 业务隔离,拉取媒体跟用户汇总,进行物理隔离
2. 定制化分配资源,拉取媒体侧重http资源,用户汇总侧重数库据资源,能更好分配
3. 错误排查,更能定位到是哪些问题
4. 业务容灾,拉取媒体定时任务出错不会影响数据汇总

3.2 代码的拆分

以前:

摸石头过河,数据量少,一个定时任务,将所有媒体的渠道执行一遍,可能在某个点将http资源耗尽,导致崩溃

现在:

按媒体进行拆分,不允许将对应媒体的拉取集合到一个定时任务中,必须拆分

将定时任务代码拆分为用户汇总模块和媒体数据模块

3.3 账号自动停投功能增大使用面

1. 媒体账号都是根据账号来拉取数据,每天实际有用账号不超300个,但是全量账号过万,资源大量浪费
2. 更新和拉取数据无用账号使时间变长,变相增大压力和变长更新周期
3. 紧急情况手动修复可以缩短恢复时间

3.4 次功能也需更关注

问题

有市场同学反馈,消耗总数没错,对应素材消耗缺失非常厉害

原因

1. 定时任务的不正常挂停导致相关素材数据丢失
2. 平时只关心核心功能,比如,总消耗之类的,对应素材消耗关注度不够
3. 手动恢复数据忽略了次功能的恢复

四 持续

1. 持续关注环境稳定
2. 将事故的原因变成开发规范
3. bug会一直有,重视任何一个反馈
4. 内部驱动,发现不好的"味道"就让它暴露出来