中企动力建设的网站如何修改,网站建设征求意见通知,网站建设网站,制作线下交易平台网站建设作者简介#xff1a;大家好#xff0c;我是smart哥#xff0c;前中兴通讯、美团架构师#xff0c;现某互联网公司CTO 联系qq#xff1a;184480602#xff0c;加我进群#xff0c;大家一起学习#xff0c;一起进步#xff0c;一起对抗互联网寒冬 学习必须往深处挖… 作者简介大家好我是smart哥前中兴通讯、美团架构师现某互联网公司CTO 联系qq184480602加我进群大家一起学习一起进步一起对抗互联网寒冬 学习必须往深处挖挖的越深基础越扎实
阶段1、深入多线程阶段2、深入多线程设计模式阶段3、深入juc源码解析阶段4、深入jdk其余源码解析阶段5、深入jvm源码解析 事故场景
我们在做需求开发时经常会遇到一些边界条件的判断
查询身高大于180cm、年龄大于18岁的学生筛选出公司P7以上的程序员 大多数时候我们只需要把产品语言转化为程序语言即可
SELECT * FROM t_student WHERE height180 and age18;
SELECT * FROM t_employee WHERE level7;
但产品语言与程序语言并不完全等同直接翻译有时会引发意想不到的BUG。 假设现在有一个需求
下单24小时以后为用户发放奖励 一般来说我们可以采用定时任务完成这个需求具体做法是
用户下单后在order_task表插入一条记录为了方便记忆type和status都用字符串代替
# 一张任务表不止一种类型的任务所以用type区分和当前需求关系不大
INSERT INTO order_task (order_id, task_type, task_status, gmt_create, gmt_modify)
VALUES(10000001, complete_order_prize, wait, xxxx-xx-xx, xxxx-xx-xx);
定时任务扫描需要发放下单奖励的任务、为用户发放奖励、更新任务状态
# 伪代码 8640024*60*60
SELECT * FROM order_task WHERE order_typecomplete_order_prize and task_statuswait and gmt_create now-86400;
注意时间条件由于产品需求是下单24小时后才发放奖励所以要满足条件gmt_create now-86400。 正常来说上面的做法是没有问题的。但是昨天产品找我说用户反馈自己一个月以前的3笔订单奖励至今未发放。 这位产品很优秀比较懂开发甚至自己会写SQL他的第一反应是定时任务挂了。 好了现在问题出现了如果是你打算怎么开始排查呢 解决方案
先介绍一下背景我们公司由于业务调整上面业务所在的平台已经很久没迭代我抓包看了下发现底层逻辑是PHP写的。于是找到对应的工程及代码确认近期确实没有人更改过代码逻辑。 紧接着我打开公司的定时任务平台查看了该任务过去一个月的执行日志发现全都执行失败了。 定时任务是否执行成功其实有两个指标
调度成功执行成功 调度成功只能说明定时任务没问题机器也没挂但具体本次操作是否执行完毕需要看执行结果。 从上图可以看到定时任务每五分钟执行一次可以调度成功尽管也有调度失败的但执行结果无一例外都是失败的。 这说明定时任务本身是好的只是执行过程出了问题。查看定时任务的执行策略我发现采用的是丢弃后续调度 这是一种什么策略呢举个例子假设定时任务每隔5分钟执行一次而上一个任务A本次执行超时了超过5分钟还在执行当下一个任务B启动时结果发现上一个任务还在进行中那么任务B就会被丢弃等待下次任务C执行。 那么现在就有个矛盾摆在我们面前
定时任务是好的但执行过程出问题了然而我们排查后确定代码近期没有变更 代码没动过定时任务也没挂然而却没有达到预期。一个线上的功能好端端的突然崩了无非几点原因
用户行为改变恰好命中之前没测到的bug
其他人发布新代码对当前功能产生影响数据出问题了 订单奖励属于定时任务不存在用户行为这个原因基本可以排除。只有第二、第三个原因其实归根到底都是数据问题A功能要想影响B功能一定是两者有共同的数据也就是有共同的表。但不论哪种原因我们可以得出结论一个运行好几年的定时任务跑着跑着突然崩了大概率是数据出问题了。 但我得出这个结论却是在2小时后。一方面恰好这个功能的PHP代码以及远程调用的Java服务都没有打印日志对问题排查造成了很大的困难。由于系统已经基本停止维护为了找到当前工程的日志花了将近1小时。另一方面电商系统太大了只能上预发环境测试。等给工程打上日志、重新发布已经过去10分钟。希望大家吸取教训实际开发时在必要的地方打上日志方便日后排查问题。 那么最终是什么原因导致定时任务不执行了呢 下面是一段PHP代码做了简化处理具体细节不用理解
/*** 定时任务脚本 处理签到下单任务奖励金的实质发放* return bool*/
public function finishSignOrderTask() {load_module_model(xxx);$start_time time() - 86400; // 24小时以后的订单// 查出符合条件的最老的一条的记录$oldest_record $this-CI-xxx_sign_task-getWaitFinishTask(self::TASK_ID_ORDER_TASK, $start_time, \Xxx_sign_task::TASK_STATUS_COMPLETE, asc);if (empty($oldest_record)) {return TRUE;}$start $oldest_record-id;// 查出符合条件最新的一条记录$end_id $this-CI-xxx_sign_task-getWaitFinishTask(self::TASK_ID_ORDER_TASK, $start_time, \Xxx_sign_task::TASK_STATUS_COMPLETE, desc)-id;// 最新~最老记录之间都是需要执行的订单奖励具体做法是 每次从中捞出100条执行start_id 100直到退出start_id100end_id$page_size 100;$xxxSignAwardService XxxSignAwardService::getInstance();while (TRUE) {$where [id . $start,id . ($start $page_size),task_id . self::TASK_ID_ORDER_TASK,task_status . \Xxx_sign_task::TASK_STATUS_FINISH,gmt_begin . $start_time,];$records $this-CI-xxx_sign_task-get_by_where($where, *, 1, $page_size);if (!empty($records)) {foreach ($records as $record) {// 再次校验订单状态$order $this-CI-xxx_order-get_by_oid($record-biz_value);if (empty($order)) {$this-logger-error(oid_deal_not_found, [$record]);// 订单不存在 关闭任务$this-updateTaskStatus(FALSE, $record);continue;}// 发放奖励...}}if ($start $end_id) {break;}$start $page_size;}return TRUE;
}
我在观察表数据时发现了一个现象最早一条处理失败的奖励任务竟然是2020年12月的它的状态仍旧是task_statuswait 这会产生一个什么现象呢(划线表示已执行)
1000000 2020-12-27 任务1start1000001 2020-12-27 任务21000002 2020-xx-xx 任务......2000001 2021-04-27 任务N...后续新的任务...2100001 2021-06-04 任务Zend 由于上面PHP代码的做法是查出start~end之间所有数据并从start开始每次查询100条数据。随着时间越来越长到了2021-04-27时任务1和任务N之间id号已经差了100w即使除以pageSize100也需要循环查1w次而这1w次SQL查询是查不到数据的因为之前被处理过了 换句话说每次定时任务开始虽然目标是执行2021-04-27 ~ 2021-06-04之间的奖励任务但却不得从2020-12-27的数据开始以id100的形式查询1w次后才能到达任务N。
注意while并不是空转而是真的去查数据库了空转1w次根本不算什么但循环查询数据库1w次是不可接受的即使分页查询一次200ms整个过程也要耗时2000s要30多分钟而定时任务频率为5分钟。然而耗时长并不是任务失败的主要原因最关键的是单任务循环次数过多导致日志输出及内存占用增加最终每次还没执行到需要的数据PHP自己就先挂了。 解决方法是查询奖励任务时加一个边界判断下单24小时后且最近3个月内的订单。 至于为什么2020年的那个任务一直没被执行掉是因为它的任务流水不知为何被删除了或者当初插入失败了而Java远程服务会做流水校验如果流水为空则抛异常跳过本次执行所以2020年的那个数据躲过了一轮又一轮的定时任务最终出现在2021年的某一天突然抡起一锤子砸向了俺尽管这个需求不是俺做的... 坑啊
之后隔天观察一下发现任务已经正常了 个人建议
注意边界判断不要做产品语言的翻译机要从开发的角度考虑设计是否合理养成打日志的习惯有利于问题排查
