不开篇铺垫了,直接说结论:如果你的项目里已经上了 Spring Boot,又需要定时任务、分布式调度、重试补偿、分片处理这类能力,XXL-JOB 几乎是当前中小团队性价比最高的选择,没有之一。我最早是自己用 Quartz 硬写调度中心,后来切到 XXL-JOB,维护成本肉眼可见地降了一截。这篇文章不会只给你贴配置,而是把调度链路里真正值得花时间理解的东西拆开讲:执行器注册、任务分片的底层逻辑、高可用部署形态、报表数据怎么沉淀,以及我实际踩过的一些坑。

1. 分布式调度场景下,为什么最终选了 XXL-JOB

1.1 自研调度 vs 直接选型,最关键的一个判断点

先聊一个很现实的问题:定时任务谁都会写,@Scheduled 注解一加,一个方法就定时跑了。但系统一旦拆成多个服务、多个实例,问题立刻变复杂:

• 同一个任务在多个实例上会重复执行,需要分布式锁;
• 任务执行超时、失败后谁来重试、怎么补偿;
• 任务之间如果有依赖关系,怎么编排;
• 任务跑完的结果、耗时、状态,怎么统一查看和跟踪;
• 某个任务负载高了,能不能按照业务维度拆成多片并行处理。

我见过不少团队一开始用 @Scheduled 加 Redis 锁对付这些问题,前期确实够用,但一旦业务任务量超过几十个,你会发现自己其实在重复造一个调度平台的轮子。而 XXL-JOB 本身就是一个轻量级的分布式任务调度平台,有可视化后台、有执行器管理、有失败告警、有路由策略,直接省掉自研那一大坨。

1.2 从整体架构看清楚 XXL-JOB 在系统中的位置

我曾经画过一张很粗糙的架构图给团队新人讲,先口述给你,你脑子里有个框架就行:

• 调度中心(admin):独立部署的 Web 应用,负责任务管理、调度触发、日志查看、执行器注册管理。
• 执行器(executor):嵌入在业务服务里的一个组件,通常每个 Spring Boot 服务启动时自动注册到调度中心。
• 任务发起后,调度中心把任务分发到某个执行器,执行器执行对应的 JobHandler,再把执行日志回传到调度中心。

这套模型里,调度中心和执行器是解耦的,一个任务跑在哪个服务上完全由执行器的注册情况和路由策略决定。这也是 XXL-JOB 跟 Quartz 单机任务调度最大的差别:Quartz 的调度逻辑在业务服务内部,而 XXL-JOB 把“调度”这个行为独立出去了。

我见过一些新人在这里容易绕晕:以为必须把调度中心也整合进 Spring Boot 项目里。其实不是,admin 是独立跑的,你的 Spring Boot 服务只需要引入 executor 相关依赖,启动时注册过去就行。这个认知一旦建立,后面的部署就顺了。

注意:把调度中心做成独立服务,不是架构洁癖。调度的稳定性直接决定所有定时业务的稳定性,它需要独立的资源、独立的日志、独立的扩缩容策略,混在业务应用里一旦业务服务被流量打满,定时任务也会跟着遭殃。

1.3 什么时候不建议用 XXL-JOB

选型不是只看优点,也说说反例。如果你符合下面任意一条,我劝你先别急着上:

• 整个系统就三五个定时任务,且没有多实例部署的需求;
• 团队完全没有独立部署运维一个中心化服务的经验;
• 业务场景对任务调度时延要求极其苛刻,毫秒级触发且触发频率极高,这种其实更该考虑内嵌调度器+消息队列的思路。

XXL-JOB 的调度模型是“中心化调度 + 执行器回执”,单次任务触发存在毫秒级的网络开销和调度成本。对普通业务(分钟级、小时级、天级任务)完全无感,但对那种每秒就要触发几万次的任务,它并不是一个好选择。

2. 调度内核拆解:执行器注册、任务触发与任务分片的底层逻辑

2.1 执行器是怎么“被找到”的

XXL-JOB 里,执行器是以 AppName 为单位注册到调度中心的。你在调度中心新增执行器时填一个 AppName(比如 xxl-job-executor-order),业务服务里配置的 appname 和它一致,启动时调度中心就能看到这个执行器,并拿到它对应的地址列表。

