Question 1

设计一个短链服务（如 t.cn），要求每天生成 1 亿条短链。

Accepted Answer

我先澄清两个约束：短链是否允许过期回收、要不要点击统计——假设需要统计且默认不过期（澄清）。估算：每天 1 亿条写入约 1200 QPS，峰值按 3 倍算 4000；读写比取 100:1，读峰值约 40 万 QPS，明显是读密集系统。存储上每条记录约 500 字节，一年 36TB，需要分片（估算）。高层设计：写路径走发号器服务——用号段模式，每台发号器从数据库批量领取一段号码区间在内存中递增发放，62 进制编码成 7 位短码，无冲突且数据库压力极小；映射关系按短码哈希分 64 个库存储（架构）。读路径是重点：短链访问极度头部化，我加两级缓存——网关本地 LRU 缓存扛最热的 1%，Redis 集群扛长尾，缓存不命中才回源数据库，预计回源率低于 1%；跳转返回 302 而不是 301，浏览器就不会本地缓存跳转，每次点击都经过服务端，统计事件异步写入消息队列再入分析库，不阻塞跳转（深入）。容错上发号器区间预取双 buffer，数据库抖动不影响发号；Redis 挂掉时本地缓存加数据库限流兜底。总结取舍：号段方案牺牲了短码的不可预测性换取零冲突和横向扩展，如果业务要求防遍历，可以在号段发放后叠加一层可逆混淆（权衡收尾）。

Question 2

设计一个秒杀系统：10 万件库存，预计 1000 万人抢购。

Accepted Answer

秒杀的本质是 1000 万请求里只有 10 万个能成功，系统要做的是把 99% 的流量在越靠前、越便宜的层挡掉（定性）。估算：开抢瞬间假设 500 万人同时点击，峰值请求几十万 QPS，但真正需要走完下单链路的只有 10 万（估算）。我分四层削峰：第一层客户端——开抢前按钮置灰、开抢后本地随机延迟加答题验证，把机器流量和瞬时尖峰摊开；第二层 CDN——商品页全静态化，动态的只有一个「是否开抢」的小接口；第三层网关——按用户维度限流去重，一人多次点击只放行一次；第四层服务——通过消息队列异步下单，队列长度超过库存量的 3 倍就直接快速失败返回「已抢完」（架构）。库存是核心难点：我把 10 万库存预热进 Redis，扣减用 Lua 脚本保证「读-判断-减」原子执行，杜绝超卖；扣减成功的请求才进订单队列，消费者落库创建订单并锁定 15 分钟支付时限，超时未支付由延迟任务回补 Redis 库存（深入）。一致性兜底：Redis 扣减和订单落库之间有窗口，用对账任务每分钟核对已扣库存与有效订单数，差异自动回补；Redis 挂掉时降级为数据库行级扣减加排队，牺牲吞吐保正确性（容错）。总结：这套设计用最终一致换高吞吐，库存准确性靠原子扣减+对账双保险（权衡收尾）。

Question 3

设计一个信息流（Feed）系统，比如微博首页时间线。

Accepted Answer

我先确认规模假设：1 亿日活、平均关注 300 人、每天 1 亿条新帖，大 V 粉丝可达 5000 万（澄清与估算）。纯推模式下大 V 发一条帖要写 5000 万个收件箱，写放大不可接受；纯拉模式下每次刷新要实时聚合 300 个人的最新帖，读延迟和扇出都太大。所以用推拉结合：粉丝数 10 万以下的用户走推——发帖后异步任务把帖子 ID 写入所有在线粉丝的 Redis 收件箱（有序集合按时间排序，只保留最近 800 条）；粉丝数超过阈值的大 V 走拉——用户刷新时实时查询自己关注的大 V 列表的最新帖子（架构）。读路径：刷新时先取自己的收件箱 ID 列表，再拉取关注的大 V 近期帖子 ID，两路按时间戳归并后批量查正文缓存，一次刷新控制在 3 次批量调用内（深入）。几个细节：不活跃用户（30 天未登录）不推送，回归时降级为拉，收件箱懒重建，能省一半以上写扩散；删帖用软删除，读取时过滤，避免反向扇出清理；正文缓存热点帖用多副本抗读（容错与优化）。总结取舍：推拉结合以读路径多一次归并的代价，同时避开了写扩散爆炸和读扇出爆炸，阈值本身要根据线上写放大监控动态调整（权衡收尾）。

