分布式 on Liangweidong's blog

XXL-Job 分布式调度：可视化任务管理 + MySQL 初始化 + 容器化部署

Wed, 15 Nov 2023 00:00:00 +0800

XXL-Job 是国内最流行的分布式任务调度平台——替代 cron / ScheduledExecutorService 的核心组件。本篇把 Docker 化部署、MySQL 初始化、调度中心 / 执行器接入、告警通知整理清楚。

阅读对象：Java 后端 / 运维工程师 覆盖范围：XXL-Job 调度中心部署 + MySQL 初始化表结构 + 执行器注册 + 任务路由策略（轮询 / 故障转移 / 分片广播）+ 告警邮件 + docker-compose 完整集成

一、为什么需要分布式调度

传统定时任务的痛点：

单机 cron：服务器挂了任务就没了
ScheduledExecutorService：分布式下会重复执行（3 台机器都跑）
手动控制：凌晨 3 点被叫起来手动跑批

XXL-Job 的解决方案：

能力	说明
可视化管理	Web 端配置任务、查看日志、触发重跑
分布式执行	任务在多台执行器中只跑一次（通过路由策略）
任务分片	1 个任务广播到 10 台机器并行处理（10x 提速）
失败重试	自动重试 N 次，指数退避
告警通知	任务失败邮件 / 钉钉 / 飞书通知
GLUE 模式	Web 端直接写 Java / Shell / Python 脚本
任务依赖	父任务完成触发子任务（DAG）

When to use XXL-Job：

替代 crontab（跨服务器去重 + 可视化）

跑批任务（日终结算、数据归档）

第三方接口同步（每 5 分钟拉一次数据）

定时清理（30 天前的日志）

订单超时关闭（每分钟扫描一次）

二、架构原理

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


┌──────────────────┐ ┌──────────────────┐
│ 调度中心 (Admin) │◄──────────────►│ 执行器 (Executor)│
│ - 任务配置 │ 注册 │ - 业务服务 │
│ - 触发调度 │ │ - 接收任务 │
│ - 日志收集 │ │ - 执行回调 │
│ - 告警通知 │ │ │
└────────┬─────────┘ └──────────────────┘
 │
 ▼
 ┌──────────┐
 │ MySQL │
 │ (元数据) │
 └──────────┘

调度中心（Admin）：独立部署，Web 管理界面
执行器（Executor）：嵌入到业务服务里，通过 jar 包依赖
MySQL：存任务配置 / 执行日志 / 调度锁

核心协议：执行器启动时主动注册到调度中心；调度中心触发后通过 RPC 调执行器。

三、MySQL 初始化

3.1 下载 SQL 脚本

1
2


# XXL-Job 2.4.0 表结构
wget https://github.com/xuxueli/xxl-job/blob/2.4.0/doc/db/tables_xxl_job.sql

完整表结构：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


CREATE DATABASE IF NOT EXISTS `xxl_job` DEFAULT CHARSET utf8mb4;

USE `xxl_job`;

SET NAMES utf8mb4;

CREATE TABLE `xxl_job_info` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `job_group` int(11) NOT NULL COMMENT '执行器主键ID',
 `job_desc` varchar(255) NOT NULL,
 `add_time` datetime DEFAULT NULL,
 `update_time` datetime DEFAULT NULL,
 `author` varchar(64) DEFAULT NULL,
 `alarm_email` varchar(255) DEFAULT NULL,
 `schedule_type` varchar(50) NOT NULL DEFAULT 'NONE' COMMENT '调度类型',
 `schedule_conf` varchar(128) DEFAULT NULL COMMENT '调度配置',
 `misfire_strategy` varchar(50) NOT NULL DEFAULT 'DO_NOTHING',
 `executor_route_strategy` varchar(50) DEFAULT NULL,
 `executor_handler` varchar(255) DEFAULT NULL,
 `executor_param` varchar(512) DEFAULT NULL,
 `executor_block_strategy` varchar(50) DEFAULT NULL,
 `executor_timeout` int(11) NOT NULL DEFAULT '0',
 `executor_fail_retry_count` int(11) NOT NULL DEFAULT '0',
 `glue_type` varchar(50) NOT NULL COMMENT 'GLUE类型',
 `glue_source` mediumtext COMMENT 'GLUE源代码',
 `glue_remark` varchar(128) DEFAULT NULL,
 `glue_updatetime` datetime DEFAULT NULL,
 `child_jobid` varchar(255) DEFAULT NULL,
 `trigger_status` tinyint(4) NOT NULL DEFAULT '0',
 `trigger_last_time` bigint(13) NOT NULL DEFAULT '0',
 `trigger_next_time` bigint(13) NOT NULL DEFAULT '0',
 PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 还有：xxl_job_log, xxl_job_log_report, xxl_job_logglue, xxl_job_registry,
-- xxl_job_group, xxl_job_user, xxl_job_lock

8 张表：

表名	作用
`xxl_job_info`	任务配置
`xxl_job_log`	任务执行日志
`xxl_job_log_report`	日志报表
`xxl_job_logglue`	GLUE 源码历史
`xxl_job_registry`	执行器注册表
`xxl_job_group`	执行器分组
`xxl_job_user`	调度中心用户
`xxl_job_lock`	分布式锁

3.2 初始化用户

执行完 SQL 后，默认账号：admin / 123456（生产必改！）

四、调度中心部署

4.1 拉取镜像

1

docker pull xuxueli/xxl-job-admin:2.4.0

4.2 启动容器

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


docker run -d --restart=always --name xxl-job-admin \
 --net=host \
 -v /home/docker/xxl-job/data:/data \
 -e PARAMS=" \
 --spring.datasource.url=jdbc:mysql://10.0.1.1:3306/xxl_job?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true&serverTimezone=Asia/Shanghai \
 --spring.datasource.username=root \
 --spring.datasource.password={{DB_PASS}}" \
 -e JAVA_OPTS="-Xms2g -Xmx2g -Xmn1g -Xss1m \
 -XX:SurvivorRatio=8 \
 -XX:MetaspaceSize=256m \
 -XX:MaxMetaspaceSize=256m \
 -XX:NativeMemoryTracking=detail" \
 xuxueli/xxl-job-admin:2.4.0

关键参数：

--net=host：管理端口 8080 直接暴露
PARAMS：MySQL 连接信息
JAVA_OPTS：JVM 调优
数据卷 /data 持久化日志

4.3 访问调度中心

1
2


http://<IP>:8080/xxl-job-admin
默认账号：admin / 123456

4.4 docker-compose 完整版

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


version: "3"
services:
 mysql:
 image: mysql:8.0
 container_name: xxl-job-mysql
 restart: always
 environment:
 MYSQL_ROOT_PASSWORD: {{DB_ROOT_PASS}}
 volumes:
 - /home/xxl-job/mysql:/var/lib/mysql
 command: --default-authentication-plugin=mysql_native_password

 xxl-job-admin:
 image: xuxueli/xxl-job-admin:2.4.0
 container_name: xxl-job-admin
 restart: always
 depends_on:
 - mysql
 ports:
 - "8080:8080"
 volumes:
 - /home/xxl-job/logs:/data/applogs
 environment:
 PARAMS: >
 --spring.datasource.url=jdbc:mysql://mysql:3306/xxl_job?useUnicode=true&characterEncoding=UTF-8
 --spring.datasource.username=root
 --spring.datasource.password={{DB_ROOT_PASS}}
 JAVA_OPTS: "-Xms1g -Xmx1g"

首次启动：

启动 MySQL 容器
手动导入 tables_xxl_job.sql
启动 xxl-job-admin

五、执行器接入（业务服务）

5.1 添加依赖

