系統設計基礎：如何思考架構？

設計的思考框架

1. 需求分析：系統要做什麼？（功能需求 + 非功能需求）
2. 估算規模：多少使用者？多少資料？QPS 多少？
3. 定義 API：對外提供什麼介面？
4. 資料模型：資料怎麼存？關聯怎麼設計？
5. 核心架構：高層設計圖
6. 細節深入：瓶頸在哪？怎麼優化？

擴展策略

垂直擴展（Scale Up）

CPU 不夠 → 換更強的 CPU
記憶體不夠 → 加更多 RAM
↓
簡單但有天花板（單台機器有極限）

水平擴展（Scale Out）

一台不夠 → 加更多台
→ 需要負載平衡（Load Balancer）
→ 需要 Session 共享（Redis）
→ 需要資料庫複製（Read Replica）
↓
理論上無限擴展，但複雜度高

常見架構元件

使用者
  ↓
CDN（靜態資源快取）
  ↓
Load Balancer（負載平衡）
  ↓
Web Server × N（水平擴展）
  ↓       ↓
Redis    Database
(快取)   (主從複製)
  ↓
Message Queue（非同步處理）
  ↓
Worker Service（背景任務）

資料庫擴展

讀寫分離：
Master（寫入）→ 複製到 → Replica 1, 2, 3（讀取）
→ 適合讀多寫少的應用

分片（Sharding）：
使用者 1-100萬 → DB Shard 1
使用者 100萬-200萬 → DB Shard 2
→ 適合資料量極大的場景
→ 但跨 Shard 查詢很困難

NoSQL：
MongoDB（文件型）、Redis（鍵值型）、Cassandra（列式）
→ 適合特定場景，不是替代 SQL

CAP 定理

分散式系統只能同時滿足三個中的兩個：
C — Consistency（一致性）：所有節點看到的資料一樣
A — Availability（可用性）：每個請求都能得到回應
P — Partition Tolerance（分區容錯）：網路分區時系統繼續運作

實務上 P 必須要有（網路一定會出問題），所以選擇：
CP：保證一致性，犧牲可用性（如：銀行系統）
AP：保證可用性，犧牲一致性（如：社群平台的按讚數）

重點不是背這些，而是能分析特定場景的需求，選擇合適的架構。