系统设计题总结：关注 / 取关系统设计（模拟面试）
一、题目背景与要求
设计一个支持亿级用户的关注 / 取关系统，具备以下功能：
- 用户之间形成单向关注关系（可进一步支持互关判断）
- 用户可查询自己关注列表、粉丝列表、是否互关、共同关注
- 热点大V粉丝千万，需高并发写入处理能力
- 关注行为要支持高可用、幂等、最终一致
- 数据要能扩展，支撑长期演化，易于冷热分层
二、你的作答内容回顾与点评
1. 系统建模与核心功能识别
“首先，我先从系统和功能的抽象建模上思考一下这个系统，对于一个用户，最重要的肯定是关注列表，和被关注列表。以及他自己的消息发布时间线系统，他发的消息所有关注者可以接收。他同时可以接收自己所有关注者的消息，按时间排序。大体上功能应该就是这样，读写模型基本属于读多写少。但因为用户数量巨大，并且对于热点用户关注、取关操作可能比较频繁。”
| 模块 | 表现 | 说明 |
|---|---|---|
| 场景分析 | ⭐⭐⭐⭐ | 准确识别出系统中的“关注列表 / 粉丝列表 / 时间线”三大核心场景 |
| 边界控制 | ⭐⭐⭐ | 轻微混入时间线场景，略偏离关注关系的本题主轴 |
| 并发认知 | ⭐⭐⭐⭐ | 正确认识到热点用户可能打破“读多写少”的常规规律 |
2. Redis 缓存设计与冷热区分策略
“数据存储设计需要借助缓存来抗流量，通过异步处理（比如消息）进行数据持久化，关注列表和被关注列表都可以借助 redis set 来快速支持。关注/取关操作就首先对于用户本人的关注 redis set 进行写或删，至于被关注者的被关注列表的变化，取决于是否热度用户或在线用户，是的话可以同批同步操作，否的话同样可以借助消息投递。”
| 模块 | 表现 | 说明 |
|---|---|---|
| 缓存结构设计 | ⭐⭐⭐⭐⭐ | Redis Set 选型非常精准，天然幂等、结构直观 |
| 写入流程设计 | ⭐⭐⭐⭐ | 明确主写自己 Set，写他人视热度判断同步或异步，具备实战经验 |
| 冷热感知 | ⭐⭐⭐⭐ | “在线用户同步、离线异步”逻辑体现细腻，可补充 TTL 控制策略 |
| 一致性意识 | ⭐⭐⭐ | 未明确说明缓存/DB 如何保持最终一致、失败重试机制，可进一步强化 |
3. 数据库模型设计与分片
“我会直接设计一个明细记录…两个字段 follerid, followingid…加 is_active 表示逻辑删除…first_follow_time, last_change_time 分别记录首次/上次关注取关的时间…关注表按 follower_id 分库分表…粉丝表按 following_id 维度做冗余分片。”
| 模块 | 表现 | 说明 |
|---|---|---|
| 数据模型设计 | ⭐⭐⭐⭐⭐ | 明细表 + 冗余表分治合理，活跃关系 +历史关系共存，字段设计全面 |
| 分片策略 | ⭐⭐⭐⭐ | 按 follower_id 和 following_id 分库分表，合理匹配访问路径 |
| 字段表达 | ⭐⭐⭐ | 字段命名有拼写误（follerid），但数据含义、索引规划清晰 |
| 写一致性 | ⭐⭐⭐ | 未说明主表与冗余表是否同步写，建议补充幂等消费、幂等 DB 控制方式 |
4. 查询行为与冷热优化
“最多查询量应该就是已知 follower_id 查 following 列表…普通用户可 Redis 短 TTL 缓存…大V数据必须预热加载…被关注列表数据变化可异步刷缓存…”
| 模块 | 表现 | 说明 |
|---|---|---|
| 访问优先级 | ⭐⭐⭐⭐ | 准确识别“关注列表 > 粉丝列表 > 是否互关”的查询频率顺序 |
| 冷热分层 | ⭐⭐⭐⭐⭐ | 冷用户短 TTL，热用户预热驻留，策略合理成熟 |
| 查询手段 | ⭐⭐⭐⭐ | Redis Set 查询 + DB 回源清晰，建议补充互关查询用 SISMEMBER |
| 查询成本控制 | ⭐⭐⭐ | 粉丝列表分页访问策略未展开，大V粉丝不可全查应强调“只查总数 + 分页接口” |
5. 并发控制与高可用策略
“写热点问题可以考虑成突发事件高并发关注的一种降级式的应对，比如热点事件，导致某人瞬间被大量用户关注…稳妥的做法是降级走消息，后面消费再平稳的更新 redis。”
| 模块 | 表现 | 说明 |
|---|---|---|
| 热点写防护 | ⭐⭐⭐⭐⭐ | MQ 降级、批量刷 Redis、削峰填谷完整具备，体现强工程经验 |
| Redis 抗压能力 | ⭐⭐⭐⭐ | 指出 Redis 扛写能力 10w QPS 的数量级，估算准确 |
| 热点打散 | ⭐⭐⭐ | 未提到 key 分片或逻辑打散（如虚拟 UID 多份 Set），建议补充 |
| 大V处理 | ⭐⭐⭐ | 提及“粉丝列表可不存”，但具体查询方式（是否仅保留粉丝数）未做展开 |
三、最终结构总结（优秀答案融合）
- 数据模型：主表关注列表按
follower_id分库分表，冗余表粉丝列表按following_id维度分片；字段包含is_active,first_follow_time,last_change_time等。 - 缓存策略：Redis Set 存储
follow:{uid}，热用户支持fans:{uid}；互关查询用SISMEMBER，共同关注查SINTER；大V粉丝做分页或分片存储。 - 写入流程：Redis 先写 + Kafka 异步落库，消费端保障幂等、同步写主表+冗余表。
- 扩展策略：MQ 削峰，冷数据懒加载，热用户预热，数据归档支持陈旧关系回收。
- 高级处理：支持打散热点 Set、多副本结构、分页聚合、只计数不存明细等策略。
四、综合评价
| 能力维度 | 表现等级 | 点评 |
|---|---|---|
| 场景建模与目标识别 | ⭐⭐⭐⭐ | 准确识别系统目标，建模合理，覆盖常规及扩展查询 |
| 数据模型设计 | ⭐⭐⭐⭐ | 表结构健全，冗余结构清晰，字段/索引匹配业务访问需求 |
| 缓存结构与使用 | ⭐⭐⭐⭐⭐ | Redis 结构匹配访问路径，冷热策略灵活，应对不同用户活跃度 |
| 写入一致性与幂等机制 | ⭐⭐⭐ | 幂等性意识较好，建议补充异常重试、消息幂等 key 控制、失败监控策略 |
| 高并发与热点处理 | ⭐⭐⭐⭐ | 热点识别清晰，具备降级与异步写设计，可补充热点打散机制 |
| 架构弹性与扩展性 | ⭐⭐⭐⭐ | 有削峰、分片、冷热归档能力，具备服务长周期可维护能力 |
综合评价：本题高分通过，达资深后端工程师水准，答题完整，结构清晰，兼具实战落地与架构演化意识。