项目面试指南

项目面试指南

一、项目介绍

1.1 STAR 法则

1.2 项目介绍模板

1. 项目背景（1-2句）
   - 业务场景、用户规模

2. 技术架构（重点）
   - 整体架构图
   - 核心技术栈

3. 你的职责
   - 负责的模块
   - 解决的核心问题

4. 技术亮点
   - 性能优化
   - 架构设计

5. 项目成果
   - 量化指标

1.3 架构图讲解技巧

这是我们订单系统的整体架构：

1. 接入层：Nginx 做负载均衡，网关负责鉴权和限流
2. 服务层：采用微服务架构，订单、库存、支付独立部署
3. 中间件：Redis 做缓存，Kafka 做异步解耦
4. 数据层：MySQL 分库分表，ES 做订单搜索

我主要负责订单服务，核心解决了高并发下的库存超卖问题...

1.4 项目亮点/创新点

1.5 收获与反思

技术收获：
- 深入理解了 XXX 技术原理
- 掌握了 XXX 问题的解决方案

业务收获：
- 理解了 XXX 业务场景
- 学会了如何平衡技术和业务

反思改进：
- 如果重新做，会在 XXX 方面做得更好
- 发现了 XXX 问题，后续可以优化

1.6 技术方案评审要点

1. 方案背景和目标
2. 技术选型和对比
3. 详细设计（架构图、时序图、数据模型）
4. 风险评估和应对
5. 里程碑和排期

1.7 技术选型理由

二、系统设计原则

2.1 高可用设计

可用性 = MTBF / (MTBF + MTTR)
99.9% = 8.76 小时/年 停机
99.99% = 52.6 分钟/年 停机

2.2 高并发设计

2.3 容量评估

日活用户：100 万
日均请求：1000 万
峰值 QPS = 日均 QPS × 峰值系数
        = (1000万 / 86400) × 10
        ≈ 1157 × 10 = 11570 QPS

单机 QPS：1000
需要机器：12 台（预留 buffer）

2.4 可扩展性设计

2.5 一致性设计

三、微服务

3.1 服务拆分原则

3.2 服务注册与发现

服务启动 → 注册到注册中心（Nacos/Consul）
         ↓
调用方从注册中心获取服务列表
         ↓
负载均衡选择实例调用

3.3 API 网关

3.4 配置中心设计

3.5 服务间通信

3.6 服务版本管理

四、消息队列

4.1 使用场景

4.2 消息可靠性

1. 确认机制（acks=all）
2. 重试机制
3. 本地消息表

1. 持久化
2. 副本机制

1. 手动确认
2. 幂等处理

4.3 消息顺序性

producer.send(new ProducerRecord<>(topic, orderId, message));

4.4 消息积压处理

1. 临时扩容消费者

2. 跳过非关键消息

3. 转存后离线处理

4.5 Kafka 高性能原理

4.6 消息幂等性

def consume(message):
    msg_id = message.id
    # Redis 去重
    if not redis.setnx(f"msg:{msg_id}", 1, ex=86400):
        return  # 已处理

    # 处理业务逻辑
    process(message)

4.7 延迟消息实现

# Redis ZSet 实现
def delay_message(msg, delay_seconds):
    execute_time = time.time() + delay_seconds
    redis.zadd("delay_queue", {msg: execute_time})

# 消费者轮询
while True:
    now = time.time()
    messages = redis.zrangebyscore("delay_queue", 0, now)
    for msg in messages:
        process(msg)
        redis.zrem("delay_queue", msg)

4.8 Kafka vs RabbitMQ vs RocketMQ

五、分布式

5.1 CAP 理论

5.2 BASE 理论

5.3 分布式事务

Try：预留资源（冻结库存）
Confirm：确认执行（扣减库存）
Cancel：取消释放（解冻库存）

5.4 分布式锁

-- 加锁
SET lock_key unique_value NX EX 30

-- 解锁（Lua 保证原子性）
if redis.call("get", KEYS[1]) == ARGV[1] then
    return redis.call("del", KEYS[1])