这里面有个容易忽略的细节:执行器上报地址有两种方式。一种是自动注册,也就是执行器启动时把自己的 IP:Port 发给调度中心;另一种是手动录入,你在后台直接填地址。自动注册适合动态扩缩容的云环境(比如 K8s 下 Pod 重建后 IP 会变),手动录入适合内网固定 IP 的传统部署。

我实际的经验是,自动注册省心,但在 K8s 环境里有个坑:Pod 里拿到的网段往往是容器网段,调度中心如果跨网段调不通,会出现“执行器显示在线,但任务一直调度失败”。后来排查才发现是注册的 IP 是 Pod IP,调度中心所在的节点访问不了这个地址。解决方案通常两种:一是把执行器注册配置里的 IP 手动指定为节点 IP,二是在 xxl-job 的 xxl.job.executor.ip 配置项里强制指定宿主机 IP。

2.2 从 JobInfo 到一次完整调度,链路里发生了什么

很多人用 XXL-JOB 只知道填一个 Cron 表达式,然后写个方法,完事。但对排查问题来说,搞清楚任务下发链路非常重要。

一次调度大概是这样的:

1. 调度中心根据任务的 Cron 和触发规则,在调度时间到达时生成一个触发请求;
2. 调度中心根据任务配置的路由策略,从已注册的 executor 地址里选一个(或广播全部);
3. 调度中心把触发请求发送给执行器;
4. 执行器收到请求后,从线程池里取一个线程执行对应的 JobHandler;
5. 执行完成后,执行器把执行结果、日志、耗时回传给调度中心,调度中心落库并展示。

这个链路里最核心的一个概念是:调度中心和执行器之间不是长连接维持任务状态,而是每次触发都走一次完整的请求-响应。所以调度中心重启,不会影响已经下发给执行器的任务;但如果任务已经在执行器上跑了一半,调度中心重启了,任务是继续跑的,只是在调度中心侧短暂看不到它,等执行器回传结果时才恢复记录。

我在生产环境遇到过调度中心发布时,刚好压在一个跑了 40 分钟的大任务上,调度中心的日志显示这个任务“执行中”的状态丢了,但执行器端其实还在跑。后来我养成了一个习惯:所有长任务在执行器端自己记录开始、结束和关键进度日志,不要把状态展示完全依赖调度中心。

2.3 任务分片的本质:把一份数据拆成 N 份,并行处理

任务分片是 XXL-JOB 里业务价值最高的能力,也是很多人没真正理解的能力。给你一个最常见的场景:有一张 5000 万行的用户表,每天凌晨需要给所有用户推送一份账单。单机跑,可能跑两个小时;集群有三台机器,如果只让一台跑,另外两台闲着,亏不亏?

分片广播的作用就是,让所有执行器同时收到同一个任务,但每个执行器拿到的分片参数不同。XXL-JOB 会给每个执行器传入两个参数:shardIndex(当前分片序号)和 shardTotal(总分片数)。比如你有 3 台执行器,那它们拿到的参数分别是:

• 实例 A:shardIndex=0, shardTotal=3;
• 实例 B:shardIndex=1, shardTotal=3;
• 实例 C:shardIndex=2, shardTotal=3;

然后你在代码里把任务的数据范围按分片序号切分。最常用的做法是按主键取模:

java复制// 假设 taskId 是用户 ID
if (userId % shardTotal == shardIndex) {
    // 处理这个用户
}

有的团队会用范围切分,比如 A 处理 1~1000 号用户,B 处理 1001~2000 号,但按 ID 取模的方式对数据分布最均匀,而且执行器扩缩容后,只需要改 shardTotal,不需要改数据划分规则。

分片广播不是免费午餐,它的前提是任务本身可以被拆分。如果你的任务是一个不可拆分的整体(比如生成一个全局的汇总报表),那分片广播就不适用,这时候更适合用故障转移或者轮询路由,让其中一台执行器跑整体任务。

实操建议:设计分片任务时,尽量让每个分片之间数据不依赖、结果不共享。如果分片处理完需要把结果汇总,可以考虑每个分片写结果表时带上分片标识,最后再做一次汇总调度。

2.4 路由策略怎么选,决定了任务跑在哪台机器上

