文章目录
- 一、简述
- 二、故障转移演示
- 2.1. 启动2个执行器
- 2.2. 添加执行器ip
- 2.3. 故障转移策略
- 2.4. 启动任务
- 2.5. 模拟8081执行器宕机
- 2.6. 结论
- 三、轮训策略演示
- 3.1. 启动2个执行器
- 3.2. 添加执行器ip
- 3.3. 轮训策略
- 3.4. 启动任务
- 3.5. 日志分析
- 3.6. 故障转移
- 3.7. 重新启动8082执行器
- 四、分片广播策略演示
- 4.1. 启动3个执行器
- 4.2. 添加执行器ip
- 4.3. 分片广播策略
- 4.4. 启动任务
- 4.5. 案例代码
- 4.6. 执行一次测试
- 4.7. 执行器效果
- 4.8. 结论
一、简述
路由策略:执行器集群部署时提供丰富的路由策略,包括:第一个、最后一个、轮询、随机、一致性HASH、最不经常使用、最近最久未使用、故障转移、忙碌转移等;
路由策略 | 说明 | 使用频次 |
---|---|---|
FIRST(第一个) | 固定选择第一个机器 | |
LAST(最后一个) | 固定选择最后一个机器 | |
ROUND(轮询) | 负载均衡+故障转移 | 经常使用 |
RANDOM(随机) | 随机选择在线的机器 | |
FAILOVER(故障转移) | 按照顺序依次进行心跳检测,第一个心跳检测成功的机器选定为目标执行器并发起调度 | 经常使用 |
SHARDING_BROADCAST(分片广播) | 广播触发对应集群中所有机器执行一次任务, 同时系统自动传递分片参数;可根据分片参数开发分片任务 | 经常使用 |
二、故障转移演示
2.1. 启动2个执行器
2.2. 添加执行器ip
2.3. 故障转移策略
2.4. 启动任务
发现任务只在8081执行器上,每5秒执行一次。8082执行器上没有执行。
2.5. 模拟8081执行器宕机
停止8081执行器,最后一次执行的时间是2021-02-15 14:59:01
8082执行器,第一次执行的时间是2021-02-15 14:59:06
正好接上了,对吧!
2.6. 结论
故障转移策略只会运行在一台8081执行器上,当8081执行器宕机,就会转移到8082执行器上继续执行任务。
三、轮训策略演示
3.1. 启动2个执行器
因为修改策略和执行器无关,如果上面启动了,此步骤可以跳过
3.2. 添加执行器ip
因为修改策略和执行器无关,如果上面启动了,此步骤可以跳过
3.3. 轮训策略
3.4. 启动任务
3.5. 日志分析
8081执行器,执行的时间是
2021-02-15 15:09:13
2021-02-15 15:09:23
2021-02-15 15:09:33
2021-02-15 15:09:43
2021-02-15 15:09:53
8082执行器,执行的时间是
2021-02-15 15:09:18
2021-02-15 15:09:28
2021-02-15 15:09:38
2021-02-15 15:09:48
2021-02-15 15:09:58
从以上数据分析得出,任务是负载均衡执行的。
3.6. 故障转移
8082执行器停止,模拟宕机,最后一次执行的时间是2021-02-15 15:14:19
当8082宕机后,最后执行的时间是
2021-02-15 15:13:59
2021-02-15 15:14:09
2021-02-15 15:14:19
当8082宕机后,8081执行器,继续执行的时间是
2021-02-15 15:14:24
2021-02-15 15:14:34
2021-02-15 15:14:44
2021-02-15 15:14:54
2021-02-15 15:15:04
8081执行器继续执行任务,但是是每隔10秒
3.7. 重新启动8082执行器
8082执行器任务开始的时间
2021-02-15 15:18:50
2021-02-15 15:18:59
2021-02-15 15:19:09
2021-02-15 15:19:19
2021-02-15 15:19:29
8081执行器任务执行的时间
2021-02-15 15:18:54
2021-02-15 15:19:04
2021-02-15 15:19:14
2021-02-15 15:19:24
2021-02-15 15:19:34
2021-02-15 15:19:45
任务继续轮序负载每个5秒执行
四、分片广播策略演示
4.1. 启动3个执行器
4.2. 添加执行器ip
因为修改策略和执行器无关,如果上面启动了,此步骤可以跳过
4.3. 分片广播策略
4.4. 启动任务
4.5. 案例代码
package com.gblfy.distributedjob.task;import com.xxl.job.core.context.XxlJobHelper;
import com.xxl.job.core.handler.annotation.XxlJob;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Component;import java.util.Arrays;
import java.util.List;@Component
public class TaskExecute {private final static Logger logger = LoggerFactory.getLogger(TaskExecute.class);/*** 任务调度入口* 分片广播任务* <p>* 参数1: 执行日期 executeDate 2021-02-15* 参数2: 执行标识 executeFlag I-增量 F-全量* 参数3: 表名称 tableName sys_user* 参数4: 管理机构 manageCom 86* 参数5: 执行场景 executeScene UPDATE* </p>*/@XxlJob("myJobHandler")public void shardingJobHandler() throws Exception {// 分片参数int shardIndex = XxlJobHelper.getShardIndex();int shardTotal = XxlJobHelper.getShardTotal();XxlJobHelper.log("分片参数:当前分片序号 = {}, 总分片数 = {}", shardIndex, shardTotal);logger.info("分片参数:当前分片序号 = {}, 总分片数 = {}", shardIndex, shardTotal);List<Integer> list = Arrays.asList(1, 2, 3, 4);// 业务逻辑for (Integer i : list) {if (i % shardTotal == shardIndex) {logger.info("myXxlJobHandler execute...user={}", i);XxlJobHelper.log("第 {} 片, 命中分片开始处理", i);}}}
}
4.6. 执行一次测试
4.7. 执行器效果
4.8. 结论
分片广播为了把数据进行分片处理,简言之,大量订单数据根据不同的订单号取模,分片机器分别处理属于自己片区的订单数据,减轻服务器压力。