1
2
3
4
5


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

5.2 配置 application.yml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


xxl:
 job:
 admin:
 addresses: http://xxl-job-admin.internal.example.com:8080/xxl-job-admin
 executor:
 appname: my-service
 address:
 ip:
 port: 9999
 logpath: /app/logs/xxl-job/jobhandler
 logretentiondays: 30
 accessToken: {{XXL_JOB_TOKEN}}

5.3 写任务 Handler

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


@Component
@JobHandler(value = "demoJobHandler")
public class DemoJobHandler extends IJobHandler {

 @Override
 public ReturnT<String> execute(String param) throws Exception {
 // 业务逻辑
 log.info("XXL-JOB Hello, param: {}", param);
 return ReturnT.SUCCESS;
 }
}

或者注解方式：

1
2
3
4
5


@XxlJob("myJobHandler")
public ReturnT<String> myJobHandler() throws Exception {
 // 业务逻辑
 return ReturnT.SUCCESS;
}

5.4 启动服务

业务服务启动时自动注册到调度中心，30 秒内在 Admin 后台 → 执行器管理看到。

六、任务配置

6.1 创建执行器

Admin → 执行器管理 → 新增：

1
2
3
4


AppName：my-service
名称：我的服务
注册方式：自动注册
机器地址：（自动填入）

6.2 创建任务

Admin → 任务管理 → 新增：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


执行器：my-service
任务描述：每日订单结算
调度类型：CRON
Cron：0 0 2 * * ? # 每天凌晨 2 点
运行模式：BEAN
JobHandler：demoJobHandler
路由策略：第一个
阻塞处理策略：单机串行
失败重试：3 次
告警邮件：ops@example.com

6.3 路由策略详解

策略	行为	适用
第一个	固定选第一台	任务不能并行
轮询	1→2→3→1→2→3	负载均衡
随机	随机选一台	简单场景
一致性 HASH	同参数同机器	分片场景
最不经常使用	选使用最少的	性能均衡
故障转移	失败后切下一台	高可用
忙碌转移	跳过忙碌选空闲	实时任务
分片广播	所有机器都跑	并行处理

6.4 分片广播实战

场景：10 万条订单待结算，1 台机器跑要 1 小时。

配置：

1

路由策略：分片广播

代码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


@XxlJob("settleOrdersJobHandler")
public ReturnT<String> settleOrdersJobHandler() throws Exception {
 // 分片参数
 int shardIndex = XxlJobHelper.getShardIndex(); // 当前分片（0 ~ shardTotal-1）
 int shardTotal = XxlJobHelper.getShardTotal(); // 总分片数

 // 假设有 10 万条待结算订单
 int total = 100000;
 int pageSize = total / shardTotal + 1;
 int from = shardIndex * pageSize;
 int to = Math.min(from + pageSize, total);

 // 处理 [from, to) 范围的订单
 List<Order> orders = orderDao.findPending(from, to);
 for (Order order : orders) {
 settle(order);
 }

 return ReturnT.SUCCESS;
}

效果：

5 台执行器 → 每台处理 2 万条 → 5x 提速

七、GLUE 模式

Web 端直接写代码——不用改业务服务：

7.1 GLUE Java

任务管理 → 选任务 → GLUE IDE → 写 Java：

1
2
3
4
5
6
7
8


public class GlueJobHandler extends IJobHandler {
 @Override
 public ReturnT<String> execute(String param) throws Exception {
 // 直接写业务逻辑
 // 注意：只能用 JDK 内置类，第三方类用不了
 return ReturnT.SUCCESS;
 }
}

适用：临时脚本（数据修复、临时跑批）。

7.2 GLUE Shell

1
2
3


#!/bin/bash
echo "xxl-job: hello shell"
echo "参数：$1"

7.3 GLUE Python

1
2
3
4
5
6


#!/usr/bin/env python
# -*- coding: UTF-8 -*-
import os
import sys
print("xxl-job: hello python")
print("参数：", sys.argv[1])

7.4 GLUE PHP / Node.js

类似，不展开。

八、告警通知

8.1 邮件告警

任务配置：

1

告警邮件：ops@example.com

Admin application.yml：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


spring:
 mail:
 host: smtp.example.com
 port: 465
 username: noreply@example.com
 password: {{SMTP_PASS}}
xxl:
 job:
 triggerpool:
 fast:
 max: 200

8.2 钉钉告警

自定义告警实现：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


@Component
public class DingTalkJobAlarm implements JobAlarm {
 @Override
 public boolean doAlarm(XxlJobInfo info, XxlJobLog log) {
 // 调钉钉 Webhook
 String text = String.format("任务 [%s] 执行失败\n日志：%s", 
 info.getJobDesc(),
 log.getHandleMsg());
 DingTalk.send("{{DINGTALK_TOKEN}}", text);
 return true;
 }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


@Configuration
public class XxlJobConfig {
 @Bean
 public XxlJobSpringExecutor xxlJobExecutor() {
 XxlJobSpringExecutor executor = new XxlJobSpringExecutor();
 executor.setAdminAddresses("http://xxl-job-admin:8080/xxl-job-admin");
 executor.setAppname("my-service");
 executor.setJobAlarm(new DingTalkJobAlarm()); // 自定义告警
 return executor;
 }
}

九、监控与日志

9.1 任务执行日志

任务管理 → 选任务 → 操作 → 日志 → 看每次执行：

触发时间
执行结果（成功 / 失败 / 调度失败）
耗时
失败原因（堆栈）
重试次数

日志保留：xxl.job.executor.logretentiondays=30（默认 30 天）。

9.2 调度报表

Admin → 调度报表：

1
2


成功 / 失败 / 调度失败 / 总数
按日 / 周 / 月 聚合

实战用法：每周一看上周的报表，任务成功率 < 99% 就要查问题。

9.3 告警指标

接入 Prometheus（自定义 exporter）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


@Aspect
@Component
public class XxlJobMetricsAspect {
 @Around("@annotation(com.xxl.job.core.handler.annotation.XxlJob)")
 public void track(ProceedingJoinPoint pjp) throws Throwable {
 long start = System.currentTimeMillis();
 try {
 pjp.proceed();
 Metrics.counter("xxl_job_success", "name", pjp.getSignature().getName()).increment();
 } catch (Exception e) {
 Metrics.counter("xxl_job_failure", "name", pjp.getSignature().getName()).increment();
 } finally {
 Metrics.timer("xxl_job_duration", "name", pjp.getSignature().getName())
 .record(System.currentTimeMillis() - start, TimeUnit.MILLISECONDS);
 }
 }
}

十、典型坑位

10.1 任务执行但 Admin 看不到日志

症状：执行器跑完了任务，Admin 端日志查询不到。

原因：执行器 xxl.job.executor.logpath 路径配置错误。

修复：

1
2
3
4


xxl:
 job:
 executor:
 logpath: /data/applogs/xxl-job/jobhandler  # 必须是绝对路径

容器内注意：路径要在挂载卷内（否则容器重启日志丢）。

10.2 任务调度延迟

症状：任务应该 2 点跑，实际 2:05 才跑。

原因：

调度中心集群只 1 台，单点压力
任务太多（> 1000 个），调度中心处理不过来

修复：

调度中心集群部署
减少短间隔任务（每分钟 1 次的太多）
加大 xxl.job.triggerpool.fast.max

10.3 任务重复执行

症状：1 个任务在 2 台机器都跑了。

原因：路由策略选错（**不能用"分片广播"**用于只能跑 1 次的任务）。

修复：选 故障转移 或 第一个（默认）。

10.4 GLUE 模式不能用第三方类

修复：

1
2


GLUE Java 只能用 JDK 内置类
要用 Spring Bean，注解 @XxlJob

十一、生产部署清单

11.1 调度中心高可用

两台调度中心集群：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 调度中心 1
xxl-job-admin:
 ports: 8080
 environment:
 PARAMS: "--xxl.job.accessToken={{TOKEN}}"

# 调度中心 2
xxl-job-admin:
 ports: 8080
 environment:
 PARAMS: "--xxl.job.accessToken={{TOKEN}}"

执行器配置 2 个地址：

1
2
3
4


xxl:
 job:
 admin:
 addresses: http://admin1:8080/xxl-job-admin,http://admin2:8080/xxl-job-admin

任务触发时会轮询选一个调度中心。

11.2 数据库高可用

1
2
3
4
5
6


# MySQL 主从 + 读写分离
spring:
 datasource:
 url: jdbc:mysql://mysql-primary:3306/xxl_job
 # 读流量大的话可加：
 # url: jdbc:mysql:loadbalance://mysql-primary:3306,mysql-replica:3306/xxl_job

11.3 监控

Prometheus 抓 Admin metrics
告警规则：
- 任务失败率 > 5% → 告警
- 调度延迟 > 5 分钟 → 告警
- 调度中心内存 > 80% → 告警

十二、完整 docker-compose

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


version: "3.8"
services:
 mysql:
 image: mysql:8.0
 container_name: xxl-job-mysql
 restart: always
 environment:
 MYSQL_ROOT_PASSWORD: {{DB_ROOT_PASS}}
 volumes:
 - /home/xxl-job/mysql:/var/lib/mysql
 networks:
 - xxl-net