XXL-JOB 内置了挺多路由策略:第一个、最后一个、轮询、随机、一致性哈希、故障转移、忙碌转移、分片广播等。

这块我不逐个介绍,只给你我实际验证过的选型逻辑:

• 普通短任务、无状态任务:选轮询或随机,让执行器负载尽量均衡;
• 需要固定实例执行的任务:选一致性哈希,保证同一个任务 ID 总落在同一台机器上,便于利用本地缓存;
• 重要且可重试的任务:选故障转移,一台失败自动切换到另一台;
• 执行器负载敏感的任务:选忙碌转移,执行器线程池忙时自动换一台。

分片广播是个例外,它不是“选择一台”,而是“发给所有”。所以它不跟前几种策略放在一起对比,属于不同维度的配置。

3. Spring Boot 集成 XXL-JOB 的完整落地过程

3.1 依赖引入与基础配置

用 Maven 引入依赖:

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

版本这里多说一句,xxl-job-core 的版本最好和调度中心的版本保持一致,不然可能出现字段序列化不兼容这类奇怪问题。我吃过这个亏:执行器用的 2.3.0,调度中心升到了 2.4.0,任务偶尔报反序列化异常,排查了好久才发现是版本不一致。

然后是 application.yml 配置:

yaml复制xxl:
  job:
    admin:
      addresses: http://xxl-job-admin:8080/xxl-job-admin
    accessToken: your-token
    executor:
      appname: xxl-job-executor-order
      address:
      ip:
      port: 9999
      logpath: /data/applogs/xxl-job/jobhandler
      logretentiondays: 30

这里几个配置项各自的含义:

• admin.addresses:调度中心地址,多个用逗号分隔;
• accessToken:调度中心和执行器之间的通信令牌,不配也能通,但生产环境一定要配,不然任何知道地址的人都能往你执行器上提交任务;
• executor.appname:执行器名称,需要和调度中心后台添加的执行器 AppName 保持一致;
• executor.ip:这个可以留空,默认自动探测。但前面说过,多网卡或容器环境下容易探错,建议有条件就直接手动指定;
• executor.port:执行器自己暴露给调度中心的通信端口,注意别和业务端口混了,一个端口只服务一个执行器;
• logpath:执行器日志的本地保存路径;
• logretentiondays:日志本地保留天数。

3.2 XxlJobConfig 配置类

接下来需要一个配置类,把 XxlJobExecutor 注册成 Spring Bean:

java复制@Configuration
public class XxlJobConfig {

    @Value("${xxl.job.admin.addresses}")
    private String adminAddresses;

    @Value("${xxl.job.accessToken}")
    private String accessToken;

    @Value("${xxl.job.executor.appname}")
    private String appname;

    @Value("${xxl.job.executor.ip}")
    private String ip;

    @Value("${xxl.job.executor.port}")
    private int port;

    @Bean
    public XxlJobSpringExecutor xxlJobExecutor() {
        XxlJobSpringExecutor xxlJobSpringExecutor = new XxlJobSpringExecutor();
        xxlJobSpringExecutor.setAdminAddresses(adminAddresses);
        xxlJobSpringExecutor.setAppname(appname);
        xxlJobSpringExecutor.setIp(ip);
        xxlJobSpringExecutor.setPort(port);
        xxlJobSpringExecutor.setAccessToken(accessToken);
        return xxlJobSpringExecutor;
    }
}

从 2.4.0 开始,XxlJobSpringExecutor 会自动扫描 Spring 容器中带有 @XxlJob 注解的方法并注册为 JobHandler,所以不需要手动一个个 add 了。这个设计很实用,像 Spring Boot 里写普通 Bean 一样,整体集成成本很低。

注意:如果你的服务里有多个数据源或特殊的事务配置,建议确认 XxlJobSpringExecutor 的初始化顺序,别让它在 Spring 容器还没准备完时就去连调度中心。一般默认初始化顺序就够,但如果你遇到“启动时执行器注册失败但服务起来了”的情况,可以看看是不是某个 Bean 初始化阻塞导致的。

3.3 写一个简单的 JobHandler

java复制@Component
public class SampleJobHandler {

