主題
0.0 · 三分鐘看懂後端世界
Part 0 前置知識
預估 3 分鐘
難度：入門
後端
名詞
速查
這章給誰看
你大學念過資工 / 計概，會寫一點程式，但「網站背後是怎麼跑的」還沒搞清楚。這頁用 3 分鐘給你一張全景圖 + 10 個最基本的詞，看完再進 0.1 才不會被縮寫淹沒。
如果你已經寫過後端、API、SQL，這頁可以直接跳過去 0.1 為什麼需要資料密集系統。
一張圖：使用者打開網站時發生什麼事
你（使用者） 網路 機房
┌──────┐ ╱ ╲ ┌─────────────────────────┐
│瀏覽器 │ ──請求──▶ ⟨網路⟩ ──▶ │ 伺服器 ← 應用程式跑著 │
│ │ ◀─回應── ⟨網路⟩ ◀── │ ↓ │
└──────┘ │ 資料庫（存資料的地方）│
└─────────────────────────┘1
2
3
4
5
6
2
3
4
5
6
3 件事一定要懂：
- 瀏覽器不存資料——它只顯示。網址列輸入
example.com/orders時，瀏覽器是去問某台機器「給我訂單資料」。 - 被問的那台機器叫「伺服器」，上面跑著一個「程式」，這程式就是後端。
- 資料真的存在哪？ 不在瀏覽器、也不在跑後端的那台機器的記憶體裡（它重開就沒了）——存在一個專門設計來「不丟失資料」的系統，叫資料庫。
DDIA 整本書，就是在處理「資料庫」這個元件的所有困難。
10 個最基本的詞
每個詞配一句白話 + 一個生活類比。分成 4 群、看完這 10 個再進 0.1 不會卡：連線（1-4）→ 儲存（5-7）→ 訊息（8）→ 格式 + 架構（9-10）。
§ 連線層 · 你問、伺服器答
1. 後端（Backend）
白話：在伺服器上跑的程式，負責處理請求、讀寫資料庫、回應結果。 類比：餐廳廚房——你（使用者）在外場下單，廚房（後端）做菜，外場（前端）把成品端給你。
2. 伺服器（Server）
白話：一台 24 小時開機、有公開 IP、等別人連進來的電腦。實體機房裡的那台，或是 AWS / GCP 雲端虛擬機。 類比：總機電話——24 小時等人打進來，有事就接、處理、回應。 順手講「公開 IP」：IP 是電腦在網路上的地址。公開 IP = 全世界都能連到的地址（伺服器要這種）；私有 IP = 只在自家內網能連（你家的筆電一般是這種，藏在路由器後面）。
3. API（Application Programming Interface）
白話：後端對外開放的「能做的事清單」+「怎麼呼叫的規則」。 範例：GET /api/orders/123 = 「我要看訂單 123 的資料」。後端收到這個請求就會去資料庫撈、組 JSON、回傳。 類比：餐廳菜單——上面列了所有能點的菜（API 端點）+ 每道菜的名字（路徑）+ 加價選項（query 參數）。
4. 請求 / 回應（Request / Response）
白話：瀏覽器或 App 「問」一句 → 伺服器「答」一句，這一來一回就是一次互動。 重點：HTTP 是無狀態的——這次請求和下次請求是分開的，伺服器不會記得你上一秒問過什麼，除非你主動帶 cookie / token。
§ 儲存層 · 資料怎麼存
5. 資料庫（Database, DB）
白話：專門設計來「穩定地存資料、且能高速查詢」的系統。停電後資料還在、多人同時操作不會打架。 類比：圖書館的書庫——不是電腦的記憶體那種臨時存放，是有專人管理、編目、防火災的長期儲存場所。
6. SQL 與 NoSQL
白話：兩大類資料庫的代表。
- SQL（關聯式）：資料像 Excel 表格（PostgreSQL、MySQL）—— 嚴格、可靠、會 JOIN
- NoSQL：資料像 JSON 物件（MongoDB、Firestore、DynamoDB）—— 彈性、就近 embed 整份文件、跨文件 JOIN 不是原生強項（MongoDB 3.2+ 有
$lookup補、但效能不比關聯式 DB） 重點：兩種不是替代關係，是適合不同場景。詳見 Ch2 資料模型。
7. 快取（Cache）
白話：把「最近常被問的答案」放在更快的地方（記憶體），下次再被問就直接給、不用重新算。 類比：餐廳熱賣菜——預先煮好、有人點立刻給，不用等 20 分鐘現做。代價是預先做的菜可能賣不完（資料變舊）。
§ 訊息層 · 不急的事先排隊
8. 佇列 / 訊息隊列（Queue / Message Queue, MQ）
白話：「不急著回應的事先排隊、之後再慢慢處理」的中介系統（Kafka、RabbitMQ）。 類比：餐廳的「外送單黏在出菜口」——師傅做完一道、就抓下一張單。誰先誰後、做不完累積在牆上、都不會搞丟。
§ 資料格式與架構
9. JSON
白話：前後端互傳資料的標準格式。看起來像 JS 物件：
json
{ "id": 123, "user": "alice", "amount": 100 }1
API 回傳的東西、寫進 NoSQL 的東西，多半長這樣。
10. 分散式系統（Distributed System）
白話：一台機器撐不下、要避免單點故障、或要把服務放到使用者附近降低延遲時，就把工作分散到多台機器——這套架構叫分散式。
三個動機（DDIA Ch1 列得很清楚）：
- Scalability（可擴展）：一台撐不下 → 加機器
- Fault tolerance（容錯）：避免單點故障
- Low latency（低延遲）：把資料 / 服務放到使用者附近的機房（如台灣連 Netflix 走的是東京 / 新加坡 CDN、不是真的美國機房）
為什麼難：「多台之間怎麼同步資料 / 誰當老大 / 網路斷一半怎麼辦」—— DDIA Part II 整個就在處理這些。
「Scale up vs Scale out」「100 ms 為何是延遲分水嶺」這些更細的問題、在 0.1 為什麼需要資料密集系統 詳述。這頁先抓住「分散式 = 多台機器」這個直覺即可。
OLTP vs OLAP（兩個你之後一定會看到的縮寫）
| OLTP（線上交易處理） | OLAP（線上分析處理） | |
|---|---|---|
| 做什麼 | 每秒處理大量小操作（下訂單、改密碼） | 跑大型報表（這個月誰買最多） |
| 資料量/查詢 | 動的多、每次只摸幾筆 | 動的少、每次掃整張表 |
| 代表產品 | PostgreSQL、MySQL（OLTP DB） | BigQuery、Redshift（OLAP DB） |
| DDIA Ch3 在做什麼 | 拆解這兩種 DB 在儲存引擎上的根本差異 |
簡單記：OLTP = 即時、小量；OLAP = 報表、大量。
看完這頁，你可以開始 Part 0 了
接下來建議的閱讀順序：
0.0（這頁）✓ → 0.1 為什麼需要資料系統 → 0.2 衡量指標 → 之後按需挑1
進 0.1 時你會看到的詞——全部已在這頁解釋過：後端、stateless、DB、Cache、MQ、JSON、分散式。
Stateless / Stateful 還沒講？
這兩個詞 0.1 開頭會直接定義。先記兩件事：
- 伺服器自己不存使用者狀態（資料丟給資料庫、session 丟給 Redis/JWT）—— 這設計叫 stateless
- 真正的好處：因為任一台伺服器都能處理任一請求、你可以開 10 台分擔負載、掛了一台就把流量導到其他台、永遠不用煩惱「使用者剛剛在哪台」
The Next Chapter
0.1 為什麼需要資料密集系統
Continue Reading→