面试场景题：请设计一个微信朋友圈系统
一、整体系统方案设计
1. 核心业务特性
- 功能：发布（文字 / 图片 / 视频）、查看好友朋友圈、点赞 / 评论、删除、权限控制（屏蔽 / 仅自己可见等）
- 技术特性：高并发（亿级 DAU）、读多写少（查看远多于发布）、数据量大、实时性中等（非强实时）、隐私性要求极高
2. 系统架构分层（微服务拆分）
用户端
接入层：Nginx+LVS
应用层
发布服务PostService
展示服务FeedService
互动服务InteractionService
权限服务PermissionService
中间件层
Redis集群
MQ队列RocketMQ
对象存储OSS
存储层
MySQL分库分表（主从）
3. 核心流程设计
（1）发布朋友圈流程
- 用户上传媒体（图片 / 视频）到 OSS，获取媒体 URL；
- 发布请求经接入层转发到
PostService，校验内容合规、用户权限； - 写入 MySQL 主库（朋友圈主表），异步删除该用户的朋友圈列表缓存；
- 可选：通过 MQ 发送 “发布成功” 通知（非核心流程）。
（2）查看朋友圈流程
- 用户请求拉取好友朋友圈，转发到
FeedService； - 调用
PermissionService获取该用户的好友列表和屏蔽列表； - 优先从 Redis 缓存拉取好友朋友圈数据，缓存未命中则从 MySQL 从库读取，再回写缓存；
- 对数据做过滤（屏蔽用户、权限校验）、排序（时间倒序）、分页后返回。
（3）点赞 / 评论流程
- 请求转发到
InteractionService，校验好友关系、屏蔽状态； - 写入点赞 / 评论表（主库），异步调用 Redis 的
INCR/DECR更新计数缓存； - 通过 MQ 异步发送点赞 / 评论通知给朋友圈发布者（非实时，最终一致即可）。
4. 高可用 & 高并发优化
- 服务集群化：所有微服务部署多实例，避免单点故障；
- 分库分表：按
user_id哈希分库分表，解决单库性能瓶颈； - 读写分离：MySQL 主库写、从库读，提升读性能；
- 限流降级：接入层 / 应用层用令牌桶限流，高并发时降级非核心功能（如暂时隐藏点赞数）；
- 隐私校验：所有查询流程前置权限校验，避免泄露非好友的朋友圈数据。
二、缓存方案设计
核心目标：缓存热点数据，减少数据库访问，提升响应速度（Redis 作为核心缓存）。
1. 缓存数据结构与 Key 设计
| 缓存数据类型 | Key 设计 | 数据结构 | 说明 |
|---|---|---|---|
| 用户朋友圈列表 | feed:user:{user_id}:timeline | ZSet | score = 发布时间戳，member = 朋友圈 ID，支持排序 / 分页 |
| 单条朋友圈详情 | feed:post:{post_id} | Hash | 存储内容、媒体 URL、可见范围等 |
| 朋友圈点赞 / 评论数 | feed:interaction:{post_id}:like/comment | String | 计数器，用 INCR/DECR 更新 |
| 好友列表 / 屏蔽列表 | relation:friend:{user_id}/block | Set | 存储好友 / 被屏蔽用户 ID，快速校验权限 |
2. 缓存更新策略
- 发布 / 删除朋友圈：先写数据库，再删除缓存（而非更新缓存），避免缓存与数据库不一致（缓存更新失败风险）；
- 点赞 / 评论：先写数据库，异步调用 Redis
INCR/DECR更新计数（允许短暂最终一致）； - 好友关系变更：主动删除对应的好友 / 屏蔽列表缓存，下次访问重新加载。
3. 缓存异常防护
- 缓存穿透：对不存在的
user_id/post_id缓存空值（过期时间 5 分钟）； - 缓存击穿：热点朋友圈（如大 V 内容）设置永不过期，发布者删除时主动清理；
- 缓存雪崩：缓存过期时间打散（基础时间 + 随机 0-60 秒），Redis 集群主从 + 哨兵部署。
三、数据库表设计方案
核心原则：满足第三范式为主，适当反范式（JSON 存储）提升读性能，按user_id分库分表。
1. 核心表结构设计
（1）朋友圈主表（moments_post）
| 字段名 | 类型 | 说明 |
|---|---|---|
| post_id | bigint | 主键（雪花算法，全局唯一） |
| user_id | bigint | 发布者 ID（分库分表键） |
| content | text | 文字内容（可为空） |
| media_list | json | 媒体 URL 列表（图片 / 视频，如 ["url1","url2"]） |
| visible_scope | tinyint | 可见范围：0 - 全部好友 1 - 仅自己 2 - 指定好友 3 - 不给谁看 |
| target_users | json | 可见 / 不可见用户列表（scope=2/3 时非空） |
| is_deleted | tinyint | 软删除标记（0 - 未删 1 - 已删） |
| create_time | datetime | 发布时间 |
| update_time | datetime | 更新时间 |
- 索引：主键索引（post_id）、二级索引（user_id, create_time）（按用户 + 时间拉取）
（2）朋友圈点赞表（moments_like）
| 字段名 | 类型 | 说明 |
|---|---|---|
| like_id | bigint | 主键 |
| post_id | bigint | 朋友圈 ID |
| user_id | bigint | 点赞者 ID（分库分表键） |
| is_canceled | tinyint | 取消点赞标记（0 - 未取消 1 - 已取消） |
| create_time | datetime | 点赞时间 |
- 索引：主键索引（like_id）、联合索引（post_id, user_id）（防止重复点赞）
（3）朋友圈评论表（moments_comment）
| 字段名 | 类型 | 说明 |
|---|---|---|
| comment_id | bigint | 主键（雪花算法） |
| post_id | bigint | 朋友圈 ID |
| user_id | bigint | 评论者 ID（分库分表键） |
| content | varchar(512) | 评论内容 |
| reply_to_id | bigint | 回复的评论 ID（0 = 直接评论） |
| is_deleted | tinyint | 软删除标记 |
| create_time | datetime | 评论时间 |
- 索引：主键索引（comment_id）、二级索引（post_id, create_time）
（4）好友关系表（friend_relation）
| 字段名 | 类型 | 说明 |
|---|---|---|
| relation_id | bigint | 主键 |
| user_id | bigint | 用户 ID（分库分表键） |
| friend_id | bigint | 好友 ID |
| block_flag | tinyint | 屏蔽标记（0 - 未屏蔽 1 - 已屏蔽） |
| create_time | datetime | 加好友时间 |
- 索引：主键索引（relation_id）、联合索引（user_id, friend_id）
2. 表设计关键说明
- 软删除：所有核心表用
is_deleted标记删除，避免物理删除导致数据丢失，方便恢复； - 分库分表键：选择
user_id（而非post_id），因为朋友圈读写均围绕 “用户” 展开，减少跨库操作； - 反范式优化：
media_list/target_users用 JSON 存储，避免多表关联，提升读效率（符合 “读多写少” 特性）； - 全局唯一 ID：朋友圈 ID / 评论 ID 用雪花算法生成，避免分库分表后的主键冲突。
总结
- 系统架构：按 “发布 / 展示 / 互动 / 权限” 拆分微服务，接入层做负载均衡，存储层分库分表 + 读写分离，适配亿级用户高并发；
- 缓存策略：Redis 缓存热点数据（朋友圈列表 / 详情 / 计数），采用 “先写库后删缓存” 保证一致性，通过空值缓存、过期时间打散防护缓存异常；
- 数据库设计：核心表按
user_id分库分表，软删除 + JSON 反范式优化，索引针对 “用户 + 时间”“朋友圈 ID + 用户 ID” 设计，兼顾性能和业务需求。