sync.Map适用于单机、短生命周期任务去重，需LoadOrStore判断存在性并defer Delete防泄漏；Redis+Lua实现跨实例原子去重；数据库唯一索引提供强一致性；MQ自身去重不可替代业务层key维度去重。
用 sync.Map 做内存级任务去重，适合单机且生命周期短的场景
任务去重最直接的思路是“执行前查是否存在正在运行的任务”，sync.Map 是 Go 标准库中线程安全的内存映射结构，适合做轻量级、无持久化需求的去重标识缓存。
常见错误是直接用普通 map 配合 sync.Mutex，但锁粒度粗、易阻塞；或误用 sync.Map.LoadOrStore 的返回值逻辑，导致任务被跳过而非排队。
- 只对任务唯一键（如
"send_email:123"）做LoadOrStore("key", true)，返回false表示已存在 → 拒绝新执行 - 任务结束后必须调用
Delete("key")，否则内存泄漏且后续永远被拦截 - 不适用于分布式环境——不同实例间无法感知彼此的
sync.Map状态 - 如果任务可能 panic 或提前退出，务必用
defer保证Delete执行
用 Redis + Lua 脚本实现原子性去重，跨进程/跨机器通用
当服务部署多实例，或需控制任务全局唯一执行时，Redis 是最常用选择。关键不是“存个 key”，而是避免 SETNX + EXPIRE 的竞态：两个协程同时通过 SETNX，再先后设过期，会导致一个任务被漏判。
正确做法是用 Lua 脚本把“判断+设置+设过期”三步压成原子操作：
立即学习“go语言免费学习笔记（深入）”；
if redis.call("exists", KEYS[1]) == 1 then
return 0
else
redis.call("setex", KEYS[1], ARGV[1], "1")
return 1
end
Go 中调用示例：redisClient.Eval(ctx, luaScript, []string{taskKey}, ttlSeconds).Int() 返回 1 表示获得执行权，0 表示已被占用。
- 务必设置合理
ttl（比如任务预期耗时 × 2），防止因崩溃导致 key 永久残留 - 不要用
SET key val EX seconds NX替代 Lua——虽然 Redis 6.2+ 支持，但旧版本兼容性差，且部分客户端封装不透传NX语义 - 如果任务执行时间远超 TTL，需在任务中定期
EXPIRE延长 key 生存期（即“续租”），否则可能被其他实例误抢
用数据库唯一索引 + INSERT IGNORE 实现强一致性去重
当已有业务数据库、且任务 ID 可结构化（如 task_type + resource_id 组合），用唯一索引是最省心的方案。它不依赖外部组件，天然支持事务回滚和持久化。
典型表结构：CREATE TABLE task_locks (task_key VARCHAR(255) PRIMARY KEY, created_at TIMESTAMP DEFAULT NOW());
- 执行任务前
INSERT IGNORE INTO task_locks (task_key) VALUES (?);，成功则继续，失败（err != nil && IsDuplicateEntry(err)）则跳过 - 任务完成后
DELETE FROM task_locks WHERE task_key = ?;，同样建议加defer保障清理 - 注意 MySQL 的
INSERT IGNORE不会报错，但会静默忽略；PostgreSQL 需用INSERT ... ON CONFLICT DO NOTHING - 高并发下大量
INSERT IGNORE可能引发表锁或死锁，建议配合重试退避（如指数退避 10ms~100ms）
为什么不能只靠消息队列的“去重”功能？
很多同学看到 Kafka / RabbitMQ / Pulsar 提供“消息去重”选项就以为万事大吉，但实际这些机制只针对“相同消息体重复投递”，而业务上真正的重复是“同一业务意图多次触发”，比如用户连点两次提交按钮，生成两条内容不同但语义相同的任务消息。
也就是说，MQ 层的去重是传输层的，你得在应用层定义“什么是重复”——这取决于你的 task_key 如何构造，而不是靠 MQ 自动生成的 message ID。
- Kafka 的
enable.idempotence=true只防 Producer 重发，不防多个 Producer 同时发同一任务 - RabbitMQ 的
x-message-ttl或插件式去重，依赖消息 header 或 body 内容哈希，无法覆盖参数变化但语义重复的场景（如send_sms(123, "hi")和send_sms(123, "hello")） - 真正可控的方式，还是在消费端用上述任一方法（Redis / DB / sync.Map）校验业务维度的唯一键
去重逻辑离业务越近越可靠，但代价是复杂度上移；选哪种方案，本质是在一致性、性能、运维成本之间做显式取舍。最容易被忽略的是：没有为“执行中任务异常退出”设计兜底清理机制，结果就是锁永远挂着，后续所有同类任务全被拦死。