 xxl-job-admin:
 image: xuxueli/xxl-job-admin:2.4.0
 container_name: xxl-job-admin
 restart: always
 depends_on:
 - mysql
 ports:
 - "8080:8080"
 volumes:
 - /home/xxl-job/logs:/data/applogs
 environment:
 PARAMS: >
 --spring.datasource.url=jdbc:mysql://mysql:3306/xxl_job?useUnicode=true&characterEncoding=UTF-8&serverTimezone=Asia/Shanghai
 --spring.datasource.username=root
 --spring.datasource.password={{DB_ROOT_PASS}}
 --xxl.job.accessToken={{XXL_JOB_TOKEN}}
 JAVA_OPTS: "-Xms1g -Xmx1g -XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0"
 networks:
 - xxl-net

networks:
 xxl-net:
 driver: bridge

十三、最佳实践清单

MySQL 8.0 + utf8mb4——中文支持好
调度中心至少 2 台集群——避免单点
路由策略根据场景选：
- 跑批任务 → 故障转移（高可用）
- 同步任务 → 分片广播（并行）
- 普通定时 → 第一个（避免重复）
告警邮件必开——失败 5 分钟内收到
任务日志保留 30 天——logretentiondays=30
失败重试 3 次——临时网络抖动不报错
执行器 ip+port 唯一——xxl.job.executor.ip 显式指定
GLUE 用于临时脚本——生产任务用 @XxlJob 注解
JVM 调优：UseContainerSupport + MaxRAMPercentage
任务配置备份：MySQL 定期 dump

2024+ 视角补充

本文写于 2023-11，2024-2026 期间 XXL-Job / 分布式调度生态关键演进：

XXL-Job 2.4+ → 2.5+（2024-2025）：Spring Boot 3.x 兼容；JDK 17 强制；K8s 原生调度（不再依赖固定 IP）
XXL-Job 2.5+：内置 OpenTelemetry 集成；Web IDE 增强（GLUE Java 支持 Spring Bean）
PowerJob 5.x（2024-2025）：K8s 原生 Worker（动态注册）；DAG 工作流 2.0；MapReduce 性能 10x——vs XXL-JOB 更现代
DolphinScheduler 3.2+（2024-2026）：Apache 顶级项目；大数据集成（Spark / Flink / Hive）；K8s 调度原生；多租户 + 工作流 3.0
Airflow 2.10+（2024-2026）：Python 系首选；TaskFlow API（Pythonic DAG）；Kubernetes Executor 2.0
Temporal 1.25+（2024-2026）：Workflow-as-Code 之王——状态机 + 长期运行任务首选
KubeVela 1.10+：云原生应用编排——微服务编排 + 灰度发布
Serverless Cron：AWS EventBridge Scheduler / 阿里云定时任务 / GCP Cloud Scheduler 2024+ 仍是云端首选

实战建议（2025-2026 视角）：

Java 业务定时任务 → XXL-Job 2.5+（轻量、上手快）或 PowerJob 5.x（更现代）
大数据 / 离线数仓 → DolphinScheduler 3.2+（Apache 顶级项目）
Python 系 → Airflow 2.10+
复杂工作流 / 长期任务 → Temporal 1.25+（2024-2026 趋势）
Serverless / 简单定时 → 云厂商 EventBridge / 定时任务

下一步

想看 JDK 自建镜像实战（Alpine / Debian / Ubuntu）→ JDK 自建镜像实战
想看 Java 应用 Docker 化（Tomcat / Spring Boot 打包）→ Java 应用 Docker 化
想看 Java 微服务治理（Sentinel 限流 / Spring Boot Admin）→ Java 微服务治理
想看 Nginx 自建镜像实战（反代安全加固）→ Nginx 自建镜像实战

Spring Cloud Alibaba 整体架构与 7 大分布式问题

Tue, 15 Sep 2020 00:00:00 +0800

本文写于 2020 年 9 月——Spring Cloud Alibaba 在 2018 年诞生，2019 年进入 Apache 孵化，2020 年成为事实上的国内微服务标准。

一、Spring Cloud vs Spring Cloud Alibaba

1.1 Spring Cloud 是什么

Spring Cloud 是一套分布式微服务解决方案。区别于 Dubbo（只是一个远程 RPC 框架），Spring Cloud 是一整套生态，包括：

服务注册 / 服务调用
负载均衡
服务网关
服务降级 / 熔断
分布式配置管理
消息总线
链路跟踪
……

Spring Cloud 自成生态。

1.2 为什么还需要 Spring Cloud Alibaba

Spring Cloud 进入维护阶段——版本迭代非常快，每发布一个 release 后又会紧接着发布下一个版本，积累了一系列 bug，使用过程中问题频出。

进入维护模式意味着不会再有新的组件技术出现，只是在原来的基础上修修补补，处理一些 merge 和 PR 请求。

剧本：几年前 Dubbo 被 Spring Cloud 取代。现在 Spring Cloud 停更，谁来补位？

阿里和 Spring 社区都是巨头，巨头之间战斗要考虑很多，于是想到了合作：

Spring 社区负责 Spring 基础
阿里负责新组件 + 推广阿里云 + 商业软件
双赢 → Spring Cloud Alibaba 诞生

1.3 一句话总结

Spring Cloud Alibaba = Spring Cloud 的中国化继任者，由阿里主导持续更新。

二、Spring Cloud Alibaba 16 大核心组件

按应用层从外到内：

2.1 服务治理层

#	组件	功能	替代关系
1	Nacos	服务注册 + 发现	替代 Eureka + Consul
2	Nacos Config	统一配置中心	替代 Spring Cloud Config
3	Spring Cloud Gateway	路由网关	替代 Zuul
4	OpenFeign	分布式 HTTP 调用	替代 Ribbon + RestTemplate
5	Sentinel	熔断 / 降级 / 限流	替代 Hystrix
6	Spring Boot Admin	服务监控	自研方案

2.2 数据 & 存储层

#	组件	功能	替代关系
7	MinIO / 阿里 OSS	分布式文件	自研 FS
8	RocketMQ / RabbitMQ	消息中间件	替代 ActiveMQ
9	Seata	分布式事务	替代 TCC 自研

2.3 平台 & 运维层

#	组件	功能
10	xxl-job	分布式任务调度
11	SkyWalking	链路跟踪（APM）
12	ELK + Kafka	分布式日志收集
13	JWT + Shiro	统一权限控制
14	CAS / sa-token	单点登录
15	docker-compose / K8s / Jenkins	部署 & 流水线
16	Sentinel（路由限流模式）	入口限流

三、技术架构图

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