end

创建临时顺序节点
判断是否最小节点
是 → 获得锁
否 → 监听前一个节点

5.5 分布式 ID

5.6 一致性哈希

哈希环：0 ~ 2^32-1
节点映射到环上
数据顺时针找到第一个节点

虚拟节点：解决数据倾斜

5.7 Raft 协议

1. 选举：获得多数票成为 Leader
2. 日志复制：Leader 复制日志到 Follower
3. 提交：多数确认后提交

5.8 Paxos 协议

5.9 ZooKeeper 原理与应用

/services
  /user-service
    /instance-1  (临时节点)
    /instance-2  (临时节点)

六、缓存设计

6.1 缓存策略

6.2 缓存一致性

def update(data):
    db.update(data)
    cache.delete(key)

    # 延迟双删（可选）
    time.sleep(0.5)
    cache.delete(key)

6.3 多级缓存

请求 → 本地缓存(Caffeine) → Redis → 数据库

6.4 热点数据处理

6.5 缓存预热

def warm_up_cache():
    # 加载热点商品
    hot_products = db.query("SELECT * FROM products WHERE is_hot = 1")
    for product in hot_products:
        cache.set(f"product:{product.id}", product, ex=3600)

    # 加载热门用户
    hot_users = db.query("SELECT * FROM users ORDER BY followers DESC LIMIT 1000")
    for user in hot_users:
        cache.set(f"user:{user.id}", user, ex=3600)

七、限流熔断

7.1 限流算法

class TokenBucket:
    def __init__(self, rate, capacity):
        self.rate = rate          # 令牌生成速率
        self.capacity = capacity  # 桶容量
        self.tokens = capacity
        self.last_time = time.time()

    def acquire(self):
        now = time.time()
        # 添加令牌
        self.tokens = min(self.capacity,
                         self.tokens + (now - self.last_time) * self.rate)
        self.last_time = now

        if self.tokens >= 1:
            self.tokens -= 1
            return True
        return False

7.2 熔断器

Closed → Open → Half-Open → Closed
  ↓       ↓         ↓
正常    熔断    尝试恢复

7.3 降级策略

7.4 服务隔离

// Hystrix 线程池隔离
@HystrixCommand(
    threadPoolKey = "userServicePool",
    threadPoolProperties = {
        @HystrixProperty(name = "coreSize", value = "10"),
        @HystrixProperty(name = "maxQueueSize", value = "100")
    }
)
public User getUser(Long id) {
    return userService.getUser(id);
}

八、性能优化

8.1 接口优化

8.2 数据库优化

8.3 线上问题排查

1. top -c 找到进程
2. top -Hp <pid> 找到线程
3. printf '%x' <tid> 转 16 进制
4. jstack <pid> | grep <tid> 查看堆栈

1. jmap -heap <pid> 查看堆使用
2. jmap -dump:format=b,file=heap.bin <pid>
3. MAT 分析 dump 文件

1. jstat -gc <pid> 1000 查看 GC 情况
2. 分析 GC 日志
3. 调整堆大小、GC 算法

8.4 JVM 调优

# 堆内存
-Xms4g -Xmx4g          # 初始和最大堆
-Xmn2g                  # 新生代大小

# GC 选择
-XX:+UseG1GC           # G1 收集器
-XX:+UseZGC            # ZGC（低延迟）

# GC 日志
-Xlog:gc*:file=gc.log:time,uptime:filecount=5,filesize=10M

8.5 压测与性能评估

# wrk 示例
wrk -t12 -c400 -d30s http://localhost:8080/api/users

八点五、监控告警

8.6 日志收集与分析（ELK）

应用日志 → Filebeat → Kafka → Logstash → Elasticsearch → Kibana

{
  "timestamp": "2026-01-09T10:00:00Z",
  "level": "ERROR",
  "service": "order-service",
  "traceId": "abc123",
  "message": "订单创建失败",
  "exception": "..."
}

