脸书后端工程师面试题及答案.docxVIP

第PAGE页共NUMPAGES页

2026年脸书后端工程师面试题及答案

一、系统设计题（共3题，每题20分）

1.设计一个高效的短链接系统（如tinyURL）

要求：

-支持高并发访问（QPS10万）。

-短链接生成全局唯一且不可逆。

-支持链路快速跳转（HTTP301重定向）。

-系统需考虑成本优化（如使用Redis缓存热点数据）。

答案与解析：

方案设计：

1.短链接生成：

-使用自增ID或UUID生成全局唯一标识。

-结合base62编码（a-z、A-Z、0-9）将ID压缩为6-7位短码（如`abc123`）。

-前缀可选区域码（如`cn-`）区分地域，降低ID冲突。

2.数据存储：

-主库使用Redis（单机或集群）缓存热点链路，降低数据库压力。

-MySQL/PostgreSQL存储完整数据（长链接、短链接、创建时间、点击量等）。

-索引优化：`short_code`和`long_url`字段建立联合索引。

3.高并发处理：

-使用Nginx/HAProxy做负载均衡，分摊请求压力。

-短链接请求先走缓存，未命中时查询数据库并更新缓存。

4.安全与防刷：

-限制单IP/短时间点击频率。

-长链接访问时验证短链接有效性（如过期检查）。

解析：

-为什么用Redis？Redis内存存储响应速度快，适合高频访问场景。

-base62编码？比base64更节省空间（去掉大小写字母重叠），如`/abc123`。

-高并发优化？缓存+数据库分片+负载均衡是标配。

2.设计一个实时新闻推荐系统（类似FacebookNewsFeed）

要求：

-支持用户动态（文字、图片、视频）的发布与展示。

-推荐算法需考虑用户兴趣、社交关系、内容热度。

-系统需支持离线计算与实时更新结合。

答案与解析：

方案设计：

1.数据模型：

-用户表（`users`）：`user_id`、`follows`（关注列表）、`interests`（标签）。

-动态表（`posts`）：`post_id`、`user_id`、`content`（文本/多媒体）、`timestamp`。

-互动表（`interactions`）：`user_id`、`post_id`、`type`（点赞/评论/分享）。

2.推荐算法：

-协同过滤：根据相似用户行为（如点赞相似动态）推荐。

-内容召回：用户兴趣标签与动态标签匹配。

-实时排序：结合LDA（主题模型）对文本动态打分。

3.系统架构：

-离线计算：Hadoop/Spark每日计算用户画像，存储至HBase/Redis。

-实时更新：Kafka收集用户行为，Flink/Storm实时更新推荐权重。

-排序服务：使用Lambda架构（批处理+流处理）保证实时性。

4.性能优化：

-使用Trie树缓存热门标签，加速内容匹配。

-动态分片存储，按用户ID或时间范围分区。

解析：

-为什么用Lambda架构？批处理保证准确度，流处理提升实时性。

-推荐算法怎么平衡冷启动？新用户优先推荐热门内容，逐步收集行为数据。

3.设计一个分布式计数器服务（如RedisCluster实现）

要求：

-支持毫秒级高并发计数（如活动抢购）。

-兼容分布式环境，解决数据一致性问题。

-考虑幂等性设计（防止重复点击）。

答案与解析：

方案设计：

1.RedisCluster方案：

-使用`INCR`命令实现原子计数。

-节点分片规则：根据计数器ID哈希到不同槽位。

-主从复制+哨兵机制保证可用性。

2.幂等性设计：

-使用`SETNX`（SETifNoteXists）锁住计数器，避免重复操作。

-用户请求时生成UUID，存入Redis（过期删除），验证唯一性。

3.扩展性：

-按业务线分片（如`counter:product:123`），避免跨场景冲突。

-使用Lua脚本在Redis原子化执行计数+验证逻辑。

解析：

-为什么用RedisCluster？分片后单节点压力降低，支持百万级QPS。

-Lua脚本？避免网络往返延迟，提升性能。

二、数据库与存储题（共3题，每题15分）

4.如何优化MySQL的慢查询问题？

要求：

-列举3种常见的慢查询场景及解决方案。

-解释索引失效的典型原因。

答案与解析：

慢查询场景及优化：

1.全表扫描：

-原因：未使用索引，WHERE条件无效。

-解决：添加索引（如`id`、`timestamp`常用字段）。

-验证：`EXPLAIN`命令查看`type`是否为`ALL`。

2.索引失效：

-原因：

-范围查询（