系统设计基础

官方文档：https://learn.microsoft.com/zh-cn/azure/architecture/patterns/
适用版本：2026-05-07 整理

核心指标

SLA 对照表：

水平扩展 vs 垂直扩展

选择建议：无状态服务（Web 层、API 层）优先水平扩展；数据库初期垂直扩展，达到瓶颈后考虑分库分表或读写分离。

缓存策略

缓存模式对比

缓存三大问题

缓存穿透（查询不存在的 key，每次都打到 DB）：

• 解决：布隆过滤器（Bloom Filter）拦截非法 key；或将空结果也缓存（短 TTL）

缓存击穿（热点 key 过期，瞬间大量请求打到 DB）：

• 解决：互斥锁（只让一个请求重建缓存）；或热点 key 不设过期时间，主动更新

缓存雪崩（大量 key 同时过期，或缓存服务宕机）：

• 解决：TTL 随机抖动（base_ttl + random(0, 300)）；缓存服务高可用（主从/集群）；熔断降级

import random
import time

def set_cache_with_jitter(key: str, value, base_ttl: int = 3600):
    """加入随机抖动防止缓存雪崩"""
    jitter = random.randint(0, base_ttl // 10)  # 10% 抖动
    ttl = base_ttl + jitter
    redis_client.setex(key, ttl, value)

限流算法

令牌桶 Python 实现：

import time
import threading

class TokenBucket:
    def __init__(self, rate: float, capacity: int):
        """
        参数：
            rate     - 每秒生成的令牌数
            capacity - 桶的最大容量
        """
        self.rate = rate
        self.capacity = capacity
        self._tokens = capacity
        self._last_refill = time.monotonic()
        self._lock = threading.Lock()

    def consume(self, tokens: int = 1) -> bool:
        with self._lock:
            self._refill()
            if self._tokens >= tokens:
                self._tokens -= tokens
                return True
            return False

    def _refill(self):
        now = time.monotonic()
        elapsed = now - self._last_refill
        self._tokens = min(self.capacity, self._tokens + elapsed * self.rate)
        self._last_refill = now

Redis 实现分布式限流（滑动窗口）：

-- KEYS[1]: 限流 key
-- ARGV[1]: 当前时间戳（毫秒）
-- ARGV[2]: 窗口大小（毫秒）
-- ARGV[3]: 限流阈值
local key = KEYS[1]
local now = tonumber(ARGV[1])
local window = tonumber(ARGV[2])
local limit = tonumber(ARGV[3])

redis.call('ZREMRANGEBYSCORE', key, 0, now - window)
local count = redis.call('ZCARD', key)
if count < limit then
    redis.call('ZADD', key, now, now)
    redis.call('EXPIRE', key, math.ceil(window / 1000))
    return 1
end
return 0

API 设计规范

RESTful 设计原则

URL 命名规则：

• 用名词复数，不用动词：/users 而非 /getUsers
• 层级关系：/users/{id}/orders
• 过滤用 query 参数：/users?status=active&page=1&page_size=20

版本控制

分页方案对比

Cursor 分页响应格式：

{
  "data": [...],
  "pagination": {
    "next_cursor": "eyJpZCI6IDEwMH0",
    "has_next": true
  }
}

幂等设计

# FastAPI 幂等 Key 中间件示意
async def idempotency_middleware(request: Request, call_next):
    idempotency_key = request.headers.get("Idempotency-Key")
    if idempotency_key and request.method == "POST":
        cached = await redis.get(f"idem:{idempotency_key}")
        if cached:
            return JSONResponse(content=json.loads(cached), status_code=200)
    response = await call_next(request)
    if idempotency_key and response.status_code in (200, 201):
        body = b""
        async for chunk in response.body_iterator:
            body += chunk
        await redis.setex(f"idem:{idempotency_key}", 86400, body)
        return Response(content=body, status_code=response.status_code,
                        headers=dict(response.headers))
    return response

分布式 ID

雪花算法结构（64 bit）：

符号位(1) | 时间戳(41) | 机器ID(10) | 序列号(12)

• 时间戳：毫秒级，从自定义 epoch 开始，可用约 69 年
• 机器 ID：最多 1024 个节点
• 序列号：同一毫秒内最多 4096 个 ID

import time
import threading

class Snowflake:
    def __init__(self, machine_id: int, epoch: int = 1700000000000):
        assert 0 <= machine_id < 1024
        self.machine_id = machine_id
        self.epoch = epoch
        self._sequence = 0
        self._last_ts = -1
        self._lock = threading.Lock()

    def generate(self) -> int:
        with self._lock:
            ts = int(time.time() * 1000) - self.epoch
            if ts == self._last_ts:
                self._sequence = (self._sequence + 1) & 0xFFF
                if self._sequence == 0:
                    while ts <= self._last_ts:
                        ts = int(time.time() * 1000) - self.epoch
            else:
                self._sequence = 0
            self._last_ts = ts
            return (ts << 22) | (self.machine_id << 12) | self._sequence

CAP 定理

定义：分布式系统不能同时满足以下三个特性：

在分布式环境中 P 是必须保证的，所以实际是 CP vs AP 的选择。

BASE 理论（对 ACID 的弱化）：

• BA - 基本可用（Basically Available）：允许损失部分可用性
• S - 软状态（Soft State）：允许中间状态存在
• E - 最终一致性（Eventually Consistent）：数据最终会达到一致

消息队列使用场景

参考：RabbitMQ完全指南、Kafka完全指南、Celery完全指南

最佳实践

系统设计面试框架（RESHADED）

容量估算速算表

常用换算：

• 100 万 DAU，每用户每天 10 次请求 → 约 12 QPS（100万×10/86400）
• 1 GB/day 数据写入 → 约 12 KB/s
• MySQL 单表上限：500 万行以上考虑分表；读 QPS > 5,000 考虑读写分离

缓存设计决策树

需要缓存吗？
├── 数据读多写少 → 是，考虑缓存
│   ├── 数据允许短暂不一致 → Cache-Aside + TTL
│   ├── 数据必须强一致 → Write-Through
│   └── 写性能是瓶颈 → Write-Behind（接受丢失风险）
└── 数据写多读少 → 通常不缓存，考虑异步写入队列

数据库选型原则

常见陷阱

陷阱：缓存与数据库数据不一致

现象： 用户更新了数据，缓存命中后返回旧数据，直到缓存过期才恢复正常。

原因： 更新数据库后忘记同步删除/更新缓存，或更新缓存失败（网络抖动）导致脏数据残留。

解决： 使用 Cache-Aside（旁路缓存）模式：写操作先更新数据库，再删除缓存（而不是更新缓存）；读操作 miss 时从数据库加载并写入缓存。删除缓存比更新缓存更安全，因为下次读时才重建，避免并发写的竞态。

陷阱：没有设置超时导致线程/协程堆积

现象： 下游服务变慢后，上游服务接口响应时间线性增加，最终所有线程耗尽，服务不可用。

原因： 对数据库、Redis、HTTP 等外部调用未设置超时，一旦下游慢，调用方线程长时间阻塞，新请求无线程可用。

解决： 所有外部调用必须配置超时（HTTP: timeout=3s，数据库: connect_timeout + read_timeout，Redis: socket_timeout）；配合熔断器（Circuit Breaker）在错误率超阈值时快速失败，防止级联故障。

陷阱：分布式锁过期时任务未完成

现象： 任务持有 Redis 分布式锁，但任务执行时间超过锁的 TTL，锁被自动释放，其他节点拿到锁并开始执行，产生重复操作。

原因： TTL 设置过短，或任务执行时间不可预估（GC 暂停、慢查询等）导致持锁时间超出预期。

解决： 用看门狗（watchdog）机制：持有锁的进程周期性续期；或在任务逻辑中做幂等保证（即使重复执行也不影响最终结果），锁只是降低重复的概率而非完全依赖。

参见

• Redis完全指南 — 缓存实现、分布式锁、排行榜
• MySQL基础完全指南 — 索引优化、分库分表
• Kafka完全指南 — 消息队列、流量削峰
• RabbitMQ完全指南 — 任务队列、事件驱动
• Prometheus与Grafana监控 — 系统性能监控、SLA 告警