8.7 链路追踪（Jaeger/Zipkin）

请求进入 → 生成 TraceId → 传递到下游服务 → 收集 Span → 聚合展示

8.8 指标监控（Prometheus/Grafana）

应用暴露 /metrics → Prometheus 拉取 → 存储时序数据 → Grafana 展示
                                    ↓
                              Alertmanager 告警

8.9 告警设计

# Prometheus 告警规则
groups:
-name: api-alerts
rules:
-alert: HighErrorRate
expr: rate(http_requests_total{status="500"}[5m]) > 0.1
for: 5m
labels:
severity: critical
annotations:
summary:"高错误率告警"

九、场景设计题

9.1 秒杀系统

用户 → CDN → Nginx → 网关 → 秒杀服务 → Redis → MQ → 订单服务

local stock = redis.call('get', KEYS[1])
if tonumber(stock) > 0 then
    redis.call('decr', KEYS[1])
    return 1
end
return 0

9.2 短链服务

1. 生成短码：Base62(自增ID) 或 哈希
2. 存储：短码 → 长链接
3. 访问：302 重定向

CHARS = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"

def encode(num):
    result = []
    while num:
        result.append(CHARS[num % 62])
        num //= 62
    return ''.join(reversed(result))

9.3 Feed 流系统

发布动态 → 写入所有粉丝的 Feed 列表
优点：读取快
缺点：写放大（大 V 问题）

读取 Feed → 聚合关注人的动态
优点：写入简单
缺点：读取慢

9.4 订单系统

9.5 支付系统

9.6 抢红包系统

-- 抢红包 Lua 脚本
local remaining = redis.call('hget', KEYS[1], 'remaining')
if tonumber(remaining) > 0 then
    local amount = redis.call('lpop', KEYS[2])
    if amount then
        redis.call('hincrby', KEYS[1], 'remaining', -1)
        return amount
    end
end
return nil

9.7 评论系统

-- 评论表
CREATE TABLE comments (
    id BIGINT PRIMARY KEY,
    content TEXT,
    user_id BIGINT,
    target_id BIGINT,      -- 被评论对象
    parent_id BIGINT,      -- 父评论（楼中楼）
    root_id BIGINT,        -- 根评论
    created_at TIMESTAMP
);

9.8 排行榜系统

# 更新分数
redis.zadd("leaderboard", {user_id: score})

# 获取排名（从 0 开始）
rank = redis.zrevrank("leaderboard", user_id)

# 获取 Top N
top_users = redis.zrevrange("leaderboard", 0, 9, withscores=True)

# 获取用户附近排名
start = max(0, rank - 5)
nearby = redis.zrevrange("leaderboard", start, rank + 5, withscores=True)

9.9 搜索系统

数据源 → 数据同步 → Elasticsearch → 搜索服务 → 用户

9.10 定时任务系统

9.11 消息推送系统

业务系统 → 推送服务 → 长连接网关 → 客户端
                   ↘ 第三方推送（APNs/FCM）

9.12 文件存储系统

客户端 → 上传服务 → 对象存储（OSS/S3）
              ↓
         元数据服务 → 数据库

十、通用问题

10.1 接口幂等性

# 获取 Token
token = uuid.uuid4()
redis.set(f"token:{token}", 1, ex=300)
return token

# 使用 Token
if redis.delete(f"token:{token}"):
    # 执行业务
else:
    # 重复请求

10.2 接口安全

10.3 灰度发布

10.4 AB 测试

def get_experiment_group(user_id, experiment_name):
    bucket = hash(f"{user_id}:{experiment_name}") % 100
    if bucket < 10:
        return "control"  # 对照组 10%
    elif bucket < 20:
        return "treatment_a"  # 实验组A 10%
    else:
        return "treatment_b"  # 实验组B 80%

10.5 项目亮点回答模板

1. 背景：为什么要做这个优化/设计
2. 方案：采用了什么技术方案
3. 实现：关键的技术细节
4. 效果：量化的改进数据
5. 思考：方案的优缺点、改进空间

