日期：2026-07-11
标签：#面试 #八股 #后端 #系统设计 #点赞 #场景题
一句话答案
以动态和用户建立唯一点赞关系，点赞/取消做幂等状态转换，计数异步聚合；展示时还要按好友可见性过滤并批量查询点赞用户。
面试口语版
关系表使用 postId + userId 唯一键，点赞是插入或把状态改为有效，取消是改为无效，不能盲目加减计数。高并发时可在 Redis Lua 中原子修改集合/状态和计数，再通过可靠事件落数据库；数据库唯一约束兜底。朋友圈详情批量返回当前用户是否点赞、点赞数和部分好友头像，完整列表游标分页。动态删除、拉黑或可见范围变化时，读路径必须重新校验权限，点赞通知异步发送且可聚合。
关键细节
- 点赞关系是真实数据，计数是可重建派生数据。
- 同一个请求重复到达不能重复加计数。
- 大 V 动态可能形成热点 Key，需要本地缓存、分桶或异步聚合。
- 通知可合并为“多人赞了你”，避免消息轰炸。
面试官追问
- 朋友圈与普通内容点赞有什么额外要求？
- 点赞后立刻取消，消息乱序怎么办？
- 如何展示“共同好友点赞”？
面试官追问参考答案
1. 朋友圈与普通内容点赞有什么额外要求？
核心是社交可见性：动态权限、好友关系、拉黑和删除都会影响点赞是否可见。查询和通知都不能只按 postId 返回全部用户，必须基于当前关系做权限过滤并防止隐私泄露。
2. 点赞后立刻取消，消息乱序怎么办？
事件携带关系版本或更新时间，消费者只接受更高版本，数据库按 (postId,userId) 幂等更新最终状态。计数聚合使用可撤回事件，定时从关系明细校准；通知发送前可短暂聚合或检查最终状态。
3. 如何展示“共同好友点赞”？
先获取动态点赞用户集合，再与当前用户好友集合求交集，并按时间或亲密度取前几个。规模大时使用缓存的好友集合、倒排关系或离线社交图服务，所有结果仍受隐私策略约束。
学习清单
- 区分关系、计数和通知三条链路。
- 能说明社交权限与乱序处理。
Maintained by · YihuiEdit on GitHub