    @XxlJob("demoJobHandler")
    public void demoJobHandler() throws Exception {
        XxlJobHelper.log("demo job start, param: {}", XxlJobHelper.getJobParam());
        // 业务逻辑
        XxlJobHelper.log("demo job finished");
    }
}

@XxlJob 注解里的名字就是 JobHandler 的名称,在调度中心配置任务时,JobHandler 填这一串名字就能对上了。注意一点:这个名字全局唯一,重复的话后面注册的会顶掉前面的,而且启动时都不报错,排查起来非常隐蔽。

XxlJobHelper 是执行器侧封装的操作类,常用几个方法:

• getJobParam():获取调度中心配置的任务参数;
• log(...):打印调度日志,会同步到调度中心的日志面板;
• getShardIndex() / getShardTotal():获取当前分片序号和总分片数;
• handleSuccess() / handleFail():手动标记任务成功或失败。

3.4 更多细节:glue 模式的适用场景

XXL-JOB 支持两种代码模式:一种是上面这种 Bean 模式,代码在业务服务里,跟着服务发布走;另一种是 Glue 模式,代码直接维护在调度中心,可以动态发布,不用重新部署执行器。

Glue 模式最爽的地方在于,紧急修一个线上脚本逻辑、或者临时改一个任务逻辑时,直接在调度中心改代码、点发布,实时生效,不用等业务服务发版。我有次凌晨接了个临时数据修复需求,如果走服务发版流程,光审批加流水线要一两个小时,用 Glue 模式五分钟就改完了。

但 Glue 模式也有硬伤:代码散落在调度中心,版本管理不方便,没法走团队平时的 Code Review 和 CI 流程;而且它强依赖调度中心可用性。所以我给团队定的规矩是:长期稳定跑的核心业务任务一律用 Bean 模式,临时脚本、偶尔调整逻辑的数据修复类任务才允许用 Glue 模式。

4. 高可用部署形态与监控报表的搭建思路

4.1 调度中心的高可用:数据库是最大的单点

XXL-JOB 的调度中心本身可以集群部署,多台 admin 实例通过共同的数据库协调状态。部署层面比较简单:前面挂负载均衡,后面挂两个或更多 admin 实例,共用同一个数据库。调度中心节点之间没有复杂的内部通信,所以扩展能力很强。

但这里有一个最常见的“伪高可用”误区:很多人以为把 admin 部署成多台就高可用了,却忽略了数据库还是单点。XXL-JOB 的调度数据全部存在数据库里,一旦数据库挂了,调度中心界面还能打开,但调度任务基本全部瘫痪。所以你要真想做到高可用,数据库这一层必须有主备或集群方案。MySQL 的主从 + MHA,或者直接用云数据库的高可用版,再或者你已经在用 PostgreSQL,可以考虑 Patroni 那套。

第二点容易被忽略的是,调度中心的 session 问题。admin 集群部署后,登录态默认存在内存里,负载均衡切到另一台实例就没登录了。解决办法是配置 spring.session.store-type 为 redis 或 jdbc,让多个 admin 实例共享会话。我见过不止一个团队在 admin 集群部署后遇到“一会能登录一会不能登录”的诡异问题,最后发现就是这个 session 没做共享。

4.2 执行器的高可用:注册中心思维比多部署更重要

执行器的高可用其实不用额外做太多事。XXL-JOB 的执行器天然支持多实例注册:同一个 AppName 下起多个服务实例,它们在调度中心显示为多个地址,路由策略和分片广播都会基于全部实例来做。

所以在 Spring Boot 侧,你只要保证业务服务部署了多个实例,并且它们都能把执行器注册上,就已经具备高可用了。一台挂了,调度中心会在下一个调度周期把它摘掉(或者触发时失败转移到别的实例)。这里需要注意的是,如果你用了故障转移、轮询等依赖多实例的路由策略,一定要在调度中心确认执行器地址列表里确实能看到全部实例,只看到一个地址就不要指望高可用。

很多团队在 K8s 环境里把执行器也容器化,注意两件事:

• 容器重启后 IP 会变,所以依赖自动注册,别用手动录入的地址;
• 调度中心访问执行器的网络要通,前面说过的 Pod IP 和节点 IP 的问题,一定提前验证。

4.3 用 Micrometer 和 Actuator 把调度指标暴露出来

