系统设计 012：从用户系统出发，吃透缓存、数据库与高并发设计
- [Bilibili 同步视频](#Bilibili 同步视频)
- 一、用户系统，藏着后端设计的核心考点💡
- [二、4S 分析法：先读懂用户系统的流量挑战📊](#二、4S 分析法：先读懂用户系统的流量挑战📊)
-
- [1. Scenario：四大需求，查询为王🔥](#1. Scenario：四大需求，查询为王🔥)
- [2. 流量估算：亿级 DAU 的 QPS 压力💥](#2. 流量估算：亿级 DAU 的 QPS 压力💥)
- [3. Service：职责拆分，让系统更清晰🧩](#3. Service：职责拆分，让系统更清晰🧩)
- [三、QPS 决定选型：数据库与缓存的性能边界⚡](#三、QPS 决定选型：数据库与缓存的性能边界⚡)
- 四、用户系统存储选型：对症下药，高效支撑✅
- 五、延伸思考：从用户系统到面试实战🎯
Bilibili 同步视频
在后端开发与系统设计的学习路径中，用户系统 是最经典、最贴近实战的切入点📌。它不仅串联起注册、登录、信息管理、好友关系等核心业务场景，更能帮我们真正理解缓存是什么、缓存与数据库如何协同、SQL 与 NoSQL 怎么选、高并发 QPS 如何承载等关键问题。今天，我们就以用户系统为锚点，拆解这套从基础到实战的技术逻辑🚀。
一、用户系统，藏着后端设计的核心考点💡
一个完整的用户系统，绝非简单的信息存储，它覆盖了后端面试与工程实践的高频考点：
-
缓存的本质与工作机制🔍
-
缓存 + 数据库的经典协作模式
-
登录态的实现逻辑与持久化方案
-
好友关系的存储、查询与优化
-
关系型数据库 (SQL) vs 非关系型数据库 (NoSQL) 的场景边界
-
以 Cassandra 为代表的 NoSQL 实战用法
-
大厂系统设计面试真题：亿级用户系统设计思路
这些问题看似分散，却能通过用户系统这一条主线完全打通，成为后端工程师必须筑牢的底层能力🧱。
二、4S 分析法：先读懂用户系统的流量挑战📊
做系统设计，第一步永远是看清场景、算清流量。我们用 4S 分析法，快速定位用户系统的核心压力点。
1. Scenario：四大需求，查询为王🔥
用户系统的核心操作：注册、登录、信息查询、信息修改 。
从真实使用场景看：
-
注册：低频行为，不会每日重复
-
登录：多为持久化态，手动输入账号密码频次极低
-
信息修改：昵称、头像等更新频率极低
-
信息查询：最高频！ 自查询、好友查看、会话展示等，都会触发查询
2. 流量估算：亿级 DAU 的 QPS 压力💥
假设支撑1 亿日活跃用户 (DAU)：
-
注册 / 登录 / 信息修改：每 10 天 1 次，日均 0.1 次 / 人
-
平均 QPS ≈ 100
-
峰值 QPS ≈ 300
-
-
用户信息查询：人均每日 100 次（含他人查询）
- 峰值 QPS ≈ 30 万（300K）
这组数据直接决定：查询是用户系统的最大瓶颈。
3. Service：职责拆分，让系统更清晰🧩
按照单一职责原则，用户系统可拆分为三大服务：
-
User Service：用户信息增删改查 → 核心数据载体
-
Authentication Service：登录态管理 → 实现 "一次登录、长期有效"
-
Friendship Service：好友关系存储与查询 → 社交场景必备
三、QPS 决定选型：数据库与缓存的性能边界⚡
为什么要精准估算 QPS？因为流量量级直接决定存储方案。不同存储组件的性能天花板，是系统设计的核心依据。
| 存储类型 | 代表组件 | QPS 支撑量级 | 核心特点 |
|---|---|---|---|
| 关系型数据库 | MySQL/PostgreSQL | 百～千级 | 功能强、事务完善、结构复杂 |
| 硬盘型 NoSQL | MongoDB/Cassandra | 1K~10K 级 | 结构简单、读写更快、灵活扩展 |
| 内存型 NoSQL | Redis/Memcached | 10 万级 + | 全内存操作、极致性能、高并发首选 |
简单总结：越简单的存储，跑得越快；越强大的数据库， overhead 越高。
四、用户系统存储选型：对症下药，高效支撑✅
结合前面的 QPS 数据，我们可以直接给出最优解：
-
注册 / 登录 / 信息修改（QPS≈300）
完全可以用MySQL/PostgreSQL支撑，稳定、可靠、满足事务需求。
-
用户信息查询（QPS≈30 万）
单机 MySQL/PostgreSQL完全扛不住 ！必须引入Redis 等内存缓存，做查询层的流量削峰与加速。
这就是缓存与数据库最经典的配合逻辑：写请求走数据库，高并发读请求走缓存。
五、延伸思考：从用户系统到面试实战🎯
吃透用户系统，等于掌握了系统设计的通用方法论：
-
先定场景与流量，再拆服务，最后选存储
-
NoSQL 不是 SQL 的替代品，而是场景互补
-
Cassandra 这类分布式 NoSQL，更适合高写入、高吞吐、弱事务的场景
-
亿级用户系统的核心：缓存架构 + 分库分表 + 服务拆分
后续我们会深入：Cassandra 实战、缓存一致性、登录态实现、好友关系存储方案，以及大厂系统设计真题解析，把用户系统的每一个技术细节彻底讲透🔧。