分布式任务调度技术选型

背景

因为我是在一家银行外包的公司做开发，我们公司接了一个类电商的项目，背靠银行针对于地方的惠民app。上线一个月，我们接了新的需求，双12做一些促销活动，且需要根据用户画像生成不同的推送内容。
当时我们总共有50万用户左右。
经测试，通过Spring Task和分布式锁，单台机器同时开启5个线程，执行时间需要27个小时左右，即便开10个线程，需要14个小时左右，显然执行时间过长。

解决方案

当时个推服务部署节点有3台，在每年大促期间可动态扩容，显然通过上述方案是行不通的，其余的机器资源没有充分利用起来。

要想短时间内完成推送，那么就得想办法让每台机器各自分一部分用户数据去执行，这样效率可提高原来的N倍。

核心思想如下图：

经过调研现有的开源的分布式任务调度框架，决定在elastic-job和xxl-job中选一个

Elastic Job是当当网开源一个分布式调度解决方案，由两个相互独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成；定位为轻量级无中心化解决方案，使用 jar 包的形式提供分布式任务的协调服务。支持分布式调度协调、弹性扩容缩容、失效转移、错过执行作业重触发、并行调度、自诊断和修复等等功能特性。

XXL-Job官网是大众点评发布的分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。现已开放源代码并接入多家公司线上产品线，开箱即用。

更倾向于选择XXL-JOB：

1. 轻量级，支持通过Web页面对任务进行动态CRUD操作，操作简单
2. 只依赖数据库作为集群注册中心，接入开发简单，不需要ZK
3. 高可用、解耦、高性能、监控报警、分片、重试、故障转移
4. 团队持续开发，社区活跃
5. 支持后台直接查看每个任务执行实时日志

具体实现

在项目中集成xxl-job客户端

<dependency>
    <groupId>com.xuxueli</groupId>
    <artifactId>xxl-job-core</artifactId>
    <version>2.2.0</version>
</dependency>

在配置文件中配置xxl-job信息

xxl:
  job:
    accessToken:
    admin:
      addresses: http://xxl部署IP地址:8080/xxl-job-admin
    executor:
      appname: vm-service
      address:
      ip:
      port: 9989
      logretentiondays: 30

在xxl-job中新增执行器

注册方式选自动注册，这样方便动态扩容

创建任务

路由策略选择分片广播

代码部分

在任务代码获取推送用户时，根据当前的分片及分片总数对用户ID取余，这样我们就可以在每个分片节点，获取不一样的数据。id值越连续，分片则越均匀。

 ShardingUtil.ShardingVO shardingVo = ShardingUtil.getShardingVo();
 int numbers = shardingVo.getTotal();  //分片总数
 int index = shardingVo.getIndex(); //当前分片索引

假设分片总数为3，当前节点获取到的分片索引为0，那么查询推送用户SQL如下：

SELECT user_id FROM `user_info` WHERE MOD(user_id,3)=0 

我们在实际代码中，分片总数和当前分片索引是以参数的形式传给查询的SQL语句的。

如上，即可完成分布式任务。