系统设计 012：从用户系统出发，吃透缓存、数据库与高并发设计

Bilibili 同步视频

系统设计 012：从用户系统出发，吃透缓存、数据库与高并发设计

在后端开发与系统设计的学习路径中，用户系统是最经典、最贴近实战的切入点📌。它不仅串联起注册、登录、信息管理、好友关系等核心业务场景，更能帮我们真正理解缓存是什么、缓存与数据库如何协同、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：职责拆分，让系统更清晰🧩

按照单一职责原则，用户系统可拆分为三大服务：

1. User Service：用户信息增删改查 → 核心数据载体

2. Authentication Service：登录态管理 → 实现 “一次登录、长期有效”

3. Friendship Service：好友关系存储与查询 → 社交场景必备

三、QPS 决定选型：数据库与缓存的性能边界⚡

为什么要精准估算 QPS？因为流量量级直接决定存储方案。不同存储组件的性能天花板，是系统设计的核心依据。

简单总结：越简单的存储，跑得越快；越强大的数据库， overhead 越高。

四、用户系统存储选型：对症下药，高效支撑✅

结合前面的 QPS 数据，我们可以直接给出最优解：

1. 注册 / 登录 / 信息修改（QPS≈300）
   完全可以用MySQL/PostgreSQL支撑，稳定、可靠、满足事务需求。

2. 用户信息查询（QPS≈30 万）
   单机 MySQL/PostgreSQL完全扛不住！必须引入Redis 等内存缓存，做查询层的流量削峰与加速。

这就是缓存与数据库最经典的配合逻辑：写请求走数据库，高并发读请求走缓存。

五、延伸思考：从用户系统到面试实战🎯

吃透用户系统，等于掌握了系统设计的通用方法论：

• 先定场景与流量，再拆服务，最后选存储

• NoSQL 不是 SQL 的替代品，而是场景互补

• Cassandra 这类分布式 NoSQL，更适合高写入、高吞吐、弱事务的场景

• 亿级用户系统的核心：缓存架构 + 分库分表 + 服务拆分
  

后续我们会深入：Cassandra 实战、缓存一致性、登录态实现、好友关系存储方案，以及大厂系统设计真题解析，把用户系统的每一个技术细节彻底讲透🔧。