 ┌──────────────────┐
 │ Nginx / SLB │
 │ (入口 LB) │
 └─────────┬────────┘
 │
 ┌─────────▼────────┐
 │ Spring Cloud │
 │ Gateway 网关层 │
 │ (路由/限流/鉴权) │
 └─────────┬────────┘
 │
 ┌─────────────────────────┼─────────────────────────┐
 │ │ │
 ┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────┐
 │ 用户服务 │ │ 订单服务 │ │ 商品服务 │
 │ (集群) │ │ (集群) │ │ (集群) │
 └──────┬──────┘ └──────┬──────┘ └──────┬──────┘
 │ │ │
 └─────────────────────────┼─────────────────────────┘
 │
 ┌────────────────┬────────────┼────────────┬────────────────┐
 │ │ │ │ │
 ┌────▼────┐ ┌─────▼────┐ ┌─────▼────┐ ┌────▼────┐ ┌─────▼────┐
 │ Nacos │ │ Redis │ │ MySQL │ │ MQ │ │ Seata │
 │ 注册/配置│ │ 缓存 │ │ 存储 │ │ 消息 │ │ 分布式事务│
 └─────────┘ └──────────┘ └──────────┘ └─────────┘ └──────────┘

四、服务器集群后产生的 7 大问题

单节点应用升级到集群后，本地假设全部失效，必须解决以下 7 大分布式问题：

4.1 分布式锁

问题：多节点同时操作同一资源，需要互斥。

方案：

Redis SETNX + Lua：最常用，性能高
Redisson：Java 客户端封装，可重入锁 / 公平锁 / 读写锁
Zookeeper 顺序节点：强一致，性能略低
MySQL 行锁 / 表锁：能不用就不用

4.2 分布式全局 ID

问题：单库自增 ID 在分库分表后会重复。

方案：

雪花算法（Snowflake）：Twitter 开源，64 位（1 符号 + 41 时间戳 + 10 机器 + 12 序列号）
UUID：简单但 128 位太长，无序
美团 Leaf：号段模式 / Snowflake 增强版
百度 UidGenerator：基于 Snowflake 优化

4.3 分布式 Session 一致性

问题：用户登录后 Session 存在单节点，下次请求被路由到另一节点就丢失登录态。

方案：

Session 复制：Tomcat 自带，性能差
客户端存储：JWT（无状态，Token 放在 Header）
统一 Session 存储：Spring Session + Redis（推荐）
Session 粘性（IP Hash）：Nginx ip_hash，但扩缩容困难

4.4 分布式事务

问题：跨服务调用，本地事务无法保证全局一致。

方案：

2PC / 3PC：强一致但性能差
TCC（Try-Confirm-Cancel）：业务侵入大，性能好
本地消息表：最终一致，简单
RocketMQ 事务消息：最终一致，推荐
Seata AT 模式：无业务侵入，最常用

4.5 分布式任务调度

问题：多节点都跑定时任务会重复执行。

方案：

xxl-job：大众点评开源，业界事实标准
Elastic-Job：当当网开源，分片支持好
Quartz Cluster：老牌方案，配置复杂
Spring Task + ShedLock：基于数据库锁的轻量方案

4.6 分布式日志收集

问题：日志散落在几十台机器上，排查故障要逐台登录。

方案：

ELK（Elasticsearch + Logstash + Kibana）：经典
EFK（Fluentd）：K8s 时代更轻量
Loki + Promtail + Grafana：标签索引，比 ES 便宜
SkyWalking / Pinpoint：APM 工具自带 traceId 串联

4.7 分布式配置中心

问题：配置散落在每个服务的 application.yml 里，改一个配置要重启几十个服务。

方案：

Nacos Config：自带，推荐
Apollo：携程开源，功能强大
Spring Cloud Config：老牌，依赖 Git
Consul KV：也行

五、面试常问

Q：Spring Cloud 和 Spring Cloud Alibaba 怎么选？ A：

新项目：直接 Spring Cloud Alibaba
老 Spring Cloud Netflix 项目：保留但不再升级
国内大厂项目：Spring Cloud Alibaba + 自研
国际化项目：Spring Cloud + Kubernetes（云原生）

Q：Seata AT 模式的原理是什么？ A：基于全局锁 + 快照 + 回滚日志——每个分支事务：

解析 SQL → 生成前镜像 + 后镜像 + 回滚日志
提交本地事务，释放本地锁
申请全局锁（Seata Server 协调）
根据全局决议，异步删除回滚日志（提交）或回滚（用后镜像恢复前镜像）

无业务侵入，业务代码只需加 @GlobalTransactional 注解。

Q：Nacos 和 Eureka 有什么区别？ A：Nacos 同时支持 AP（Distro）和 CP（Raft），Eureka 只支持 AP。Nacos 自带配置中心，Eureka 纯注册中心。Nacos 是更好的选择。

Q：Sentinel 和 Hystrix 有什么区别？ A：Hystrix 已停更，Sentinel 持续维护。Sentinel 控制台更强大（实时监控 / 簇点链路 / 规则动态推送），规则支持流控 / 降级 / 热点 / 系统 / 授权 5 大类。

六、整体技术选型清单（中小厂推荐）

类别	推荐组件	理由
注册中心	Nacos	一体化（注册 + 配置）
网关	Spring Cloud Gateway	响应式 + Netty
RPC	OpenFeign	声明式 + Ribbon 集成
熔断限流	Sentinel	规则丰富 + 控制台
分布式事务	Seata AT	无业务侵入
分布式锁	Redisson	完整封装
分布式任务	xxl-job	成熟 + 可视化
消息	RocketMQ	事务消息 + 顺序消息
日志	ELK	经典方案
链路跟踪	SkyWalking	国产 + 字节码增强
配置中心	Nacos Config	一体化

七、小结

Spring Cloud Alibaba = Spring Cloud 中国化继任者
16 大核心组件覆盖服务治理 / 数据存储 / 平台运维全链路
7 大分布式问题（锁/ID/Session/事务/任务/日志/配置）是集群化的必修课
选型原则：先选生态最完整的方案（Nacos + Sentinel + Seata 三件套），再考虑业务侵入度

限流算法完全对比：固定窗口、滑动窗口、漏桶与令牌桶

Mon, 23 Sep 2019 00:00:00 +0000

在高并发系统中，限流（Rate Limiting）是保护下游服务不被突发流量打挂的核心手段。限流算法家族里，最常见的 4 个成员是：固定窗口计数器、滑动窗口计数器、漏桶算法、令牌桶算法。它们各有取舍，分别适用于不同的业务场景。这篇文章会带你用 4 张原理图 + 代码实现 + 选型建议，把这 4 个算法彻底讲透。

为什么学限流？ 限流是后端面试几乎必考的题目（无论是社招还是校招），因为它同时考察你算法理解、并发编程、系统设计三大能力。更重要的是，主流的微服务网关（Spring Cloud Gateway / Sentinel / Kong / Envoy）底层都跑着这些算法。

一、为什么需要限流？

在动手学算法之前，先搞清楚"限流到底在防什么"：

风险	说明
雪崩	一个慢下游拖垮整个调用链
资源耗尽	数据库连接池/线程池被打满
恶意流量	爬虫/羊毛党/CC 攻击
突发流量	秒杀、热点事件、明星离婚导致 10x 流量尖刺

限流的目标是：在系统容量范围内接待尽可能多的"好"请求，把"坏"请求挡在外面。

二、固定窗口计数器（Fixed Window Counter）

2.1 算法原理

图源说明：上图来自原 限流/算法.md 文档，展示了固定窗口计数器把时间轴切成等长窗口（图中每个矩形就是一个窗口），每个窗口内独立计数的结构。

核心思想：

将时间划分为多个等长的窗口（例如 1 秒一个窗口）
在每个窗口内每来一个请求就将计数器加一
如果计数器超过了限制数量，则本窗口内所有的请求都被丢弃
当时间到达下一个窗口时，计数器重置

2.2 致命缺陷：边界双倍突发

固定窗口是最简单的算法，但有一个著名的"边界问题"——它可能让通过请求量允许为限制的两倍。

图源说明：上图演示了"边界双倍突发"问题。

例子：限制 1 秒内最多通过 5 个请求。

第 1 个窗口的最后半秒：通过了 5 个请求
第 2 个窗口的前半秒：又通过了 5 个请求

看起来是在 1 秒内通过了 10 个请求——两倍于限制！系统在临界点承受了远超设计容量的压力。

2.3 代码实现

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


import time

class FixedWindowRateLimiter:
 """固定窗口计数器：实现最简单，但有边界双倍突发的风险"""
 def __init__(self, limit: int, window_seconds: int):
 self.limit = limit
 self.window = window_seconds
 self.count = 0
 self.window_start = int(time.time())

