Beego高频点赞/收藏应避免直接ORM写库，须用Redis原子操作（如SETNX/EXISTS/INCRBY）实现轻量、幂等、低延迟交互，并通过异步批量落库保障最终一致性。
Beego 项目里做点赞/收藏这类高频写操作，别直接用 orm.Add() 或 orm.ReadOrCreate() 往数据库里硬插——高并发下秒变锁表、超时、重复记录。核心思路是：写操作必须轻量、幂等、可降级，读操作尽量缓存。
为什么不能在 Controller 里直接调用 ORM 写库
Beego 的 orm.Ormer 实例本身不带连接池复用控制，每次 orm.NewOrm() 都可能新建事务或复用底层 *sql.DB 连接，但没做并发限流和失败重试。更关键的是：ReadOrCreate 在并发场景下大概率触发唯一键冲突（比如用户对同一内容重复点赞），而 beego orm 对 ErrNoRows 和 ErrDuplicateEntry 的处理不统一，容易漏判或 panic。
- 多个请求同时执行
ReadOrCreate→ 都查不到记录 → 都尝试插入 → 至少一个失败（MySQL 报ERROR 1062 (23000): Duplicate entry） - 没包
recover或没检查err类型 → Controller 直接 500 - 没设
context.WithTimeout→ 数据库慢查询拖垮整个接口
用 Redis + 原子操作兜底点赞/收藏状态
把「用户是否点过赞」这种布尔态行为交给 Redis 处理，比查库快两个数量级，且天然支持原子性。推荐结构：like:content_id:user_id（String）或 like:content_id（Set）。前者省空间、适合需要反查的场景；后者查是否存在更快，适合纯校验。
- 点赞：用
SETNX like:123:456 1（user_id=456 对 content_id=123 点赞），返回 1 表示首次操作成功 - 取消点赞：用
DEL like:123:456 - 查是否点过：用
EXISTS like:123:456，不是GET—— 减少网络开销 - 计数：单独维护
like_count:123，用INCRBY like_count:123 1/DECRBY like_count:123 1
注意：Redis 操作必须配超时（如 redis.DialReadTimeout(500 * time.Millisecond)），避免单点故障拖死 Beego 请求链路。
异步落库 + 定时聚合，避免实时写压力
点赞/收藏动作不需要立刻进 MySQL。你可以用 Beego 的 bee run 启动时注册一个 goroutine，或者用简单消息队列（如 Redis List + BRPOP）收拢写请求，再批量刷库。
- 定义结构体：
type LikeEvent struct { UserID int64; ContentID int64; Action string // "like" or "unlike"; Timestamp time.Time } - Controller 只做：
_, err := redisClient.RPush("like_queue", data).Result()，成功就返回 200 - 后台 worker 每 100ms
BRPOP like_queue 0拉一批事件，用INSERT ... ON DUPLICATE KEY UPDATE批量 upsert 到 MySQL - 计数类字段（如
like_count）不要依赖实时 count(*)，从聚合表或 Redis 计数器读
这样即使 MySQL 临时抖动，也不影响前端交互体验——用户看到“已点赞”是 Redis 写成功的反馈，不是数据库 commit 的结果。
Beego 中如何安全注入 Redis 客户端
别在每个 Controller 方法里 redis.Dial(...)。利用 Beego 的 AppConfig 和全局变量，在 main.go 初始化阶段完成连接，并导出为包级变量：
var RedisClient *redis.Client
<p>func init() {
addr := beego.AppConfig.String("redis::addr")
pwd := beego.AppConfig.String("redis::password")
db, _ := beego.AppConfig.Int("redis::db")
RedisClient = redis.NewClient(&redis.Options{
Addr: addr,
Password: pwd,
DB: db,
DialTimeout: 500 <em> time.Millisecond,
ReadTimeout: 500 </em> time.Millisecond,
WriteTimeout: 500 * time.Millisecond,
})
}
然后在 Controller 里直接用 models.RedisClient（假设你放在 models 包）——既避免重复建连，又保证所有地方用的是同一个健康连接实例。记得加 defer RedisClient.Close() 在应用退出时。
真正难的不是代码怎么写，而是想清楚：用户点一下“赞”，他到底需要什么？是立刻看到红心变色，还是等数据库 commit 成功才敢松手？答案通常是前者。所以把强一致性让渡给 Redis，把最终一致性交给后台任务，才是 Beego 高并发点赞功能的实际落地方式。