监控这件事,很多人会忽略——任务能跑就行,出问题再说。但真正出问题时,你手上没有任何历史指标,排查就全靠猜。

Spring Boot 服务里引入 Actuator 和 Micrometer 后,可以把一些 JVM、线程池、HTTP 调用指标暴露给监控平台。对 XXL-JOB 执行器来说,值得关注的核心指标其实是线程池的状态,因为执行器的任务跑在线程池里,如果线程池被占满,后续任务就会排队甚至超时。

xml复制<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

暴露指标后,你可以用 Prometheus 抓取,再接到 Grafana 看板。执行器本身并没有暴露太多调度维度的指标,所以我自己通常会在 JobHandler 里埋点,把每个任务的执行耗时、成功失败数记到 Micrometer 的 Counter 和 Timer 里:

java复制@XxlJob("payStatJob")
public void payStatJob() {
    Timer.Sample sample = Timer.start(meterRegistry);
    try {
        doPayStat();
        successCounter.increment();
    } catch (Exception e) {
        failCounter.increment();
        XxlJobHelper.handleFail("pay stat job failed: " + e.getMessage());
    } finally {
        sample.stop(taskDurationTimer);
    }
}

这套埋点方案看起来简单,但真正救过我一次:任务调度中心显示执行成功,但业务数据一直不对。后来看 Grafana 上的任务耗时曲线,发现任务每天耗时都在涨,涨到接近超时阈值时处理不完,但任务本身又没有抛异常,调度中心记录的成功其实是“假成功”——代码里把异常吞了,只打了日志。这种情况下任务维度的监控报表就是唯一能快速定位问题的线索。

4.4 调度报表数据怎么沉淀

说到高可用报表,这里多讲一层:报表数据本身是个数据工程问题。XXL-JOB 自带的后台能看日志和调度记录,但只适合人工点开排查,不适合做长期的、多维度的统计分析。

我推荐的做法是,写一个定时任务(很有趣,用 XXL-JOB 来监控 XXL-JOB),定期从调度中心的日志表里抽取数据,整理成任务执行明细表,再沉淀出日维度的汇总报表。

通常关注这几个维度:

• 每天任务执行总数、成功数、失败数、失败率;
• 任务平均耗时、P95 耗时、最大耗时;
• 失败任务 Top N;
• 执行器实例的负载分布,哪个实例承担的任务最多,有没有倾斜。

具体可以制定一张调度任务执行汇总表:

这个表每天凌晨汇总一次,数据量不大(一个任务一天最多一两千条记录),存一年都没压力。报表数据沉淀下来之后,你再去规划执行器扩容、调整任务调度时间、判断哪些任务需要优化,就不再是拍脑袋了。

5. 生产环境里的典型故障与排查方法

5.1 任务一直不触发,但执行器在线

这个现象排查起来其实有清晰路径。先查调度中心的调度日志,看任务调度时间到没到,有没有生成调度记录。如果没有调度记录,多半是 Cron 配置有问题,或者调度中心的调度线程卡住了。如果调度记录有,但执行器没收到,这就基本是网络问题或执行器地址失联。

一个比较容易中招的配置是调度中心所在服务器和执行器所在服务器时钟不一致。Cron 调度依赖系统时间,两边时间差太多会出现调度记录显示触发,但执行器侧看时间是未来的情况。

5.2 任务报错“执行器地址为空”

这里要区分执行器是自动注册还是手动录入。自动注册的话,确认 xxl-job executor 配置里的 appname 和调度中心后台执行器管理里的 AppName 完全一致,包括大小写和特殊字符。手动录入的话,确认地址格式,比如 http://192.168.1.10:9999/ ,端口要写执行器暴露的端口,不是业务端口。

还有一个隐藏问题:调度中心的任务配置里,如果你在任务的“高级配置”里指定了集群的某个地址,但地址已经失效了,就会出现报错。检查任务配置,把机器地址改成正确的或清空重新选择执行器。

5.3 任务执行成功,但业务数据不对

这是最恶心的一个问题,因为调度中心显示全绿,但业务方说数据对不上。

我上面的例子提到了“假成功”这一种情况。还有另外两种常见原因:

• 代码里用了 try-catch,异常只打日志,没调用 XxlJobHelper.handleFail(),任务被标记为成功;
• 任务本身没报错,但逻辑上有 bug,比如分片参数取错、或者并发重复执行导致数据覆盖。