 def allow(self) -> bool:
 now = int(time.time())
 if now - self.window_start >= self.window:
 # 进入新窗口
 self.window_start = now
 self.count = 0
 if self.count < self.limit:
 self.count += 1
 return True
 return False

2.4 优缺点

优点	缺点
实现最简单（一个计数器 + 一个时间戳）	边界双倍突发问题
内存占用最小	窗口切换时可能"突然丢一半请求"
单机/分布式都好实现	不适合"严格平滑限流"的场景

三、滑动窗口计数器（Sliding Window Counter）

3.1 算法原理

图源说明：上图展示了滑动窗口计数器把每个窗口再细分成多个小时间区间，并按时间"滑动"的机制。

核心思想：

将时间划分为多个小时间区间（如 1 秒的窗口再分成 10 个 100ms 的子区间）
在每个子区间内每来一个请求就将该子区间的计数器加一
维持一个时间窗口，占据多个子区间
每经过一个子区间的时间，则抛弃最老的一个子区间，并纳入最新的一个子区间
如果当前窗口内所有子区间的请求计数总和超过了限制数量，则本窗口内所有的请求都被丢弃

3.2 为什么解决了边界问题？

滑动窗口通过"细分 + 滑动"避免了固定窗口的双倍突发——窗口的边界是连续滑动的，不会突然从一个干净状态跳到满载状态。

3.3 精度与空间的权衡

子区间数量	精度	内存占用（每个用户）
1（=固定窗口）	最粗	O(1)
10	中	O(10)
60	细	O(60)
1000	很高	O(1000)

子区间越多，限流越精准，但每个用户/接口的内存占用越大。Cloudflare 公开的方案里就用 60 个子区间的滑动窗口。

3.4 代码实现

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


import time
from collections import deque

class SlidingWindowRateLimiter:
 """滑动窗口计数器：精度高，能避免固定窗口的边界双倍突发"""
 def __init__(self, limit: int, window_seconds: int):
 self.limit = limit
 self.window = window_seconds
 # 存 (时间戳, )，每次清理掉超过 window 的旧时间戳
 self.timestamps: deque[float] = deque()

 def allow(self) -> bool:
 now = time.time()
 # 弹出过期的时间戳
 while self.timestamps and self.timestamps[0] <= now - self.window:
 self.timestamps.popleft()
 if len(self.timestamps) < self.limit:
 self.timestamps.append(now)
 return True
 return False

3.5 优缺点

优点	缺点
解决了固定窗口的边界问题	内存占用更大
精度可调	实现稍复杂
适合 API 限流、爬虫限频	单机原子性需要锁/原子操作

四、漏桶算法（Leaky Bucket）

4.1 算法原理

图源说明：上图展示了漏桶算法把请求视作"水滴"放入"漏桶"，再以固定速率向外"漏"出请求的机制。

核心思想：

将每个请求视作"水滴"放入"漏桶"进行存储
“漏桶"以固定速率向外"漏"出请求来执行
如果"漏桶"空了则停止"漏水”
如果"漏桶"满了则多余的"水滴"会被直接丢弃

4.2 核心特性：强制平滑输出

漏桶最大的特点是输出速率恒定——无论进来的流量多不均匀，出去的速率永远是 leak_rate。这非常适合"下游服务处理能力固定“的场景（如调用银行接口、调用第三方 API）。

4.3 缺陷：无法应对突发

漏桶的缺陷也很明显——当短时间内有大量的突发请求时，即便此时服务器没有任何负载，每个请求也都得在队列中等待一段时间才能被响应。换句话说：它把"突发"给"抹平"了。

4.4 代码实现

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


import time
from collections import deque

class LeakyBucketRateLimiter:
 """漏桶算法：强制平滑输出，适合下游处理能力固定的场景"""
 def __init__(self, capacity: int, leak_rate_per_sec: float):
 """
 :param capacity: 桶容量
 :param leak_rate_per_sec: 每秒漏出的水滴数
 """
 self.capacity = capacity
 self.leak_rate = leak_rate_per_sec
 self.queue: deque[float] = deque()
 self.last_leak_time = time.time()

 def _leak(self):
 """把超过当前时间该漏出的水滴都漏掉"""
 now = time.time()
 elapsed = now - self.last_leak_time
 leaked = int(elapsed * self.leak_rate)
 if leaked > 0:
 for _ in range(min(leaked, len(self.queue))):
 self.queue.popleft()
 self.last_leak_time = now

 def allow(self) -> bool:
 self._leak()
 if len(self.queue) < self.capacity:
 self.queue.append(time.time())
 return True
 return False

4.5 优缺点

优点	缺点
输出绝对平滑，保护下游	抹掉突发——空闲时也无法利用富余容量
队列机制天然支持"等待"语义	需要额外的队列/定时器
实现直观	延迟 = 队列长度 / 漏出速率

五、令牌桶算法（Token Bucket）

5.1 算法原理

图源说明：上图展示了令牌桶算法以固定速率生成令牌、请求来临时取令牌的工作机制。

核心思想：

令牌以固定速率生成
生成的令牌放入令牌桶中存放，如果令牌桶满了则多余的令牌会直接丢弃
当请求到达时，会尝试从令牌桶中取令牌
取到了令牌的请求可以执行
如果桶空了，那么尝试取令牌的请求会被直接丢弃

5.2 为什么是"工业界默认”？

令牌桶既能够将所有的请求平均分布到时间区间内，又能接受服务器能够承受范围内的突发请求——这两点恰好是漏桶和固定窗口都做不到的：

平均限流：长期平均速率 = 令牌生成速率
允许突发：桶里积攒的令牌可以一次性被突发请求用完
平滑降级：桶空了就拒绝，不会让下游被打挂

因此 Guava RateLimiter、Nginx limit_req、AWS API Gateway、Spring Cloud Gateway 等都默认使用令牌桶或它的变体。

5.3 代码实现

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


import time
import threading

class TokenBucketRateLimiter:
 """令牌桶算法：兼顾平滑限流 + 允许突发，是工业界最常用的限流算法"""
 def __init__(self, capacity: int, refill_rate_per_sec: float):
 """
 :param capacity: 桶容量（即最大突发量）
 :param refill_rate_per_sec: 每秒生成的令牌数（平均限流速率）
 """
 self.capacity = capacity
 self.refill_rate = refill_rate_per_sec
 self.tokens = float(capacity) # 初始满桶
 self.last_refill_time = time.time()
 self._lock = threading.Lock()

