MiFaZhan
2bec257289
iotlcm-worker-svr：异步执行中枢（RabbitMQ 消费者 + 全量同步编排）。 - Go module：iotlcm-worker-svr → git.5iot.com/iotlcm-public/iotlcm-worker-svr（214 文件） - 凭据与内部标识脱敏：MySQL/Redis 凭据、私网与生产 IP、内网域名、 库名 xiujie_admin → iotlcm、哨兵名占位 - 159 处真实手机号 → 合法 11 位编造号（保留号段与后 4 位，维持互异， 不破坏「校验 MSISDN 格式」等测试断言） - 移除内部资产：CI 触发器、Jenkins 触发测试文档、预演门禁与镜像 digest 记录 - Dockerfile 改用公共基础镜像（golang:1.25-alpine → alpine:3.23）， 移除写死的 git 凭据 - README 重写（架构/全量同步模型/配置/已知失败），补 Apache-2.0 LICENSE，LF 行尾 + .gitattributes 已知：3 个测试包在源仓同一提交上同样失败（client/upstream、 service/allocate、service/inbound），属既有缺陷，本仓未引入亦未修复。
3.5 KiB
3.5 KiB
卡状态同步 Run 计数与收尾
状态同步此前创建了 Run 元数据，但使用渠道级 EnqueueBatch/Enqueue 和 AckBatch，这些操作不会维护 Run 计数，也不会调用 Run 完成判定。任务实际处理结束后，元数据因此可能长期停在 running，成功、失败计数均为零。
新任务行为
全量和单卡状态同步均改用 Run 队列。RunQueueEnabled 控制 Run 消费，RoundRetryEnabled 独立控制多轮重试；状态同步固定单轮，流量同步继续保留原来的多轮策略。
- 入队按稳定 Task ID 去重；
activeCount包含排队及租约中的任务，背压不能再次加上inflightCount。 - 成功结果先写 MySQL，再凭租约令牌原子确认、累加成功数。永久业务失败记入失败数及失败记录；数据库失败和可恢复网络失败保留任务，等待租约恢复。
- 电信渠道受限时，先确认同批已落库的成功结果，再凭触发任务的有效租约封禁该 Run 的渠道。其余已入队任务记为
channel_blocked终态失败，保留逐卡记录；尚未入队而被拒绝的任务不计入已处理数量。此计数规则仅用于状态同步。 - 只有
producerDone=1，且activeCount/inflightCount/nextRoundCount均为零，才写入completedAt。无失败为completed，存在失败为completed_with_failures。周期性检查覆盖空 Run 和消费先结束的情形。 - 元数据、任务状态和失败记录在收尾后保留 30 天。
sim_status_queue_round_batch是批次尝试日志，不能直接按其failed汇总终态失败；最终 Run 计数以元数据及sim_status_queue_run事件为准。
配置和后续上线步骤
使用 simStatusQueueSync.redisKeyPrefix，默认 sim-status:。生产者和消费者锁仍使用原键。
本次代码交付不部署、不修改旧 Run。后续上线应遵循以下顺序：
- 暂停状态同步的新触发入口（定时、手动及单卡），让旧 Worker 完成现有工作。核对两个状态 MQ 队列的 ready/unacked 为零、无在途 producer，以及旧命名空间所有渠道 ZSet 与租约为零。历史
status=running本身不能作为仍有业务任务的判据。 - 使用新代码和
redisKeyPrefix: "sim-status:"启动，保持锁键配置不变；恢复触发入口。 - 先运行小规模/单卡同步，再核验一次全量同步：MySQL 状态及同步时间符合成功结果，Run 计数持续变化，最终唯一入队数量（任务状态 Hash 的 HLEN）等于成功数加失败数，活动计数归零、终态与完成时间正确。查询
sim-status:{<runId>}:meta。 - 如需回滚，先暂停新触发并等待 v2 队列处理结束，再停新 Worker、恢复旧版本和旧配置；有未完成 v2 任务时应保留可消费 v2 的版本继续处理，不直接切回旧版遗留任务。
自动验证
go test ./...
Redis 集成测试要求 PATH 存在 redis-server，或设置 REDIS_SERVER_BINARY 为可执行文件路径。每个测试启动独立的回环地址 Redis，使用临时目录且关闭持久化，退出后清理进程；不会读取应用 Redis 配置。缺少二进制时会明确 skip，验收时应确认这些测试实际执行。
覆盖成功/失败混合、空 Run、生产消费交错、重复入队/确认、租约失效及恢复、数据库和网络失败、渠道封禁及逐卡失败记录、多 Run 并行、单卡入口和背压；另回归流量五轮重试与原渠道封禁语义。