直接用 rand.intn 做任务分发会出问题，因为它仅实现纯随机选择，不感知节点真实负载，可能导致任务集中压在刚启动或高负载节点上，而其他空闲节点闲置；真正可用的负载均衡必须基于实时指标（如待处理任务数、cpu、内存等），需外部系统采集或自行埋点。
为什么直接用 rand.Intn 做任务分发会出问题？
因为它是纯随机，不感知节点真实负载。你看到调度器把任务“均匀”发出去了，但实际可能 3 个任务全压在刚启动、还没上报心跳的 Worker 上，而其他节点 CPU 已满却收不到新任务。
真正可用的负载均衡必须基于实时指标：当前待处理任务数、CPU 使用率、内存占用、网络延迟。Golang 本身不提供这些采集能力，得靠外部系统或自己埋点。
-
rand.Intn(len(s.WorkerIDs))只适合单机测试，上线后必须替换 - Consul 或 etcd 的服务健康状态（如 TTL 心跳）只能判断“存活”，不能反映“忙闲”
- 如果用 Nginx 做 HTTP 层负载，它对后端 Go Worker 的长连接、任务粒度无感知，仅转发请求，不参与任务调度逻辑
TaskQ 的 redisq.Queue 如何实现分布式任务均衡？
它不是靠调度器主动挑 Worker，而是让所有 Worker 竞争消费同一 Redis 队列。Redis 的 BRPOP 或 LPOP 加分布式锁（SET key value NX PX 30000）保证同一任务只被一个 Worker 拿走——本质是“被动拉取 + 最先抢到者执行”，天然规避了中心调度器的单点和状态同步问题。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- Worker 启动后只订阅一个队列名（如
"task:email"），不注册 IP/端口，也不上报负载 - 任务入队时无需指定目标 Worker，由 Redis 自动做 FIFO 或优先级排序（需配合 Sorted Set）
- 失败重试走
RetryPolicy，不是靠调度器重发，避免重复调度风险 - 缺点：无法按 CPU 负载动态调权，但胜在简单、可靠、水平扩展无瓶颈
用 xxl-job-executor-go 时，RegistryKey 和负载均衡的关系
RegistryKey 是执行器集群的逻辑分组标识，不是负载均衡策略本身。xxl-job-admin 后台看到的“多台机器在线”，只是表示这些 Go 进程都向同一个 RegistryKey 注册了；真正决定哪个节点执行任务的是 admin 的调度算法（默认轮询），Go 客户端本身不参与选择。
- 如果你在 admin 页面给执行器配置了“阻塞策略：单机串行”，那即使有 10 个 Go Worker，也只会有一个在跑任务
- 要启用并发执行，必须在 admin 中将该执行器的“运行模式”设为“并行”，且 Go Worker 的
executorPort各不相同（否则注册冲突） - xxl-job 不暴露 Worker 实时负载数据，所以它的“负载均衡”只是静态分片，不是动态适配
Consul + 自研权重计算时，Agent.ServiceRegister 哪些字段影响调度决策？
关键不是注册动作本身，而是你往 Checks 里塞什么。Consul 默认只检查端口连通性，但你可以加自定义 HTTP Check，返回 JSON 包含 {"cpu": 65, "queue_len": 12}，然后在调度器里解析这个响应做加权选择。
-
Check.HTTP必须指向 Worker 提供的 /health 接口，且该接口要实时返回负载指标 -
Check.Timeout和Check.Interval要设小（如 2s），否则负载变化延迟超过 10 秒就失去意义 - 不要依赖
Service.Tags存权重——它是静态标签，改了要手动触发 reload，没法自动生效 - Consul 的 KV 存储可以存动态权重，但每次调度前都要
api.KV.Get一次，IO 开销大，建议本地缓存 + TTL 刷新
真正难的不是选哪个节点，而是让每个节点的“负载值”可信且低延迟。采集不准，再好的算法也白搭。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