 def allow(self, cost: float = 1.0) -> bool:
 with self._lock:
 now = time.time()
 # 补充令牌：自上次以来应该生成的令牌数
 elapsed = now - self.last_refill_time
 self.tokens = min(self.capacity, self.tokens + elapsed * self.refill_rate)
 self.last_refill_time = now
 # 取令牌
 if self.tokens >= cost:
 self.tokens -= cost
 return True
 return False

5.4 优缺点

优点	缺点
兼顾平均限流 + 突发	实现比固定/滑动窗口复杂
工业界事实标准	桶容量需要根据业务调优
Guava / Nginx / Sentinel 都内置	分布式实现需要原子操作（Redis + Lua）

六、四大算法对比

维度	固定窗口	滑动窗口	漏桶	令牌桶
时间复杂度	O(1)	O(N)	O(1)	O(1)
空间复杂度	O(1)	O(N)	O(队列长)	O(1)
实现难度	★	★★	★★★	★★★
平滑输出	✗	✗	✓ 绝对平滑	△ 平均平滑、允许突发
允许突发	△ 边界双倍	△	✗ 抹平突发	✓ 可控突发
边界问题	✗ 有	✓ 无	✓ 无	✓ 无
典型应用	简单统计	Cloudflare	消息队列 / 网络整形	API 网关 / Nginx

七、核心要点与常见坑

7.1 核心 N 点

固定窗口有"边界双倍突发"问题——限制 1 秒 5 个，可能 1 秒放 10 个
滑动窗口把窗口细分并滑动，是固定窗口的精准化升级，但内存占用和精度成正比
漏桶强制平滑输出，抹掉突发——空闲时也无法"加速消化"
令牌桶兼顾平均限流 + 可控突发，是工业界事实标准——Guava/Nginx/Sentinel 都用它
限流本质是保护下游——算法选型要回答"下游怕什么"：怕突发 → 漏桶；怕长期过载 → 令牌桶
分布式限流需要共享计数器（Redis + Lua 脚本 / Redis Cell 模块），单机限流直接用进程内限流器即可

7.2 常见 M 个坑

混淆"算法粒度"和"限流维度"——限流可以按 IP / User ID / 接口 / 租户，算法本身和粒度无关
桶容量设得太大——突发可能把下游打挂
桶容量设得太小——失去了"应对正常抖动"的能力
漏桶的"等待"语义被忽略——某些业务根本不能等，直接拒绝更友好
限流后没有兜底——被拒绝的请求要返回友好的错误（429 + Retry-After）
单机限流当成分布式限流用——多机部署时总速率会变成"单机限制 × 机器数"
限流开关没接入监控——出问题时根本不知道是谁在打

八、工业级实践

8.1 Guava `RateLimiter`（单机令牌桶）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// 创建一个每秒生成 5 个令牌的限流器（即平均 200ms 一个）
RateLimiter limiter = RateLimiter.create(5.0);

if (limiter.tryAcquire()) {
 // 拿到令牌，处理请求
 handleRequest();
} else {
 // 没拿到令牌，直接拒绝
 return Response.status(429).build();
}

8.2 Nginx `limit_req`（基于令牌桶）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# 定义一个名为 my_limit 的限流区：
# 10m 共享内存大小
# rate=10r/s 平均 10 个请求/秒
# burst=20 桶容量 20（允许最大 20 个突发）
# nodelay 突发请求不延迟直接处理
limit_req_zone $binary_remote_addr zone=my_limit:10m rate=10r/s;

server {
 location /api/ {
 limit_req zone=my_limit burst=20 nodelay;
 proxy_pass http://backend;
 }
}

8.3 Redis + Lua 分布式令牌桶

单机的 RateLimiter 只对单进程有效，分布式场景需要共享计数器。常见做法是 Redis + Lua 脚本保证原子性：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


-- KEYS[1]: 令牌桶的 key
-- ARGV[1]: 桶容量
-- ARGV[2]: 填充速率（每秒）
-- ARGV[3]: 当前时间戳（秒）
-- ARGV[4]: 请求消耗的令牌数

local capacity = tonumber(ARGV[1])
local rate = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local cost = tonumber(ARGV[4])

local data = redis.call('HMGET', KEYS[1], 'tokens', 'last_refill')
local tokens = tonumber(data[1]) or capacity
local last_refill = tonumber(data[2]) or now

-- 补充令牌
local elapsed = math.max(0, now - last_refill)
tokens = math.min(capacity, tokens + elapsed * rate)

if tokens >= cost then
 tokens = tokens - cost
 redis.call('HMSET', KEYS[1], 'tokens', tokens, 'last_refill', now)
 redis.call('EXPIRE', KEYS[1], 60) -- 60 秒没访问就清掉
 return 1
else
 redis.call('HMSET', KEYS[1], 'tokens', tokens, 'last_refill', now)
 return 0
end

8.4 选型速查

场景	推荐算法	理由
简单统计、QPS 监控	固定窗口	最简单
API 限流、爬虫限频	滑动窗口	精度高，无边界问题
调用第三方固定速率 API	漏桶	强制平滑，保护合作方
API 网关、Nginx、Sentinel	令牌桶	兼顾平均 + 突发，工业标准
秒杀抢购	令牌桶 + 排队	削峰填谷
分布式系统	令牌桶 + Redis/Lua	多机共享状态

参考资料

PowerJob 分布式任务调度实战：可视化控制台 + 容器化部署 + 故障转移

Fri, 20 Sep 2019 00:00:00 +0800

PowerJob 分布式任务调度实战：可视化控制台 + 容器化部署 + 故障转移

背景与价值

分布式任务调度是后端系统的"水电煤"——定时报表、订单关闭、数据同步、对账、清理、推送都依赖它。Java 生态对比：

框架	维护方	特性	适合
Quartz	Terracotta	老牌单体，集群需自己实现	传统企业单体应用
XXL-Job	大众点评	经典分布式，轻量	中小型项目
Elastic-Job	当当 + Apache	生态丰富，依赖 ZK	大型分布式
PowerJob	QQ 音乐	新一代，多语言，Workflow	复杂业务编排
Spring Schedule	Spring	简单，但无分布式	单机

本文聚焦 PowerJob V4.3.9（2024-03 GA），最大的卖点是"可视化工作流"——可以用 DAG 编排多作业的复杂依赖关系，比 XXL-Job 的"作业依赖"更强大。

核心架构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


┌────────────────────────────────────────┐
│ PowerJob Server │
│ (调度中心，端口 7700 HTTP / 10010 OMS)│
│ ┌──────────┐ ┌──────────┐ ┌────────┐ │
│ │ 调度器 │ │ 执行器 │ │ 控制台 │ │
│ └─────┬────┘ └─────┬────┘ └────┬───┘ │
└────────┼────────────┼──────────┼──────┘
 │ │ │
 ↓ ↓ ↓
┌────────────────────────────────────────┐
│ Worker 集群 │
│ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │Worker│ │Worker│ │Worker│ │
│ │ 1 │ │ 2 │ │ 3 │ │
│ └──────┘ └──────┘ └──────┘ │
└────────────────────────────────────────┘
 ↓
 MySQL（持久化）

三大组件：

Server：调度中心，1 个或 3 节点集群
Worker：业务执行器，部署在业务应用内
MySQL：存储任务定义 + 执行历史

Server 部署

1. 初始化数据库

1
2
3
4
5
6
7


# 1. 创建数据库
mysql -u root -p{{MYSQL_PASSWORD}} -e \
 "CREATE DATABASE powerjob CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"

# 2. 初始化表结构
# https://github.com/PowerJob/PowerJob/blob/v4.3.9/others/powerjob-mysql.sql
mysql -u root -p{{MYSQL_PASSWORD}} powerjob < powerjob-mysql.sql

2. Docker Compose 一键部署（推荐）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


# docker-compose.yml
version: '3'
services:
 powerjob-server:
 image: powerjob/powerjob-server:V4.3.9
 container_name: powerjob
 restart: always
 network_mode: host
 environment:
 - TZ=Asia/Shanghai
 - PARAMS=--spring.profiles.active=product \
 --spring.datasource.core.jdbc-url=jdbc:mysql://{{MYSQL_HOST}}:3306/powerjob?useUnicode=true&characterEncoding=UTF-8 \
 --spring.datasource.core.username={{DB_USER}} \
 --spring.datasource.core.password={{DB_PASSWORD}} \
 --oms.http.port=10010 \
 --server.address={{SERVER_IP}}
 volumes:
 - /data/powerjob-server:/root/powerjob/server
 - ~/.m2:/root/.m2

1

docker-compose up -d

3. 端口规划

端口	用途
7700	HTTP 服务（控制台 + API）
10010	OMS（运维管理）
10086	Akka 节点间通信（集群）

4. 控制台访问

1

http://{{SERVER_IP}}:7700

默认账号：内置 admin（首次登录强制改密）。

Worker 集成（业务应用）

1. 引入依赖

1
2
3
4
5


<dependency>
 <groupId>tech.powerjob</groupId>
 <artifactId>powerjob-worker-spring-boot-starter</artifactId>
 <version>4.3.9</version>
</dependency>

2. application.yml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


powerjob:
 worker:
 enabled: true
 allow-lazy-connect-server: false # 启动时立即连 Server
 port: 9988
 app-name: my-application  # 必须与 Server 中注册的应用名一致
 server-address: {{SERVER_HOST}}:7700
 protocol: http
 store-strategy: disk  # 上下文存储：disk / memory
 max-result-length: 4096
 max-appended-wf-context-length: 4096

3. 注册应用（关键步骤）

首次启动 Worker 前必须先在 Server 控制台注册应用：

1
2


应用名：my-application # 与 worker 配置的 app-name 一致
密码：{{APP_SECRET}} # 自定义

否则 Worker 启动会报"应用未注册"。

4 大处理器类型

1. BasicProcessor（基础，单机执行）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


@Component
public class SimpleJob implements BasicProcessor {

