初始模型：
用户对某个对象点赞，本质上就是保存一条 user_id + target_id 的点赞关系；最简单可以直接落 MySQL，唯一索引保证不能重复点赞。Redis 可以作为加速层，辅助做去重和计数。
- 去重：同一个用户不能重复点赞 → MySQL 唯一索引，或者 Redis Set / Bitmap 辅助判断
- 点赞数统计：每次都查数据库
count(*)成本高 → Redis 单独维护点赞计数 - 高并发突发：明星内容瞬间大量点赞，数据库写入扛不住 → 先写 Redis / MQ，后台异步批量落库
- 热 Key：单个热门内容的点赞量特别大，所有请求集中到一个 Redis Key → 按
hash(user_id)做 Key 分片，分散压力 - 总量过大：单个 Set 里用户数量太多 → 同样通过分片拆成多个 Set / Bitmap
- 最终一致性：Redis、MQ、数据库之间可能短暂不一致 → 异步落库 + 定期对账补偿
- 额外能力：如果还要展示“谁点过赞”“我是否点赞”“点赞排行榜”等 → 再按具体查询需求设计索引或额外缓存
最后主线就是：
保存点赞关系 → 去重 → Redis 计数 → 高并发时 MQ 削峰 → 热 Key / 大 Key 分片 → 异步落库 → 对账兜底。