RoadMap：系统设计（资深后端开发岗位）
说明：高级/资深服务端开发，重点掌握系统设计逻辑与典型场景拆解，不深入运维与SRE方向。
鉴于我近4年的工作经验以及最近准备面试过程中对系统设计的认识，得出的感悟是目前的大多数C端分布式在线系统业务解决方案无非就那么几点：
横向分片、纵向分层、缓存抗量、异步解耦、异步一致、异步补偿。概括起来就是三板斧和一句话：
三是 分治 缓存 异步化
一是 Redis 是爹
🧠 第一部分：系统设计核心思维与基础构建
| 模块 | 关键词 | 要求 |
|---|
| 设计目标理解 | 可扩展性、可用性、一致性、成本、性能 | 能识别 trade-off 并据此做决策 |
| 系统容量预估 | QPS、流量峰值、数据量估算 | 掌握估算公式、缓存/数据库选型策略 |
| 架构风格选择 | 单体 vs 微服务、分层架构、异步解耦 | 熟悉常见架构图与模块职责 |
| 核心组件职责 | Web 层、服务层、缓存、DB、消息队列 | 用例驱动，清楚组件选型原因 |
🚀 第二部分：高频系统设计场景拆解（核心复习重点）
每题都需掌握：关键问题 + 架构图 + 模块设计 + 扩展优化
| 场景 | 建议掌握内容 |
|---|
| 🔗 短链系统 | 哈希冲突、反向解析、读多写少、热点缓存 |
| 🔥 秒杀系统 | 限流策略、库存一致性、削峰填谷、幂等设计 |
| 📩 IM系统 | 长连接、消息顺序、离线消息、消息存储 |
| 🧵 Feed流系统 | 拉/推模型、个性化排序、热点数据策略 |
| 📸 图片/视频上传 | CDN分发、断点续传、Hash 去重、鉴黄 |
| 🛒 电商购物车 | 登录/未登录合并、Redis存储、过期策略 |
| 🔍 搜索建议 | Trie前缀匹配、缓存淘汰、QPS处理优化 |
| 📊 投票/打分系统 | 防刷机制、Redis去重计数、幂等设计 |
| 📅 延时任务/提醒系统 | 延迟队列、幂等任务、时间精度设计 |
| 📚 文档协作系统 | 实时同步、版本冲突、CRDT/OT概念 |
🔍 第三部分：专题挑战训练（拉升上限）
| 专题 | 建议内容 |
|---|
| 分库分表设计 | 分片键、数据迁移方案、热点分片问题 |
| 缓存架构与一致性 | 穿透/雪崩、失效策略、缓存一致性方案 |
| 分布式ID生成 | Snowflake、美团Leaf、全局唯一性方案 |
| 分布式事务设计 | TCC、SAGA、最终一致性、幂等重试 |
| API 限流与熔断 | 滑动窗口、令牌桶、漏桶、熔断器原理 |
| 多级缓存策略 | 本地缓存+Redis+CDN、预热、淘汰 |
| 服务拆分原则 | 微服务边界识别、粒度、幂等与回滚 |
🎯 第四部分：大厂真题实战演练（可逆推架构）
| 公司 | 常见题目 |
|---|
| 字节跳动 | 抖音Feed流、短链、直播弹幕、在线文档 |
| 阿里巴巴 | 秒杀、购物车、商品搜索、优惠券系统 |
| 腾讯 | IM系统、游戏后端架构、缓存一致性方案 |
| Google | 搜索建议、全局ID、文件同步系统 |
| Amazon | 推荐系统、购物车、库存一致性 |
| Microsoft | Outlook邮件、OneNote协作、身份验证 |
- 刷题顺序推荐：短链 → 秒杀 → Feed流 → IM → 上传系统 → 日志系统
一、系统架构
1. 微服务与单体
| 场景 | 推荐架构 | 理由 |
|---|
| MVP 阶段、小团队、快速验证 | 单体 | 快速上线、低成本迭代 |
| 模块职责明确，团队人数较多 | 微服务 | 按领域拆分、并行开发 |
| 高频写操作 + 高并发 | 微服务 | 水平扩展、隔离瓶颈 |
| 部分模块需独立扩缩容（如推荐、搜索） | 微服务 | 提高资源利用率 |
面试官可能问什么？
| 提问点 | 应对策略 |
|---|
| 为什么你们系统采用了微服务？ | 结合业务规模、团队分工、模块解耦说明好处，并提及面临的挑战（如服务治理） |
| 如何做系统拆分？ | 按业务边界（如订单、用户、支付），避免频繁跨服务调用，保持领域聚合 |
| 你如何避免微服务间依赖地狱？ | 使用 API 网关统一入口、制定接口规范、引入服务注册与监控工具 |
| 单体架构什么时候更合适？ | 表示你了解 trade-off，比如初创阶段优先交付、成本敏感项目 |
| 微服务如何部署测试？ | 提及容器化（Docker）、CI/CD、灰度发布、集成测试手段 |
2. 容器化与Docker
- 容器的本质：轻量级、可移植的运行环境，解决“本地能跑，上线崩了”的老问题。
Docker把服务容器化，每次提交代码后由CI自动构建镜像，然后上线环境直接拉镜像运行，保证开发和生产环境一致交付。
| 术语 | 说明 |
|---|
| 容器（Container） | 独立的进程空间，资源隔离，启动快 |
| 镜像（Image） | 打包代码 + 依赖 + 环境的只读模板 |
| Dockerfile | 用于构建镜像的脚本配置 |
3. 云原生理念与Service Mesh
- “云原生”不是技术，是一套做系统的方式，或者说是构建系统的理念。
- 用
微服务 + 容器 + 自动化工具链，让服务部署、扩容、回滚都像云上水龙头一样开关自如。
云原生五要素
| 要素 | 举例 |
|---|
| 微服务化 | 功能拆成独立服务，便于分工 |
| 容器化部署 | Docker / K8s |
| 弹性伸缩 | 根据流量自动扩容 |
| 持续交付（CI/CD） | GitHub Actions / Jenkins |
| 可观测性 | Prometheus、Grafana、链路追踪 |
Service Mesh：让开发更专注业务
- 典型架构：Sidecar（如 Envoy）+ 控制面（如 Istio）
- Service Mesh 是微服务架构的通信“管家”，开发者不需要写网关、熔断、限流、全链路监控等逻辑，全都交给“边车代理”搞定。
| 基本能力 | 帮你做的事 |
|---|
| 服务发现 | 自动找到服务地址 |
| 负载均衡 | 自动分发请求 |
| 熔断/限流 | 不写代码也能配置 |
| 安全通信 | mTLS 加密 |
| 链路追踪 | 每个请求走过哪都能看到 |
4. 系统设计核心思想 & 容量预估（资深开发版）
🎯 一、系统设计的五大核心目标
| 设计目标 | 说明 | 常见技术实践 |
|---|
| 可扩展性 Scalability | 随业务增长平滑扩容 | 分布式、分片、无状态服务、MQ、Cache、CDN |
| 可用性 Availability | 系统服务不中断 | 主备容灾、重试机制、限流熔断、健康检查 |
| 一致性 Consistency | 数据状态准确可靠 | CAP权衡、幂等设计、分布式事务、版本控制 |
| 性能 Performance | 响应快、延迟低 | Cache、异步化、读写分离、并行计算 |
| 成本 Cost | 性能之外的性价比 | 资源隔离、冷热分级、Spot实例、调度优化 |
📌 设计目标往往冲突，必须结合业务特性进行取舍（下节详述）。
🧭 二、设计目标间的典型 Trade-off 策略
| 冲突方向 | 场景/解释 | 应对策略 |
|---|
| 一致性 vs 可用性 | 分布式数据库断网时写入处理？ | 强一致场景用 Paxos/Raft，普通业务可 eventual consistency |
| 性能 vs 成本 | 高并发写入是否需要全链路强一致？ | 高频写转为异步落盘、批处理合并 I/O |
| 可扩展性 vs 一致性 | 多副本写入存在同步滞后？ | 弱一致架构 + 写入确认策略（如 quorum） |
| 可用性 vs 数据完整性 | 容灾切换是否允许部分数据丢失？ | 引入幂等重试、最终补偿机制 |
| 性能 vs 可维护性 | 极限性能调优引入复杂异步流程 | 用中间件封装、划分 SLA 层级 |
📐 三、容量预估
流量模型、峰值/日均QPS、RT、CPU/内存、带宽有无特殊关注点、DB表数据增长、读写模型、TPS并发情况、DB查询情况（是否有较慢查询、查询索引命中如何）、Redis缓存容量、本地缓存容量
5. 傻逼问题汇总
a.问题本身不傻逼，但是大傻逼们很喜欢问，故归为傻逼问题，如：
CAP理论，有些大傻逼并没有那么高的学术造诣，也设计不出合适的提问场景，上来就让你说CAP理论，这种人我把P替换成O，称他们叫CAO大傻逼。
还是说说吧，
b.问题本身就比较傻逼，但是有些人比较特儿，就是喜欢问，如：