 @Override
 public ProcessResult process(TaskContext context) throws Exception {
 String jobParams = context.getJobParams(); // 任务参数
 long instanceId = context.getInstanceId(); // 实例 ID
 log.info("任务执行: instanceId={}, params={}", instanceId, jobParams);

 // 返回执行结果
 return new ProcessResult(true, "执行成功 " + System.currentTimeMillis());
 }
}

2. BroadcastProcessor（广播，所有 Worker 都执行一次）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


@Component
public class ClearCacheJob implements BroadcastProcessor {

 @Override
 public ProcessResult broadcast(TaskContext context) {
 log.info("清理本地缓存");
 localCache.clear();
 return new ProcessResult(true);
 }
}

典型场景：每台机器本地缓存清理、每台机器配置刷新。

3. MapProcessor（分片，多 Worker 并行执行）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


@Component
public class BatchInsertJob implements MapProcessor {

 @Override
 public ProcessResult process(TaskContext context) {
 // 当前分片参数
 int subTaskId = (int) Thread.currentThread().getId();
 int totalSubTask = context.getControlPoint(); // 总分片数

 // 假设有 100 万条数据要处理
 int pageSize = 10000;
 int totalPage = 100;
 int startPage = subTaskId * (totalPage / totalSubTask);
 int endPage = (subTaskId + 1) * (totalPage / totalSubTask);

 for (int p = startPage; p < endPage; p++) {
 List<User> users = userDao.findByPage(p, pageSize);
 // 批量处理
 }

 return new ProcessResult(true, "处理 " + (endPage - startPage) + " 页");
 }
}

典型场景：百万级数据批量同步、并行处理。

4. MapReduceProcessor（分片 + 汇总）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


@Component
public class StatisticsJob implements MapReduceProcessor {

 // 1. Map 阶段：每台 Worker 算自己分区
 @Override
 public ProcessResult process(TaskContext context) {
 List<Order> orders = orderDao.findByDateRange(...);
 long totalAmount = orders.stream().mapToLong(Order::getAmount).sum();
 return new ProcessResult(true, String.valueOf(totalAmount));
 }

