1. 项目概述为什么XXL-Job必须集群化而不是单点跑着凑合XXL-Job不是那种装完就能扔角落里自动运转的“傻瓜调度器”。我最早在2019年接手一个电商订单对账系统时就吃过单节点的亏——凌晨三点调度中心突然OOM挂掉37个定时任务全部中断财务侧第二天一早发现昨日对账数据全断档技术团队被拉进跨部门复盘会坐了四个小时。从那以后但凡涉及核心业务的定时任务比如库存同步、风控规则刷新、用户行为归因计算我坚持一条铁律XXL-Job调度中心不集群等于没上线。所谓“集群部署和高可用”本质是解决三个刚性问题单点故障不可接受、并发调度能力有瓶颈、配置与状态必须全局一致。很多人误以为只要把调度中心多起几个实例就算集群了结果发现任务重复触发、路由策略失效、执行器注册混乱——这恰恰暴露了对XXL-Job集群机制的误解。它不是无状态服务而是强依赖中心化注册中心分布式锁一致性配置分发的三重保障体系。你看到的“高可用”背后是ZooKeeper或Redis做服务发现、MySQL主从读写分离扛住调度元数据压力、Quartz集群模式协调触发时机、以及执行器端心跳保活与故障剔除的完整闭环。这个实战指南就是把我过去三年在金融、物流、SaaS三条业务线落地XXL-Job集群踩过的所有坑、调过的所有参数、验证过的每一种拓扑结构掰开揉碎讲清楚。不讲概念只说“为什么这里必须用ZK而不是Eureka”、“为什么MySQL binlog延迟会导致任务漏触发”、“为什么执行器注册超时阈值设成30秒反而比60秒更稳”。适合正在规划生产环境部署的架构师、被线上调度异常折磨的运维同学以及想真正搞懂XXL-Job底层逻辑的开发同学。如果你还在用单机版跑核心任务或者刚配好双节点却发现任务乱跳——这篇就是为你写的。2. 集群架构设计与核心组件选型逻辑2.1 调度中心集群不是“多起几个进程”而是四层协同的精密系统XXL-Job调度中心集群绝非简单地启动多个xxl-job-admin实例。它的高可用实现是调度中心、注册中心、存储中心、执行器四者深度耦合的结果。任何一层选型失误都会导致整个集群“形似神散”。调度中心层XXL-Job Admin负责任务触发、路由分发、日志收集、UI管理。集群中每个实例都是有状态的——它们共享同一套MySQL元数据但各自维护本地Quartz调度器、本地任务执行线程池、本地缓存如执行器地址缓存。关键在于所有实例必须连接同一个MySQL库且必须启用Quartz的JDBCJobStore集群模式。否则会出现任务被多个实例重复触发的灾难性问题。注册中心层服务发现这是集群的“神经中枢”。XXL-Job官方支持ZooKeeper、Redis、Etcd三种。我们实测下来ZooKeeper是唯一能稳定支撑生产级高可用的选项。原因很实在Redis作为注册中心时执行器心跳续租依赖SET key value EX seconds NX一旦Redis主从切换期间出现短暂脑裂执行器可能同时向新旧两个调度中心注册导致任务路由错乱而ZooKeeper的ZAB协议保证了强一致性临时节点ephemeral node的创建与销毁严格有序执行器下线感知延迟稳定在3秒内ZK session timeout默认30秒但我们调优到15秒。存储中心层MySQL所有任务定义、触发日志、执行器注册信息都存在这里。单点MySQL是最大单点风险。我们采用MySQL 8.0 MGRGroup Replication集群而非传统主从。MGR的多写特性让任意节点都可读写避免了主库宕机后手动切换VIP的运维黑洞。更重要的是MGR内置的流控机制flow control能自动抑制慢节点防止binlog复制延迟拖垮整个调度链路——这点在大数据量任务日志写入时尤为关键。执行器层XXL-Job Executor这是常被忽视的“哑终端”。执行器本身不集群但必须支持多实例注册负载均衡路由。每个执行器实例启动时向注册中心注册自己的IPPORTAppName并定期发送心跳。调度中心从注册中心拉取该AppName下的所有存活实例列表按配置的路由策略轮询、LRU、一致性哈希等分发任务。注意执行器实例数必须≥2且部署在不同物理机/可用区否则无法规避单机故障。提示不要试图用Nginx反向代理调度中心UI来实现“负载均衡”。XXL-Job Admin的UI请求如任务操作、日志查看必须路由到同一实例因为部分操作依赖本地缓存如执行器地址缓存。正确的做法是UI入口走DNS轮询或VIP后台API调用由执行器直连注册中心获取调度中心地址列表自行选择。2.2 为什么放弃Eureka/NacosZooKeeper的不可替代性在哪网络上很多教程推荐用Nacos或Eureka做注册中心理由是“Spring Cloud全家桶更统一”。但我们在线上压测中发现当执行器规模超过200个时Nacos的健康检查接口/nacos/v1/ns/instance/status响应延迟飙升至2秒以上导致调度中心拉取执行器列表超时进而触发默认路由策略第一个注册的实例造成流量倾斜。Eureka的问题更隐蔽其自我保护模式在大规模实例注册时会主动关闭剔除下线节点的功能导致“僵尸执行器”长期滞留注册表任务持续被派发到已宕机的机器。ZooKeeper则完全不同。它的设计哲学是“宁可拒绝服务也不提供错误数据”。我们用zkCli.sh直接测试# 模拟执行器注册创建临时节点 create -e /xxl-job/executor/demo-executor/10.10.1.100:9999 # 查看所有注册节点毫秒级响应 ls /xxl-job/executor/demo-executor # 删除节点立即生效 delete /xxl-job/executor/demo-executor/10.10.1.100:9999ZooKeeper的ZNode操作是原子的且watch机制让调度中心能实时感知变更。我们甚至用echo stat | nc localhost 2181监控ZK连接数发现200个执行器注册时ZK客户端连接数稳定在200左右无抖动。这种确定性是AP型注册中心Nacos/Eureka无法提供的。2.3 MySQL MGR集群 vs 主从复制一次数据库选型的血泪教训最初我们用MySQL 5.7主从复制主库写从库读调度中心配置spring.datasource.urljdbc:mysql://master,slave1,slave2/xxl_job?loadBalancetrue。上线两周后某次主库计划维护手动切换VIP结果因从库binlog延迟12秒导致任务触发记录写入主库但调度中心从从库读取执行器列表时拿到的是旧数据任务被派发到已下线的执行器返回Connection refused。更糟的是XXL-Job的失败重试机制将该任务标记为“失败”但实际执行器根本没收到请求——日志里查不到任何痕迹。换成MySQL 8.0 MGR后问题彻底解决。MGR的组通信协议XCom确保所有节点数据强一致。我们配置了3节点MGR集群1主2备并通过SELECT MEMBER_STATE, MEMBER_ROLE FROM performance_schema.replication_group_members;实时监控状态。当主节点宕机MGR在8秒内自动选举新主我们调优过group_replication_member_expel_timeout0所有调度中心实例无缝切换任务触发零丢失。关键参数如下-- MGR初始化配置my.cnf [mysqld] plugin_load_addgroup_replication.so transaction_write_set_extractionXXHASH64 group_replication_group_nameaaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa group_replication_start_on_bootoff group_replication_local_address10.10.1.101:33061 group_replication_group_seeds10.10.1.101:33061,10.10.1.102:33061,10.10.1.103:33061 group_replication_bootstrap_groupoff -- 启动后执行 CHANGE MASTER TO MASTER_USERrepl, MASTER_PASSWORDrepl FOR CHANNEL group_replication_recovery; START GROUP_REPLICATION;3. 核心组件部署与关键参数调优详解3.1 ZooKeeper集群部署从3节点到5节点的演进路径ZooKeeper集群节点数必须是奇数3/5/7这是Paxos协议的硬性要求。我们最初用3节点ZK但在一次网络分区事件中机房交换机故障2个节点失联剩余1个节点因无法获得多数派quorum投票而自动停止服务导致整个XXL-Job集群不可用。后来升级到5节点即使2个节点宕机剩余3个仍能组成多数派服务持续可用。部署要点硬件隔离5个ZK节点必须部署在不同物理机、不同机柜、不同供电线路。我们曾把3个ZK放在同一台4U服务器的3个VM里结果宿主机硬盘故障3个ZK同时挂掉。磁盘IO优化ZooKeeper的事务日志/dataLogDir必须单独挂载SSD且禁用atime更新# /etc/fstab /dev/sdb1 /var/lib/zookeeper/log xfs defaults,noatime 0 0JVM参数ZK对GC极其敏感必须用G1GC并限制堆内存# zoo.cfg JVMFLAGS-Xms2g -Xmx2g -XX:UseG1GC -XX:MaxGCPauseMillis200ZooKeeper关键配置zoo.cfg# 基础配置 tickTime2000 initLimit10 syncLimit5 # 数据目录务必分开 dataDir/var/lib/zookeeper/data dataLogDir/var/lib/zookeeper/log # 客户端连接端口 clientPort2181 # 四字命令端口用于监控 admin.serverPort8080 # 集群配置5节点示例 server.110.10.1.101:2888:3888 server.210.10.1.102:2888:3888 server.310.10.1.103:2888:3888 server.410.10.1.104:2888:3888 server.510.10.1.105:2888:3888 # 启用动态重配置重要 dynamicConfigFile/var/lib/zookeeper/conf/zoo.cfg.dynamic每个ZK节点的myid文件内容必须唯一/var/lib/zookeeper/data/myid# 节点1 echo 1 /var/lib/zookeeper/data/myid # 节点2 echo 2 /var/lib/zookeeper/data/myid # ...以此类推注意ZooKeeper的initLimit初始同步时间和syncLimit心跳超时必须根据网络延迟调整。我们机房内网延迟1ms所以设为默认值若跨机房部署initLimit需调大至20即40秒否则节点启动时无法完成初始同步会卡在LOOKING状态。3.2 XXL-Job调度中心集群部署配置文件逐行解析调度中心的application.properties是集群稳定的核心。以下是我们生产环境的完整配置已脱敏重点参数均加注释### xxl-job admin port server.port8080 ### xxl-job admin context-path server.servlet.context-path/xxl-job-admin ### xxl-job db spring.datasource.urljdbc:mysql://10.10.1.101:3306,10.10.1.102:3306,10.10.1.103:3306/xxl_job?useUnicodetruecharacterEncodingUTF-8autoReconnecttruefailOverReadOnlyfalseserverTimezoneAsia/ShanghaiallowMultiQueriestrue spring.datasource.usernameroot spring.datasource.passwordyour_password spring.datasource.driver-class-namecom.mysql.cj.jdbc.Driver # 关键必须开启HikariCP连接池的keepalive防止MySQL空闲连接超时断开 spring.datasource.hikari.connection-timeout30000 spring.datasource.hikari.validation-timeout3000 spring.datasource.hikari.idle-timeout600000 spring.datasource.hikari.max-lifetime1800000 spring.datasource.hikari.keepalive-time30000 ### xxl-job, datasource pool spring.datasource.typecom.zaxxer.hikari.HikariDataSource ### xxl-job, quartz init # 关键必须启用Quartz集群模式否则多实例会重复触发任务 xxl.job.quartz.jdbc.dataSourcexxlJobDataSource xxl.job.quartz.scheduler.instanceNameXXL-JOB-SCHEDULER xxl.job.quartz.scheduler.instanceIdAUTO xxl.job.quartz.threadPool.classorg.quartz.simpl.SimpleThreadPool xxl.job.quartz.threadPool.threadCount20 xxl.job.quartz.threadPool.threadPriority5 xxl.job.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThreadtrue # 关键Quartz集群表前缀必须与XXL-Job保持一致默认QRTZ_ xxl.job.quartz.dataSource.myDS.drivercom.mysql.cj.jdbc.Driver xxl.job.quartz.dataSource.myDS.URLjdbc:mysql://10.10.1.101:3306,10.10.1.102:3306,10.10.1.103:3306/xxl_job?useUnicodetruecharacterEncodingUTF-8autoReconnecttruefailOverReadOnlyfalseserverTimezoneAsia/Shanghai xxl.job.quartz.dataSource.myDS.userroot xxl.job.quartz.dataSource.myDS.passwordyour_password xxl.job.quartz.dataSource.myDS.maxConnections20 xxl.job.quartz.dataSource.myDS.unusedConnectionTimeout300 xxl.job.quartz.dataSource.myDS.checkoutTimeout3000 ### xxl-job, access token xxl.job.accessTokendefault_token ### xxl-job, i18n (default is zh_CN, and you can choose zh_CN, zh_TC and en) xxl.job.i18nzh_CN ### xxl-job, trigger pool size (must be larger than cpu core count) xxl.job.trigger.pool.fast200 xxl.job.trigger.pool.slow100 ### xxl-job, log retention days xxl.job.logretentiondays30 ### xxl-job, registry center (ZooKeeper) # 关键注册中心必须指向ZK集群而非单点 xxl.job.admin.registry.addresszookeeper://10.10.1.101:2181?zkSessionTimeout15000zkConnectionTimeout10000 # 关键调度中心实例名必须全局唯一用于ZK节点标识 xxl.job.admin.appnamexxl-job-admin-prod # 关键调度中心地址供执行器反向调用必须是本机可访问的IPPORT xxl.job.admin.addresshttp://10.10.1.101:8080/xxl-job-admin特别强调三个易错点xxl.job.admin.address必须填写本机真实IP不能写localhost或127.0.0.1。执行器通过此地址回调调度中心若填错执行器日志会报Connection refused。xxl.job.admin.registry.address中的zkSessionTimeout1500015秒必须小于ZK的tickTime*2默认4秒否则ZK会认为客户端失联过快。我们ZK的tickTime2000所以设为15000是安全的。xxl.job.trigger.pool.fast/slow参数决定了任务触发的并发能力。fast池处理高频小任务如每分钟一次的健康检查slow池处理低频大任务如每小时一次的数据清洗。我们按CPU核心数*10设置16核机器设为fast160, slow80。3.3 执行器集群部署不只是多起几个进程执行器xxl-job-executor-sample-springboot的集群部署核心是注册一致性和故障自愈。执行器的application.properties关键配置### xxl-job admin address list, such as http://address or http://address1,http://address2 # 关键此处填调度中心集群的VIP或DNS而非单个地址 xxl.job.admin.addresseshttp://xxl-job-admin-vip:8080/xxl-job-admin ### xxl-job, access token xxl.job.accessTokendefault_token ### xxl-job executor appname # 关键所有同类型执行器必须用相同appname这是注册分组的依据 xxl.job.executor.appnamedemo-executor ### xxl-job executor registry address # 关键执行器注册到ZK的路径必须与调度中心配置的registry.address一致 xxl.job.executor.registry.addresszookeeper://10.10.1.101:2181?zkSessionTimeout15000zkConnectionTimeout10000 ### xxl-job executor port # 关键每个执行器实例的端口必须唯一避免冲突 xxl.job.executor.port9999 ### xxl-job executor logpath xxl.job.executor.logpath/data/applogs/xxl-job/jobhandler ### xxl-job executor logretentiondays xxl.job.executor.logretentiondays30执行器启动后在ZK中生成的节点路径为/xxl-job/executor/{appname}/{ip:port}。例如/xxl-job/executor/demo-executor/10.10.1.201:9999 /xxl-job/executor/demo-executor/10.10.1.202:9999 /xxl-job/executor/demo-executor/10.10.1.203:9999调度中心通过监听/xxl-job/executor/demo-executor子节点变化实时维护执行器列表。当某个执行器进程崩溃ZK上的临时节点自动消失调度中心在3秒内ZK session timeout将其从列表剔除后续任务不再派发。实操心得执行器的xxl.job.executor.port不要用随机端口如0必须显式指定。我们曾用随机端口结果容器重启后端口变化ZK上残留旧节点10.10.1.201:34567新节点10.10.1.201:45678同时存在导致任务被重复派发到同一台机器的两个端口引发资源竞争。4. 高可用验证与故障注入实战4.1 四步验证法确认集群真正可用部署完成后绝不能只看UI上“执行器注册成功”就认为高可用达成。必须进行以下四步验证第一步ZooKeeper节点健康检查# 在任意ZK节点执行检查集群状态 echo stat | nc 10.10.1.101 2181 | grep Mode: # 输出应为 Mode: follower 或 Mode: leader # 检查所有节点是否在线 echo mntr | nc 10.10.1.101 2181 | grep zk_followers\|zk_synced_followers # zk_followers应为45节点集群1个leader4个follower第二步调度中心实例注册验证登录ZK客户端检查调度中心是否注册# 进入ZK CLI zkCli.sh -server 10.10.1.101:2181 # 查看调度中心注册路径 ls /xxl-job/admin # 应看到类似输出[xxl-job-admin-prod-10.10.1.101:8080, xxl-job-admin-prod-10.10.1.102:8080, ...]第三步执行器路由一致性验证在调度中心UI创建一个测试任务Cron:0/30 * * * * ?即每30秒触发执行器选择“轮询”策略。然后查看任务触发日志确认每次触发的执行器IP是否按顺序轮换10.10.1.201 → 10.10.1.202 → 10.10.1.203 → 10.10.1.201...手动停掉10.10.1.202的执行器进程等待3秒后观察日志是否跳过该IP直接轮到10.10.1.203再回到10.10.1.201第四步MySQL MGR故障切换验证模拟主节点宕机-- 在当前主节点执行先确认谁是主 SELECT MEMBER_HOST, MEMBER_ROLE FROM performance_schema.replication_group_members WHERE MEMBER_STATEONLINE; -- 假设10.10.1.101是主执行 SHUTDOWN;等待8秒后检查-- 在任意节点执行 SELECT MEMBER_HOST, MEMBER_ROLE FROM performance_schema.replication_group_members WHERE MEMBER_STATEONLINE; -- 应看到新主节点如10.10.1.102角色变为PRIMARY -- 创建一个新任务确认能正常保存到数据库4.2 故障注入实战模拟5种典型生产事故我们用混沌工程方法对集群进行5种故障注入记录恢复时间和影响范围故障类型注入方式观察现象恢复时间关键结论ZK单节点宕机systemctl stop zookeeper停1个followerZK集群继续服务调度中心无感知执行器注册不受影响1秒3节点ZK可容忍1节点故障5节点可容忍2节点ZK网络分区iptables -A INPUT -s 10.10.1.104 -j DROP隔离1个节点被隔离节点进入SUSPENDED状态其余4节点正常服务5秒ZK的electionTimeout默认200ms选举迅速MySQL主节点宕机systemctl stop mysqld停MGR主MGR自动选举新主调度中心连接新主无中断任务触发零丢失8秒MGR切换比传统主从快10倍以上调度中心单实例宕机kill -9 $(pgrep -f xxl-job-admin)UI访问短暂502DNS轮询到宕机实例3秒后自动切到健康实例任务触发不受影响3秒调度中心实例间无状态依赖故障隔离性好执行器全量宕机pkill -f demo-executor停所有执行器调度中心UI显示执行器离线任务触发日志大量RUNNING但无SUCCESS/FAIL30秒后自动标记为FAIL30秒执行器心跳超时默认30秒可调优至15秒注意执行器全量宕机时XXL-Job的“失败重试”机制会按配置的重试次数默认0次重新派发。若业务允许建议在任务配置中开启重试如重试2次间隔10秒避免单次网络抖动导致任务失败。4.3 生产环境监控告警清单集群上线后必须建立以下7项核心监控ZooKeeper监控zk_followers必须≥4、zk_outstanding_requests1000需告警、zk_avg_latency10ms需告警MySQL MGR监控MEMBER_STATEONLINE所有节点、MEMBER_ROLEPRIMARY仅1个、RECEIVED_TRANSACTION_SET延迟1000调度中心JVM监控heap_used_percent80%告警、thread_count500告警、gc_pause_time1s告警执行器心跳监控通过ZK API/xxl-job/executor/{appname}节点数低于预期数量立即告警任务触发延迟监控采集xxl_job_log.trigger_code200的日志计算trigger_time到handle_time的差值P955s告警数据库连接池监控HikariCP的active连接数持续90%告警timeout计数0立即告警网络连通性监控调度中心到ZK、MySQL、执行器的TCP连通性telnet zk_ip 2181我们用PrometheusGrafana搭建监控面板其中最关键的“集群健康度”仪表盘包含左上角ZK节点在线数5/5右上角MGR节点在线数3/3中间调度中心实例数3/3左下执行器注册数20/20右下最近1小时任务失败率0.1%5. 常见问题排查与独家避坑指南5.1 “任务重复触发”问题的根因分析与修复这是集群中最让人抓狂的问题。现象一个Cron任务如0 0 * * * ?在日志里出现两条SUCCESS记录时间相差几秒。根因排查路径首先确认Quartz集群模式是否启用检查application.properties中是否有xxl.job.quartz.scheduler.instanceIdAUTO且xxl.job.quartz.dataSource.myDS配置正确。若未配置Quartz会以单机模式运行每个调度中心实例独立触发。检查MySQL的qrtz_locks表SELECT * FROM qrtz_locks WHERE lock_nameTRIGGERS;正常情况下该行lock_name应被某一个实例持有locked_by字段为实例名。若出现多行或locked_by为空说明Quartz锁未生效。检查MySQL时区SELECT global.time_zone, session.time_zone;若为SYSTEM而系统时区与JVM时区不一致如JVM用Asia/ShanghaiMySQL用UTC会导致Quartz认为触发时间未到多个实例同时抢锁。修复方案强制MySQL使用东八区SET GLOBAL time_zone 08:00;在application.properties中添加spring.jackson.date-formatyyyy-MM-dd HH:mm:ss和spring.jackson.time-zoneGMT8重启所有调度中心实例清空qrtz_*表备份后让Quartz重建锁表5.2 “执行器注册不上”问题的10种可能及解决方案执行器启动后UI上始终看不到注册信息。按优先级排查序号可能原因检查命令解决方案1执行器配置的xxl.job.admin.addresses无法访问调度中心curl -v http://调度中心IP:8080/xxl-job-admin/actuator/health确保网络连通防火墙开放8080端口2xxl.job.executor.appname与调度中心任务配置的执行器名称不一致查看UI任务配置页的“执行器”下拉框保持完全一致区分大小写3ZooKeeper连接超时echo ruok | nc 10.10.1.101 2181检查ZKclientPort调整zkConnectionTimeout100004执行器端口被占用netstat -tuln | grep 9999修改xxl.job.executor.port为未占用端口5调度中心未配置xxl.job.admin.registry.address查看调度中心application.properties必须配置且与执行器的xxl.job.executor.registry.address一致6执行器JVM时区与调度中心不一致java -XshowSettings:properties -version 21 | grep user.timezone统一设为-Duser.timezoneAsia/Shanghai7MySQLxxl_job库缺少xxl_job_registry表SHOW CREATE TABLE xxl_job_registry;执行xxl-job-admin/doc/db/tables.sql建表8执行器accessToken与调度中心不匹配查看调度中心xxl.job.accessToken保持一致或设为禁用token9Docker容器内网DNS解析失败docker exec -it executor ping zookeeper在docker run中添加--add-hostzookeeper:10.10.1.10110Kubernetes Service DNS解析超时kubectl exec -it executor -- nslookup xxl-job-admin增加dnsConfig.options: [{name: timeout, value: 2}]5.3 “任务触发延迟”问题的性能调优三板斧任务本该在整点触发却延迟10秒以上。这不是网络问题而是调度中心内部瓶颈。第一板斧调大触发线程池# 默认fast200slow100对于高频任务如每秒10次明显不足 xxl.job.trigger.pool.fast500 xxl.job.trigger.pool.slow200第二板斧优化MySQL慢查询开启MySQL慢查询日志发现SELECT * FROM xxl_job_info WHERE ...语句耗时2秒。原因是xxl_job_info表缺乏复合索引。添加ALTER TABLE xxl_job_info ADD INDEX idx_trigger_status_next_time (trigger_status,trigger_next_time);第三板斧分离日志写入xxl_job_log表写入频繁拖慢主库。我们将日志表拆分到独立MySQL实例-- 创建日志专用库 CREATE DATABASE xxl_job_log CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; -- 修改调度中心配置日志写入专用库 xxl.job.log.datasource.urljdbc:mysql://10.10.1.104:3306/xxl_job_log?...实操心得我们曾遇到一个极端案例——某任务每秒触发100次单次执行耗时50ms导致xxl_job_log表每秒写入100条MySQL IOPS打满。最终方案是执行器本地异步写日志用Disruptor队列每100ms批量刷到数据库将IOPS降低90%。6. 运维手册日常巡检与升级 checklist6.1 每日巡检清单5分钟完成ZooKeeper健康echo stat | nc 10.10.1.101 2181 | grep Mode:—— 确认leader存在MGR状态mysql -h10.10.1.101 -e SELECT MEMBER_HOST,MEMBER_ROLE FROM performance_schema.replication_group_members;—— 确认3节点online调度中心实例curl -s http://xxl-job-admin-vip:8080/xxl-job-admin/actuator/health | jq .status—— 返回UP执行器在线数echo ls /xxl-job/executor/demo-executor | nc 10.10.1.101 2181 \| wc -l—— 应等于部署数任务失败率grep FAIL /data/applogs/xxl-job/jobhandler/*.log \| wc -l—— 24小时内10次