背景：订单查询接口 P99 延迟达到 500ms，影响用户体验
方案：引入多级缓存（本地缓存 + Redis）
实现：
  - 本地缓存使用 Caffeine，TTL 10s
  - Redis 缓存 TTL 5min
  - 缓存更新采用 Cache-Aside 模式
效果：P99 延迟降低到 50ms，数据库 QPS 下降 80%
思考：需要注意缓存一致性问题，采用延迟双删保证

10.6 如何设计高可用系统

可用性 = MTBF / (MTBF + MTTR)

MTBF: 平均故障间隔时间
MTTR: 平均故障恢复时间

提高可用性：
1. 增加 MTBF：减少故障发生
2. 减少 MTTR：快速恢复

10.4 项目难点回答模板

1. 背景：遇到什么问题
2. 分析：问题原因是什么
3. 方案：尝试了哪些方案
4. 选择：为什么选择这个方案
5. 结果：最终效果如何
6. 反思：有什么收获

十一、高频面试题与答案

Q1: 如何介绍项目？

1. Situation（背景）：项目是什么，解决什么问题
2. Task（任务）：你负责哪部分，目标是什么
3. Action（行动）：你做了什么，用了什么技术
4. Result（结果）：取得了什么成果，数据量化

Q2: 如何设计高并发系统？

1. 缓存：Redis 缓存热点数据，减少数据库压力
2. 异步：消息队列削峰填谷，异步处理非核心逻辑
3. 分流：
   - CDN 静态资源加速
   - 负载均衡分散请求
   - 分库分表分散数据
4. 限流：保护系统不被压垮
5. 池化：连接池、线程池复用资源
6. 无状态：服务无状态，支持水平扩展

Q3: 如何保证高可用？

Q4: 消息队列如何保证不丢失？

生产端：
- 开启发送确认（confirm 模式）
- 失败重试 + 本地消息表

Broker 端：
- 消息持久化到磁盘
- 多副本同步（Kafka ISR）

消费端：
- 手动 ACK，处理完再确认
- 消费失败进入死信队列

Q5: 分布式事务怎么做？

Q6: 分布式锁怎么实现？

# 加锁
SET lock_key unique_id NX PX 30000

# 解锁（Lua 脚本）
if redis.call("get", KEYS[1]) == ARGV[1] then
    return redis.call("del", KEYS[1])
end

Q7: 缓存一致性怎么保证？

读：先读缓存，没有则读数据库，写入缓存
写：先更新数据库，再删除缓存

1. 删除缓存
2. 更新数据库
3. 延迟 500ms 再删除缓存（防止并发读写不一致）

Q8: 接口幂等怎么做？

Q9: 限流算法有哪些？

Q10: 设计秒杀系统？

1. 前端：
   - 静态资源 CDN
   - 按钮防重复点击
   - 答题/验证码削峰

2. 网关层：
   - 限流（令牌桶）
   - 黑名单过滤

3. 服务层：
   - Redis 预扣库存
   - 库存不足直接返回
   - 下单请求入消息队列

4. 数据层：
   - 异步消费创建订单
   - 数据库乐观锁扣减库存

Q11: 设计短链服务？

1. 发号器生成唯一 ID
2. Base62 编码（0-9, a-z, A-Z）
3. 存储映射关系：短链 → 长链

1. 用户访问短链
2. 服务查询映射关系
3. 302 重定向到长链

Q12: 线上问题怎么排查？

1. top -Hp <pid> 查看高 CPU 线程
2. printf "%x\n" <tid> 转换为十六进制
3. jstack <pid> | grep <tid> 查看线程堆栈

1. jmap -heap <pid> 查看堆内存
2. jmap -dump:format=b,file=heap.hprof <pid>
3. MAT 分析堆转储

1. jstat -gc <pid> 1000 查看 GC 情况
2. 分析 GC 日志
3. 调整堆大小、GC 算法

最后更新：2026-01-09