定时任务

郑昀 最后更新于2014/11/11 关键词： 定时任务 、调度、监控报警、Job、crontab、Java 本文档适用人员：研发员工 没有JobCenter时我们要面对的： 电商业务链条很长，业务逻辑也较为复杂，需要成百上千种定时任务。窝窝的大多数定时任务其实调用的是本地或远端 Java/PHP/Python Web Service。如果没有一个统一的调度和报警，在集群环境下，我们会： 不知道哪一个定时任务执行失败或超时，不见得能第一时间知道——直到最终用户投诉反馈过来； 要求每一个定时任务输出统一格式的日志供监控系统解析？ 对每一位定时任务维护者提出高要求？这不是我们的解题思路。 不知道哪一个定时任务没配好瞎跑； 比如忘记配成开机自启动； 比如曾经线上环境B与环境A并存导致定时任务互相争抢； 不知道现在线上跑了多少个定时任务，都是干什么的，负责人都是谁； 有些定时任务非常重要，不能单点，但又不能同时起多个 crontab，只能采取 master/slave 模式跑——比如退款处理。 什么是JobCenter？ 窝窝的定时任务管理和调度平台，一个实用工具， 它是一个由 任务管理、任务调度、任务监控报警以及宿主任务执行（注意不再是 crontab了） 这四部分组成的，分布式多任务协调系统 。 2012年时，我看到暴风影音的马晨开源了一个 CronHub（时间调度系统）项目 （

郑昀 创建于2015/11/10 最后更新于2015/11/12 关键词：佣金计算、定时任务、数据抽取、数据清洗、数据计算、Java、Redis、MySQL、Zookeeper、azkaban2、oozie、mesos Summoner 是国玺部门推出的基于 MySQL+Redis+Zookeeper 的分布式并行计算调度和管理系统，李红红主设。 0x00，为什么要做“数据”并行计算调度？ 大家都可能做过 基于 MySQL 数据库的，大规模的、有步骤的、步骤与步骤之间有依赖关系的数据计算 。你可能定义了一堆彼此依赖的定时任务，也可能写成一个大进程跑。 举一个实际场景吧，在我们 O2O 业务体系下，我要做人员规模三四千人、有多条业务线、组织结构为大区-区域-城市-销售组的销售团队的昨日佣金和当月佣金，这里的挑战是： 涉及到商户、门店、交易、折扣、核销物料等等，数据量很大，至少每天都要算一次，要算得快， 激励政策和佣金计算公式随着竞争态势变化，一般一两个月变一次， 数据抽取尽可能少影响正常业务， 计算逻辑调整后要能快速部署和运行。 那么，以前可能会定义一些定时任务，每天凌晨从各个业务数据库（毕竟全都拆库分表了）里抽取： 人员组织架构 大区、区域和城市的对照关系 合同以及合同拥有者 商户和门店 门店下的收单交易 佣金计算公式、规则以及各种权重因子 …… 既有全量数据，也有增量数据