系统设计 012从用户系统出发吃透缓存、数据库与高并发设计Bilibili 同步视频一、用户系统藏着后端设计的核心考点二、4S 分析法先读懂用户系统的流量挑战1. Scenario四大需求查询为王2. 流量估算亿级 DAU 的 QPS 压力3. Service职责拆分让系统更清晰三、QPS 决定选型数据库与缓存的性能边界⚡四、用户系统存储选型对症下药高效支撑✅五、延伸思考从用户系统到面试实战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职责拆分让系统更清晰按照单一职责原则用户系统可拆分为三大服务User Service用户信息增删改查 → 核心数据载体Authentication Service登录态管理 → 实现 “一次登录、长期有效”Friendship Service好友关系存储与查询 → 社交场景必备三、QPS 决定选型数据库与缓存的性能边界⚡为什么要精准估算 QPS因为流量量级直接决定存储方案。不同存储组件的性能天花板是系统设计的核心依据。存储类型代表组件QPS 支撑量级核心特点关系型数据库MySQL/PostgreSQL百千级功能强、事务完善、结构复杂硬盘型 NoSQLMongoDB/Cassandra1K~10K 级结构简单、读写更快、灵活扩展内存型 NoSQLRedis/Memcached10 万级 全内存操作、极致性能、高并发首选简单总结越简单的存储跑得越快越强大的数据库 overhead 越高。四、用户系统存储选型对症下药高效支撑✅结合前面的 QPS 数据我们可以直接给出最优解注册 / 登录 / 信息修改QPS≈300完全可以用MySQL/PostgreSQL支撑稳定、可靠、满足事务需求。用户信息查询QPS≈30 万单机 MySQL/PostgreSQL完全扛不住必须引入Redis 等内存缓存做查询层的流量削峰与加速。这就是缓存与数据库最经典的配合逻辑写请求走数据库高并发读请求走缓存。五、延伸思考从用户系统到面试实战吃透用户系统等于掌握了系统设计的通用方法论先定场景与流量再拆服务最后选存储NoSQL 不是 SQL 的替代品而是场景互补Cassandra 这类分布式 NoSQL更适合高写入、高吞吐、弱事务的场景亿级用户系统的核心缓存架构 分库分表 服务拆分后续我们会深入Cassandra 实战、缓存一致性、登录态实现、好友关系存储方案以及大厂系统设计真题解析把用户系统的每一个技术细节彻底讲透。
