演算法演進：從 0 到 1 億使用者

引言：負載改變一切

一個在 100 個使用者時執行完美的演算法，可能會在 100 萬使用者時讓妳的伺服器崩潰。隨著流量的增長，瓶頸會從 邏輯 轉移到 I/O，然後是 網路，最後是 分散式協作。

以下是隨著規模擴大，妳的演算法策略應當如何調整。

階段 1：MVP 雛形期 (0 - 1 萬使用者)

目標： 交付速度。

• 演算法： 直接使用語言內建的功能。Array.sort(), HashMap, List.filter()。
• 策略： 先不要最佳化。當 $N$ 是 1,000 時，$O(N)$ 沒任何問題。
• 儲存： 單個關聯式資料庫。讓資料庫透過簡單的 B-Tree 索引來處理「搜尋」和「排序」。

階段 2：快速增長期 (1 萬 - 100 萬使用者)

目標： 響應時間 (延遲)。

• 問題： 線性掃描 ($O(N)$) 開始出現在「慢查詢日誌」中。
• 演算法：
  • 快取： 引入 LRU 快取 以避免頻繁讀取資料庫。
  • 搜尋： 從 LIKE %關鍵字% 轉向 倒排索引 (Elasticsearch)。
  • 最佳化： 用專門的資料結構（如 前綴樹 Trie）來實現搜尋建議，替代繁重的迴圈。

階段 3：規模化擴張期 (100 萬 - 1000 萬使用者)

目標： 吞吐量與記憶體效率。

• 問題： 妳無法將所有數據存入單台伺服器的記憶體。
• 演算法：
  • 概率型： 在查詢資料庫前，先用 布隆過濾器 (Bloom Filter) 檢查使用者是否存在。
  • 統計： 使用 HyperLogLog 進行獨立訪客計數，節省 99% 的記憶體。
  • 分片： 使用 一致性雜湊 (Consistent Hashing) 將使用者分布到多個資料庫節點。

階段 4：全球級規模 (1000 萬 - 1 億+ 使用者)

目標： 高可用與系統彈性。

• 問題： 機器每天都在掛，網路不可靠。
• 演算法：
  • 共識： 使用 Raft 或 Paxos 保持跨數據中心配置的一致性。
  • 流量控制： 實施 令牌桶 限流和 熔斷器，防止級聯失效。
  • 大數據： 使用 外部排序 和 MapReduce 模式來處理遠超單塊硬碟容量的數據。

典型業務場景

• ✅ 排行榜： 初期用 SQL ORDER BY。100 萬使用者時，改用 Redis ZSet (跳表)。1 億使用者時，使用 分片聚合 模式。
• ✅ 推薦系統： 初期用簡單的「分類」過濾。規模化後，轉向使用 HNSW 的 向量搜尋 (ANN)。

小結：一句話記住它

「擴展就是用複雜性換取效率的過程。從簡單開始，但腦中要有一張『對數地圖』，以便知道何時該升級妳的武器庫。」