Question 4

设计一个即时通讯（IM）系统，支持单聊和群聊。

Accepted Answer

先定指标：假设 5000 万日活，单机长连接 10 万，需要约 500 台接入网关；消息要求不丢、不重、会话内有序，端到端 P95 延迟 200ms 内（澄清与估算）。架构分三层：接入层是 WebSocket 网关，只管连接保活和消息透传，不存业务状态，用户连接到哪台网关记录在 Redis 路由表；逻辑层做鉴权、序列号分配、会话管理；存储层消息先写入消息队列削峰，再落消息库（按会话 ID 分片）（架构）。可靠性是核心：发送方每条消息带客户端生成的唯一 ID，服务端持久化成功后才返回 ACK，发送方 5 秒未收到 ACK 就重发，服务端按唯一 ID 去重——这样丢包只会导致重试而不会丢消息或重复入库；顺序用会话级序列号，逻辑层为每个会话维护单调递增 seq，接收端按 seq 排序并检测空洞，发现缺号就拉取补齐（深入）。在线消息经路由表找到对端网关直接推送；离线消息写入收件箱，上线后按 seq 增量同步。群聊按规模分流：500 人以下小群写扩散，每个成员收件箱各写一条，读取快；万人大群写一份群信箱，成员按自己的已读 seq 拉增量，避免写放大（分场景）。容错：网关宕机客户端自动重连到其他节点，路由表更新；消息库分片故障时队列堆积缓冲，恢复后重放。总结：这套设计用「持久化后 ACK + 去重 ID + 会话 seq」三件套换可靠性，代价是每条消息多一次往返确认，对 IM 这是值得的（权衡收尾）。

Question 5

如何为一个新系统做容量估算？现场估一下：设计一个图片分享 App 的存储和带宽。

Accepted Answer

我的估算套路是四步：列假设、写算式、取数量级、落规格——过程全部说出来，假设错了面试官会当场纠正，这比闷头算更重要（方法）。现场估图片分享 App：假设 5000 万日活，10% 的人每天发 2 张图，人均每天浏览 50 张；照片压缩后平均 500KB，同时存一份 50KB 缩略图（假设）。写入：500 万人 × 2 张 = 1000 万张/天，除以 10^5 秒即约 100 张/秒，峰值 3 倍 300 张/秒；上行带宽 300 × 500KB ≈ 150MB/s，约 1.2Gbps（写路径）。读取：5000 万 × 50 张 = 25 亿次/天 ≈ 2.5 万 QPS，峰值 8 万；大部分浏览走缩略图，下行带宽按 70% 缩略图 30% 原图算约 8 万 × (0.7×50KB + 0.3×500KB) ≈ 15GB/s——这个量级说明必须上 CDN，源站只承担缓存不命中的 5% 即 750MB/s（读路径）。存储：每天 1000 万 × 550KB ≈ 5.5TB 增量，一年 2PB，三副本 6PB；元数据每张 1KB，一年才 3.6TB，单独放数据库绰绰有余（存储）。结论：这是典型读密集+CDN 密集系统，成本大头在下行流量和对象存储，架构重心应放在多级缓存和冷热分层——超过 90 天的图片转低频存储可以省一半成本（落到决策）。

Question 6

单库扛不住了，数据库怎么扩展？分库分表要注意什么？

Accepted Answer

