Redis的INCR能扛大并发点赞因其是原子操作，避免竞态；Go中需用带超时的context调用Incr，去重须用Lua脚本结合SISMEMBER与INCR，强一致场景应以DB存明细、Redis作缓存。
为什么直接用 INCR 就能扛住大并发点赞
因为 Redis 的 INCR 是原子操作，底层不依赖客户端加锁或事务，命令一发就执行完，不会出现两个请求同时读旧值、各自+1、再写回导致漏计数的问题。Go 里只要确保每次调用都走独立的 redis.Conn 或使用连接池（如 redis.UniversalClient），就天然支持高并发。
常见错误是自己在 Go 层做“先 GET 再 INCR”模拟——这已经不是原子操作了，哪怕只差几微秒，也会在高并发下丢数据。
- 别用
GET+SET手动加一；必须用INCR或INCRBY - 点赞计数建议单独 key，比如
post:123:likes，别和文章内容混在同一个 hash 里 - 如果需要初始化为 0，
INCR会自动创建 key 并设为 1，不用提前SET
Go 里用 github.com/redis/go-redis/v9 怎么安全调用 INCR
v9 版本默认用 context 控制超时，这是关键——没设 timeout 的 redis 调用，在网络抖动时可能卡死 goroutine，拖垮整个服务。
示例中 ctx, cancel := context.WithTimeout(context.Background(), 300*time.Millisecond) 是硬性建议，不是可选。
立即学习“go语言免费学习笔记（深入）”；
- 每次调用前必须新建带 timeout 的
context.Context，别复用全局 context - 用
client.Incr(ctx, "post:123:likes").Val()获取结果，.Val()才真正触发网络请求 - 检查 error：如果是
redis.Nil，说明 key 不存在（但INCR不会返回这个）；其他 error 要记录并降级（比如记日志+本地内存缓存临时计数）
点赞要“去重”，不能重复计数，怎么办
INCR 本身不解决去重，它只负责累加。去重得靠业务层：每个用户对每条内容只能点一次，本质是「集合成员判断 + 原子计数」两步，且必须一起完成。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
推荐用 Redis 的 SETNX + INCR 组合，但更稳妥的是用 Lua 脚本把逻辑锁死在服务端：
local liked = redis.call("SISMEMBER", "post:123:liked_by", ARGV[1])
if liked == 1 then
return 0
else
redis.call("SADD", "post:123:liked_by", ARGV[1])
redis.call("INCR", "post:123:likes")
return 1
end
Go 中用 client.Eval(ctx, script, []string{}, userID).Val() 调用，返回 1 表示点赞成功，0 表示已点过。
- 别用两次 round-trip（先查 set 再 incr）：中间可能被其他请求插入
-
SISMEMBER在大数据量时有性能影响，但万级用户内没问题；超十万考虑分片或用布隆过滤器预判 - Lua 脚本在 Redis 里是原子执行的，不用担心并发干扰
什么时候不该用 Redis 计数，而该写数据库
当点赞需要强一致性审计、关联用户行为日志、或要支持按时间范围查询“谁在什么时间点了赞”，Redis 就只是缓存，不能替代数据库。
典型做法是：Redis 计数 + MySQL 记录明细，但写库不能同步阻塞主流程。点赞接口应快速返回，写库走异步消息（如 Kafka）或延迟任务（如 asynq）。
- Redis 计数用于实时展示（首页 Feed 的点赞数），数据库明细用于后台运营、风控、导出报表
- 不要让 Redis 和 DB 的数值强一致——允许短暂不一致（比如 Redis 多了 2 个，DB 还没写入），用定时 job 对账修复
- 如果 DB 写失败，Redis 已 incr 的值不能回退，否则会引发负数或错乱，宁可多不可少
最麻烦的其实是“取消点赞”的幂等性和回滚时机：用户点两次取消，第二次应该静默忽略，但 Redis 的 DECR 不知道之前有没有点过，所以必须依赖去重集合（SREM + DECR 同样要用 Lua 保证原子性）。这点很容易被忽略，一写错就导致计数变负或不准。
