高效能架構設計#

高效能是架構設計中最常見的需求之一。本章介紹高效能架構的核心模式，包括快取、非同步處理和負載均衡。

高效能的複雜度來源#

高效能帶來的複雜度主要體現在兩個層面：

架構設計決定了系統效能的上限，實作細節決定了系統效能的下限。如果架構設計沒有做到高效能，後面的最佳化空間是有限的。

單機高效能模式#

並發模型#

並發模型有兩個關鍵設計點：

• I/O 模型：阻塞、非阻塞、同步、非同步
• 行程模型：單行程、多行程、多執行緒

Reactor 模式三種子模式#

Reactor 的核心是「I/O 多路復用 + 非阻塞 I/O」。常見有三種子模式，差別在於 Acceptor / Handler 是否分離、是否多執行緒：

在現代高效能伺服器中，多 Reactor 已是主流選擇；Redis 則因為自身單執行緒模型的設計取捨而採用單 Reactor。

快取架構#

快取是高效能架構中最常用的技術，基本原理是將可能重複使用的資料放到記憶體中，一次生成、多次使用。

快取帶來的問題#

雖然快取能大幅提升效能，但也引入了架構複雜性：

快取穿透詳解#

場景一：資料確實不存在

每次查詢都繞過快取直打資料庫，相當於快取形同虛設。常見對策是對空結果也快取（設較短的 TTL），讓後續同樣的查詢由快取吸收。

data := cache.Get(key)
if data == nil {
    data = db.Query(key)
    if data == nil {
        cache.Set(key, EMPTY_VALUE, 60) // 關鍵：對空值也設較短 TTL
    } else {
        cache.Set(key, data, 3600)
    }
}

場景二：快取生成耗時長

例如電商分頁，爬蟲遍歷所有頁面時，大量冷門分頁的快取已過期，需要重新從 DB 生成。

這種情況沒有完美解決方案。常見做法是識別爬蟲並限流，或做好監控及時處理。

快取雪崩詳解#

當大量快取在同一時間點失效，原本由快取吸收的流量會瞬間全部打到資料庫，造成 DB 崩潰。常見對策有兩種：

方案一：更新鎖

只允許一個請求去查 DB 並回寫快取，其他請求等待或返回預設值。

def get_data(key):
    data = cache.get(key)
    if data is None:
        if lock.acquire(key):  # 嘗試取得分散式鎖
            try:
                data = db.query(key)
                cache.set(key, data)
            finally:
                lock.release(key)
        else:
            time.sleep(0.1)
            return get_data(key)
    return data

方案二：後台更新

• 快取永不過期
• 後台執行緒定時更新
• 業務執行緒只讀快取

後台更新的優勢：既適用於單機多執行緒，也適用於分散式叢集，實作比更新鎖簡單。

快取熱點詳解#

某明星發微博，瞬間上千萬用戶湧入查看。即使是 Redis，單 key 的 QPS 也有上限。

解決方案：多副本 + 隨機讀取

原始：key = "weibo_12345"
副本：key = "weibo_12345_1", "weibo_12345_2", ..., "weibo_12345_100"

讀取時隨機選擇一個副本

不同副本的過期時間要隨機化，避免同時失效。

負載均衡架構#

當單機效能無法滿足需求時，需要通過叢集來擴展效能。

負載均衡分類#

負載均衡演算法#

非同步處理架構#

非同步處理是提升系統吞吐量的重要手段，核心思想是將非關鍵路徑的操作延後處理。

非同步架構模式#

flowchart LR
    subgraph 同步處理
        A1[用戶] --> B1[業務邏輯]
        B1 --> C1[發短信<br/>100ms]
        C1 --> D1[記日誌<br/>50ms]
        D1 --> E1[返回<br/>總耗時 150ms+]
    end

    subgraph 非同步處理
        A2[用戶] --> B2[業務邏輯]
        B2 --> E2[返回<br/>立即]
        B2 -.-> Q[訊息佇列]
        Q -.-> S1[簡訊服務]
        Q -.-> S2[日誌服務]
    end

訊息佇列選型#

非同步設計要點#

非同步不是銀彈，引入訊息佇列會帶來以下問題：

• 訊息遺失：需要持久化和確認機制
• 訊息重複：消費端需要冪等處理
• 訊息積壓：需要監控和擴容機制
• 順序問題：可能需要特殊處理

效能最佳化方法論#

最佳化層次#

flowchart TB
    A["業務最佳化<br/>(效果最大)"] --> B["架構最佳化"]
    B --> C["程式碼最佳化"]
    C --> D["設定最佳化<br/>(效果最小)"]

    style A fill:#c8e6c9
    style B fill:#e8f5e9
    style C fill:#fff3e0
    style D fill:#ffecb3

常見最佳化手段#

本章小結#

記住這個公式：高效能 = 合適的並發模型 + 快取 + 負載均衡 + 非同步處理