 // 2. Reduce 阶段：汇总所有 Worker 结果
 @Override
 public ProcessResult reduce(TaskContext context, List<TaskResult> taskResults) {
 long total = 0;
 for (TaskResult r : taskResults) {
 total += Long.parseLong(r.getResult());
 }
 log.info("总销售额: {}", total);
 return new ProcessResult(true, "Total: " + total);
 }
}

典型场景：分布式统计、跨节点数据汇总。

6 种时间表达式

PowerJob 支持 6 种 cron-like 触发方式：

类型	配置	例子
Cron	`0 0 2 * * ?`	每天凌晨 2 点
固定频率	`60000`	每 60 秒（毫秒）
固定延迟	`3000`	上次执行完后等 3 秒
API 触发	手动	运维控制台点击"执行一次"
工作流	DAG 编排	任务 A 完成后触发 B
OpenAPI	HTTP 触发	通过 API 远程触发

Cron 例子

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 每天凌晨 2 点
time_expression: "0 0 2 * * ?"

# 每周一上午 9 点
time_expression: "0 0 9 ? * 2"

# 每 5 分钟
time_expression: "0 */5 * * * ?"

# 每月 1 号零点
time_expression: "0 0 0 1 * ?"

Workflow（DAG 工作流）

PowerJob 相对 XXL-Job 的最大优势——可视化 DAG 编排。

1. 在控制台创建工作流

1
2
3


[开始] → [拉取数据] → [清洗] → [转换] → [入库] → [结束]
 ↓
 [推送通知]

2. 工作流节点配置

每个节点对应一个 Processor，可设置：

失败重试次数：0 / 1 / 3
跳过条件：前置任务 X 失败时跳过
并发度：1 / 5 / 10

3. 实战场景

1
2
3
4
5
6


订单超时关闭工作流：
1. 扫描超时订单（每 5 分钟）
2. 关闭订单
3. 释放库存
4. 退款
5. 发送通知

故障转移与容错

1. 任务超时

1
2
3
4
5


powerjob:
 worker:
 task-retry-num: 3 # 失败重试 3 次
 instance-retry-num: 0 # 实例不重试
 instance-time-limit: 0 # 0 = 不限时

2. 节点宕机

Worker 节点宕机后，Server 自动将任务重新派发到其他 Worker，无需人工介入。

3. 集群高可用

Server 3 节点集群 + MySQL 持久化：

1
2
3
4
5
6
7
8


# node-1
- PARAMS=--spring.profiles.active=product --oms.http.port=10010 --server.address=10.0.0.1

# node-2
- PARAMS=--spring.profiles.active=product --oms.http.port=10010 --server.address=10.0.0.2

# node-3
- PARAMS=--spring.profiles.active=product --oms.http.port=10010 --server.address=10.0.0.3

3 节点通过 Akka 集群 选举 Leader（类似 ZK 选举），Leader 宕机 30s 内自动切换。

4. 报警

控制台支持配置告警：

邮件（spring.mail.*）
钉钉（Webhook）
企业微信（Webhook）
Webhook 自定义

与 XXL-Job 对比

维度	XXL-Job	PowerJob
UI	经典、简洁	现代 + 暗色主题 + DAG
任务类型	4 类（Bean / GLUE / Shell / Python）	4 类（Basic / Broadcast / Map / MapReduce）
工作流	简单父子依赖	DAG 可视化编排
容器支持	一般	K8s 友好（自带 Operator 计划中）
多语言	Java only	Java + Python + Shell + HTTP
集群	集群分片	Akka 集群 + 故障自动转移
上手难度	简单	中等

选型建议：

简单 CRON 任务：XXL-Job（轻量、上手快）
复杂业务编排：PowerJob（DAG 工作流、MapReduce）

实战坑

1. Worker 启动失败：应用未注册

1

ERROR: app not registered

解决：先在 Server 控制台 → 应用管理 → 注册应用 → app-name 必须与 powerjob.worker.app-name 一致。

2. 时区问题

1
2
3
4


# 容器必须设置时区
environment:
 - TZ=Asia/Shanghai
 - JAVA_OPTS=-Duser.timezone=Asia/Shanghai

否则 Cron 任务触发时间会差 8 小时。

3. 大量任务调度延迟

1
2


Server 默认单节点：1000 QPS 调度能力
3 节点集群：3000 QPS

如果任务量 > 10万/天，建议 Server 集群 + Worker 多实例。

4. 任务执行时间超过间隔

1

固定频率 60s 任务，但任务本身耗时 80s

PowerJob 默认跳过当前任务，等下个周期。如果需要"执行完再等 60s"，改用 fixed_delay 类型。

前置知识与下一步

前置：

Spring Boot 基础
Docker 基础
Cron 表达式

下一步：

用 Workflow 编排复杂业务（订单超时关闭流程）
集成告警到企业 IM（钉钉 / 企微）
监控：Prometheus + Grafana 抓取 PowerJob 指标

小结

PowerJob 是国产分布式任务调度的新一代标杆，核心优势：

DAG 工作流（可视化编排）—— 复杂业务一图胜千言
Map / MapReduce —— 大数据量场景天然支持
多语言 Worker（Java + Python + Shell + HTTP）—— 异构系统集成友好
故障自动转移 + Akka 集群 —— 生产可用性高

如果你的项目有 10+ 定时任务 + 复杂依赖关系，XXL-Job 已经不够用，建议直接上 PowerJob。

2024+ 视角：PowerJob V5 + K8s 适配 + AI 运维

PowerJob V5（2024-12 GA）关键变化

V5 全面拥抱 K8s：内置 K8s Operator 风格的 PowerJobWorker CRD
Akka 升级：Akka 2.6 → Pekko 1.0（Apache 顶级项目，Akka 改 License 后社区 fork）
存储后端可插拔：H2 / MySQL / PostgreSQL / 达梦 / 人大金仓，V5 起把"存储"从核心解耦
多租户：单个 Server 集群可承载多业务方，namespace 隔离
工作流 2.0：DAG 节点支持循环 + 条件分支 + 子工作流

K8s 部署的 2024+ 范式

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51


# powerjob-server.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
 name: powerjob-server
spec:
 replicas: 3
 selector:
 matchLabels:
 app: powerjob-server
 template:
 metadata:
 labels:
 app: powerjob-server
 spec:
 containers:
 - name: server
 image: powerjob/powerjob-server:V5.0.0
 ports:
 - containerPort: 7700
 - containerPort: 10010
 env:
 - name: PARAMS
 value: "--spring.profiles.active=product
 --spring.datasource.core.jdbc-url=jdbc:mysql://mysql:3306/powerjob
 --spring.datasource.core.username=powerjob
 --spring.datasource.core.password=${DB_PASSWORD}
 --oms.http.port=10010"
 - name: TZ
 value: Asia/Shanghai
 resources:
 requests:
 memory: "2Gi"
 cpu: "1000m"
 limits:
 memory: "4Gi"
 cpu: "2000m"
---
apiVersion: v1
kind: Service
metadata:
 name: powerjob-server
spec:
 type: ClusterIP
 selector:
 app: powerjob-server
 ports:
 - name: http
 port: 7700
 - name: oms
 port: 10010

Worker 集成 2024+ 升级

1
2
3
4
5


<dependency>
 <groupId>tech.powerjob</groupId>
 <artifactId>powerjob-worker-spring-boot-starter</artifactId>
 <version>5.0.0</version>
</dependency>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


powerjob:
 worker:
 enabled: true
 port: 9988
 app-name: my-application
 server-address: powerjob-server:7700
 protocol: http
 # V5 新增
 max-result-length: 8192
 store-strategy: disk
 # 健康检查
 health-check-interval: 30
 # 标签（V5 多租户）
 tag: production
 namespace: tenant-a

V5 工作流 2.0 实战

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


# 订单超时关闭工作流（V5 新增循环节点）
nodes:
 - id: scan_orders
 type: Basic
 processor: scanTimeoutOrders

 - id: close_order
 type: Basic
 processor: closeOrder
 dependsOn: [scan_orders]

 - id: release_stock
 type: Basic
 processor: releaseStock
 dependsOn: [close_order]

 - id: refund
 type: Basic
 processor: refundOrder
 dependsOn: [release_stock]

 - id: notify_user
 type: Basic
 processor: sendNotification
 dependsOn: [refund]
 # V5 新增：失败重试 + 告警
 retryCount: 3
 alertEnabled: true
 alertChannels: [dingtalk, feishu]

2024+ 监控与告警

PowerJob V5 内置 Prometheus metrics 端点：

1
2
3
4
5
6
7
8
9


# application.yml（Server）
management:
 endpoints:
 web:
 exposure:
 include: health,info,prometheus
 metrics:
 tags:
 application: powerjob-server

Grafana Dashboard：

任务执行 P50 / P95 / P99 延迟
Worker 在线数 / 任务队列长度
DAG 节点完成率

2024+ 选型对比

任务调度	2024+ 适用
XXL-Job	简单 CRON 任务（< 50 个）
PowerJob V5	中大型项目 + DAG 工作流
Apache DolphinScheduler	大数据 ETL（Spark / Flink 集成）
Temporal	复杂长事务（> 1 天的 saga）
Airflow	Python 生态（数据科学）
Argo Workflows	K8s 原生 DAG（容器级任务）

2024+ 实战坑

Akka License 变化：Akka 2.7+ 改 BSL 协议（商业收费），PowerJob V5 改用 Apache Pekko——老项目升级要清 classpath
V5 默认存储改为外置：不再内置 H2 内存模式，必须配 MySQL/PG
多租户 namespace 隔离：V5 起 Worker 必须带 namespace 配置，否则启动失败
K8s 部署：Server 至少 2 副本（防止单点脑裂），但不要超过 5 副本（Akka 集群规模 5 最佳）

PowerJob V5 推荐组合

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


中型互联网业务（Java + Python 异构）
├── PowerJob Server V5 × 3 副本（K8s Deployment）
├── MySQL 8.4 LTS 存储（StatefulSet + 持久卷）
├── PowerJob Worker × N 副本（与应用一起跑）
│ ├── Java 微服务 Worker
│ ├── Python 数据同步 Worker（HTTP 类型）
│ └── Shell 清理任务 Worker
├── DAG 工作流编排业务（订单 / 报表 / 同步）
├── Prometheus + Grafana 监控
└── 告警：钉钉 + 飞书 + 企业微信