我会按演进顺序回答，因为每一步的复杂度和风险差一个量级，能不分片就不分片（框架）。第一步先确认瓶颈：慢查询日志和执行计划看是不是缺索引、有没有全表扫描——多数「数据库扛不住」在这一步就能解决。第二步读写分离：如果读占 80% 以上，加只读副本把读流量分走，代价是主从延迟，对一致性敏感的读（如刚下单后查订单）强制走主库。第三步垂直拆分：按业务域把订单、用户、商品拆到独立库，顺带解耦故障域。第四步才是水平分片（演进）。分片的核心决策是分片键：以订单库为例，按用户 ID 分片，用户查自己的订单单分片就能完成——这是主访问路径；代价是商家维度查询要广播所有分片，所以给商家侧另建一份按商家 ID 组织的异构索引表，用 binlog 同步（深入）。要提前想好的坑：一是扩容，我会预分 1024 个逻辑分片映射到 8 个物理库，扩容时只迁移逻辑分片映射，不做全量重哈希；二是全局唯一 ID，用雪花算法替代自增主键；三是跨分片事务，能用「本地事务+异步补偿」就不用分布式事务，对账兜底（避坑）。总结：分片换来的是写扩展性，付出的是查询灵活性和事务能力，所以它是最后一步而不是第一步（权衡收尾）。

Question 7

缓存与数据库的一致性怎么保证？缓存穿透、击穿、雪崩分别怎么防？

Accepted Answer

先定基调：缓存加数据库是两个存储，强一致做不到也不该做，目标是「短暂不一致可接受、最终一致有保障」（定性）。更新策略我选 Cache-Aside + 删缓存：写请求先更新数据库再删除缓存键，读请求未命中时回源数据库并回填。为什么是删不是改——并发写时「改缓存」可能把旧值写在新值后面，而「删」最多导致一次多余回源，错误代价不对称（选型理由）。删缓存失败会留下旧数据，所以删除动作进本地重试队列，三次失败后发告警；对一致性要求更高的场景订阅数据库 binlog 异步再删一次，把不一致窗口压到百毫秒级（兜底）。三个异常场景分开防：穿透是查询根本不存在的数据，缓存永远不命中——对已知键空间用布隆过滤器在缓存前拦截，攻击性的随机键查询直接挡掉，配合对确认不存在的键缓存空值 60 秒；击穿是某个热键过期瞬间大量请求同时回源——用互斥锁保证只有一个请求回源重建，其他请求短暂等待或返回旧值，核心热键干脆用逻辑过期永不真删；雪崩是大批键同一时刻失效或缓存集群宕机——过期时间统一加 10% 随机抖动错峰，集群层面开多副本，极端情况下入口限流保数据库不被打穿（三防）。总结：一致性靠「先库后删+重试+binlog」三层递进，可用性靠三个场景各自的针对性防御，这套组合是读多写少业务的标准配置（收尾）。

Question 8

设计一个限流器（Rate Limiter），并说说系统整体的高可用怎么做。

Accepted Answer

限流器先明确需求：按用户和接口两个维度限流，规则如「单用户对下单接口每秒最多 10 次」，集群全局生效，限流器本身不能成为新的故障点（澄清）。算法选型讲取舍：固定窗口计数最简单，但窗口边界可能放过两倍流量；滑动窗口日志精确但每请求存时间戳，内存贵；漏桶输出恒速适合保护下游但不允许突发；令牌桶按速率补充令牌、桶容量允许可控突发，最贴近真实流量特征——我选令牌桶（选型）。分布式实现：令牌桶状态存 Redis，取令牌用 Lua 脚本把「读桶-补令牌-扣减」原子化，避免竞态；每个网关节点本地再做一层粗粒度兜底限流，Redis 不可用时自动切换到本地模式，按节点数均摊配额——宁可短暂放过一些流量，也不能因为限流器挂了拒绝所有请求（实现与容错）。被限的请求返回 429 加 Retry-After 头，客户端按提示退避（细节）。高可用我用四层方法论收拢：冗余——接入层多节点、数据层多副本多可用区，消灭单点；隔离——按业务线拆线程池和连接池，故障爆炸半径控制在单业务；降级——预先定义非核心功能的降级开关，大促时关闭推荐保下单；防雪崩——就是刚才的限流加熔断，下游错误率超阈值自动熔断快速失败（方法论）。最后强调一点：这些机制必须靠混沌演练验证，没演练过的高可用只是文档上的高可用（收尾）。

系统设计面试高频题：8 道必考题与作答要点