排查技巧是,不要只信调度中心的执行结果,要看执行器日志里任务真正的执行细节。另外,重要任务建议在代码里加上执行结果的校验:处理完数据后查一下结果集条数是否符合预期,不符合就直接 handleFail,让调度中心把这次执行标记为失败。

这看起来是个很小的习惯,但真的能省很多麻烦。任务失败了你第一时间知道,和任务看起来成功但数据有问题你三天后才发现,是完全不同的运维体验。

5.4 任务超时没有告警

XXL-JOB 的“任务超时时间”属性是调度中心侧的判断依据,超时后调度中心会标记为失败并触发告警。但你要理解,超时标记不代表执行器端任务被终止了——执行器端的任务可能还在继续跑。这是因为 XXL-JOB 的调度中心没法远程强杀一个正在执行的任务线程,只能通过中断信号尝试通知,实际的线程终止取决于代码是否响应中断。

所以对于可能长时间运行的任务,我强烈建议在代码内部自己实现超时控制,比如用 Future 加超时时间,或者用状态标记配合循环检查。调度中心的超时配置只是一道外部保险,不是内部的熔断机制。

6. 我在实践里形成的几条经验总结

这一节不写代码,写几个我自己沉淀下来的工作习惯,有点碎,但实用性很强。

第一个经验关于权限管理。生产环境的调度中心一定要把执行器分环境隔离,测试环境的执行器不要注册到生产调度中心,不然鬼知道什么时候一个测试任务就在生产实例上跑起来了。如果团队规模不大,做不到多环境隔离,至少要在 AppName 命名上区分,比如用后缀 -prod、-test 标记。

第二个经验关于任务幂等。凡是涉及数据写入或外部接口调用的任务,执行器端一定要做幂等控制。XXL-JOB 支持的“调度过期策略”里有个选项是“忽略”,如果上一次任务还没跑完,下一次调度时间已经来了,调度中心可以选择忽略这次触发。但在业务代码里,任务可能被手动重跑、被故障转移后重试,这些路径都不受调度中心策略控制,所以在代码里做幂等是最后一道防线。

第三个经验关于日志。任务日志不要只靠 System.out 和 XxlJobHelper.log,建议在关键节点把参数、结果、耗时埋进结构化日志。一个任务跑挂了,你打开日志能看到完整的上下文,而不是一行孤零零的异常堆栈,排查效率完全不一样。

第四个经验关于容量规划。每台执行器默认的线程池大小是 200 多,但对一个服务来说不是越大越好。你得想清楚这台服务最多同时能接受多少个调度任务。如果一个服务既承担着线上接口流量,又跑着大量定时任务,调度任务的大量线程会挤占业务线程资源,导致接口响应变慢。我的做法是给执行器线程池设置一个合理的上限,同时在任务侧尽量避免大任务和短任务共用一台执行器。

7. 结个尾,顺便说点大实话

XXL-JOB 是一个很容易上手、但很难“用好”的中间件。所谓用好,不是把任务跑起来就完了,而是把调度链路、分片特性、高可用边界都摸清楚之后,能为你的业务提供稳定可靠的调度能力。

我最想强调的一个观点是:任何分布式调度平台都只是工具,它解决的是“任务怎么分发、怎么执行、怎么保证不丢”的问题,但你的任务本身写得是否健壮、是否幂等、是否可以分片、是否可以重试,这才是决定整套系统稳定性的核心要素。

我见过太多团队把任务跑挂了,第一反应是怀疑 XXL-JOB 有问题,结果查到最后几乎都是业务代码自己写的坑。所以我的排错顺序一般是这样:先看执行器日志确认业务执行情况,再看调度记录确认分发情况,最后才去怀疑框架本身。你按照这个顺序排查,大概率能比同事快一步找到问题根源。

最后再分享一个小技巧:新接入 XXL-JOB 的团队,不要一上来就追求把所有任务往平台迁移,先挑两三个非核心、但适合分片或故障转移的任务试运行,跑一两周,把调度中心、执行器、日志、告警这条链路彻底跑熟了,再批量迁移。这个循序渐进的节奏,我实践下来是最稳的。