系統設計機制完整比較指南

目錄

1. I/O 處理機制
2. 記憶體管理
3. 排程策略
4. 並行控制
5. 資料結構選擇
6. 快取策略
7. 網路與通訊
8. 儲存策略
9. 一致性模型
10. 執行模式
11. 設計模式

I/O 處理機制

1. 中斷 vs 輪詢 (Interrupt vs Polling)

詳細說明：

• 中斷機制：當你在電腦上按下鍵盤，鍵盤會發送一個中斷訊號給CPU，CPU暫停當前工作，處理鍵盤輸入，然後繼續原本的工作。
• 輪詢機制：遊戲引擎每16毫秒檢查一次手把按鈕狀態，確保即時回應玩家操作。
• 混合策略：Linux的NAPI在網路封包少時用中斷，封包多時切換到輪詢避免中斷風暴。

2. 同步 vs 異步 (Synchronous vs Asynchronous)

詳細說明：

• 同步範例：你打電話給客服，必須等電話接通、問題處理完才能掛斷，這段時間什麼都不能做。
• 異步範例：你發email給客服，發送後可以繼續工作，收到回覆時再處理。
• JavaScript範例：

  // 同步
  const data = readFileSync('file.txt'); // 等待完成
  console.log(data);
  
  // 異步
  readFile('file.txt', (err, data) => {
    console.log(data); // 稍後執行
  });
  console.log('繼續執行'); // 立即執行
  

3. 阻塞 vs 非阻塞 (Blocking vs Non-blocking)

詳細說明：

• 阻塞範例：你打電話訂餐，必須等店員接電話、記錄完訂單，電話才能掛斷。
• 非阻塞範例：你用App訂餐，點擊送出後App立即回到主畫面，訂單在背景處理。
• Socket範例：

  # 阻塞模式
  data = socket.recv(1024)  # 等到收到資料
  
  # 非阻塞模式
  socket.setblocking(False)
  try:
      data = socket.recv(1024)  # 立即返回
  except BlockingIOError:
      # 資料還沒準備好
      pass
  

4. DMA vs PIO (Direct Memory Access vs Programmed I/O)

詳細說明：

• DMA範例：你下載電影時，網卡收到的資料直接寫入記憶體，CPU可以同時執行其他程式。
• PIO範例：早期電腦讀取軟碟時，CPU要一個一個位元組搬移資料，這時電腦會變得很慢。
• 效能差異：
  • DMA：1GB資料傳輸，CPU使用率 < 5%
  • PIO：1GB資料傳輸，CPU使用率接近 100%

5. 零拷貝 vs 傳統拷貝 (Zero-Copy vs Traditional Copy)

詳細說明:

• 傳統拷貝流程:發送檔案給客戶端

  1. read(): Disk → Kernel buffer (DMA)
  2. read(): Kernel buffer → User buffer (CPU拷貝)
  3. write(): User buffer → Socket buffer (CPU拷貝)
  4. write(): Socket buffer → Network card (DMA)
  總共:2次DMA + 2次CPU拷貝 + 4次上下文切換
  

• 零拷貝流程:使用sendfile()

  1. sendfile(): Disk → Kernel buffer (DMA)
  2. sendfile(): Kernel buffer → Network card (DMA或直接描述符傳遞)
  總共:2次DMA + 0次CPU拷貝 + 2次上下文切換
  

• 實際程式碼對比:

  // 傳統方式
  char buffer[4096];
  while ((n = read(fd, buffer, 4096)) > 0) {
      write(socket, buffer, n);  // 2次CPU拷貝
  }
  
  // 零拷貝
  sendfile(socket, fd, NULL, file_size);  // 0次CPU拷貝
  

• 效能提升:
  • 傳統方式:100MB檔案,CPU使用率30%,吞吐量500MB/s
  • 零拷貝:100MB檔案,CPU使用率5%,吞吐量2GB/s

6. 記憶體映射 I/O vs 標準 I/O (Memory-Mapped I/O vs Standard I/O)

詳細說明:

• mmap範例:隨機存取大檔案

  // 映射檔案到記憶體
  int fd = open("data.db", O_RDWR);
  char* addr = mmap(NULL, file_size, PROT_READ|PROT_WRITE,
                    MAP_SHARED, fd, 0);
  
  // 像存取陣列一樣存取檔案
  addr[1000] = 'A';      // 直接修改offset 1000
  addr[999999] = 'B';    // 跳到offset 999999,無需seek
  
  munmap(addr, file_size);
  

• 標準I/O範例:順序讀取

  FILE* fp = fopen("data.txt", "r");
  char buffer[4096];
  while (fread(buffer, 1, 4096, fp) > 0) {
      process(buffer);
  }
  fclose(fp);
  

• 效能對比(100MB檔案,隨機存取10000次):
  • mmap:約100ms(頁面錯誤後幾乎零開銷)
  • read/write + lseek:約5000ms(每次都要系統呼叫)
• 共享記憶體應用:多程序通訊

  // 程序A
  void* shared = mmap(NULL, SIZE, PROT_READ|PROT_WRITE,
                      MAP_SHARED|MAP_ANONYMOUS, -1, 0);
  fork();  // 子程序繼承映射
  
  // 父子程序共享這塊記憶體,無需pipe或socket
  

• 注意事項:
  • mmap檔案修改不會立即寫入磁碟,需要msync()強制同步
  • 映射大檔案可能耗盡虛擬記憶體位址空間(32位元系統)
  • 適合大檔案(>幾MB),小檔案反而比read/write慢

記憶體管理

5. 分頁 vs 分段 (Paging vs Segmentation)

詳細說明：

• 分頁範例：一個程式需要17KB記憶體，在4KB分頁系統中會分配5頁（20KB），浪費3KB。
• 分段範例：程式的程式碼、資料、堆疊分別放在不同的段，每段有自己的起始位址和長度。
• 混合使用：現代x86-64系統同時支援分頁和分段，但主要使用分頁。

6. 寫回 vs 寫透 (Write-back vs Write-through)

詳細說明：

• 寫回範例：你在Word編輯文件，修改先存在記憶體，過一段時間或關閉時才存到硬碟。
• 寫透範例：每次輸入都立即存檔，確保不會遺失任何內容，但存檔頻繁會變慢。
• 混合策略：資料庫的Write-Ahead Log（WAL）先寫日誌（寫透），資料頁面用寫回。

7. 靜態分配 vs 動態分配 (Static vs Dynamic Allocation)

詳細說明：

• 靜態範例：宣告 char buffer[1024]; 直接在stack上配置1024 bytes，編譯時就決定了。
• 動態範例：std::vector 初始可能只配置8個元素空間，使用時自動擴充到16、32、64...
• 記憶體區域：
  • 靜態：放在 Stack（區域變數）或 Data Segment（全域變數）
  • 動態：放在 Heap

排程策略

8. 搶佔式 vs 非搶佔式 (Preemptive vs Non-preemptive)

詳細說明：

• 搶佔式範例：你在看影片時下載檔案，作業系統每10毫秒切換一次，兩個程式都能執行。
• 非搶佔式範例：舊系統執行一個程式，必須等它執行完或主動sleep才能執行下一個。
• 即時系統：飛機控制系統用搶佔式，確保緊急任務（如引擎故障）能立即處理。

9. FCFS vs SJF vs RR (First-Come First-Served vs Shortest Job First vs Round Robin)

詳細說明：

• FCFS範例：3個工作：A(24秒)、B(3秒)、C(3秒)，B和C必須等A完成，平均等待時間=(0+24+27)/3=17秒
• SJF範例：同樣3個工作，執行順序變成B(3秒)、C(3秒)、A(24秒)，平均等待時間=(0+3+6)/3=3秒
• RR範例：時間片4秒，執行順序：A→B→C→A→A→A→A→A→A，每個工作輪流執行

10. 時間分享 vs 空間分享 (Time-sharing vs Space-sharing)

詳細說明：

• 時間分享範例：一顆4核CPU同時運行100個程序，每個程序輪流使用CPU。
• 空間分享範例：8GB記憶體分給4個程式，每個程式固定使用2GB。
• 混合使用：現代系統CPU用時間分享，記憶體用空間分享。

並行控制

11. 鎖 vs 無鎖 (Lock-based vs Lock-free)

詳細說明：

• 鎖範例：銀行帳戶轉帳時，先鎖定兩個帳戶，完成轉帳後解鎖。

  mutex.lock();
  balance += amount;
  mutex.unlock();
  

• 無鎖範例：多個執行緒更新計數器，使用CAS操作。

  do {
      old_value = counter;
      new_value = old_value + 1;
  } while (!compare_and_swap(&counter, old_value, new_value));
  

• 效能比較：無競爭時鎖快；高競爭時無鎖快。

12. 悲觀鎖 vs 樂觀鎖 (Pessimistic vs Optimistic Locking)

詳細說明：

• 悲觀鎖範例：電影訂票系統，選座位時立即鎖定，避免同時被兩人選到。

  BEGIN TRANSACTION;
  SELECT * FROM seats WHERE id = 10 FOR UPDATE;
  UPDATE seats SET booked = true WHERE id = 10;
  COMMIT;
  

• 樂觀鎖範例：Wiki編輯，編輯時不鎖定，提交時檢查版本號是否變更。

  UPDATE articles 
  SET content = '新內容', version = version + 1
  WHERE id = 100 AND version = 5;
  -- 如果version已經變更，UPDATE會失敗
  

• 選擇原則：衝突率低選樂觀鎖，衝突率高選悲觀鎖。

13. 粗粒度鎖 vs 細粒度鎖 (Coarse-grained vs Fine-grained Locking)

詳細說明：

• 粗粒度鎖範例：整個購物網站共用一個庫存鎖，任何人修改任何商品庫存都要等待。

  with global_lock:
      update_inventory(product_id, quantity)
  

• 細粒度鎖範例：每個商品有自己的鎖，修改A商品不影響B商品。

  with product_locks[product_id]:
      update_inventory(product_id, quantity)
  

• 死鎖風險：細粒度鎖如果同時鎖定多個資源需注意順序，避免死鎖。

資料結構選擇

14. 陣列 vs 鏈結串列 (Array vs Linked List)

詳細說明：

• 陣列範例：學生成績表，可以直接查詢第50個學生 grades[49]，但插入新學生需要移動後面所有元素。
• 鏈結串列範例：播放清單，可以輕鬆插入新歌曲，但要找第50首歌需要從頭走訪。
• 效能對比：
  • 陣列存取：arr[1000] 一次記憶體存取
  • 鏈結串列存取：需要走訪1000次指標
• 記憶體使用：鏈結串列每個節點需要額外8 bytes（64位元）儲存指標

15. 堆疊 vs 佇列 (Stack vs Queue)

詳細說明：

• 堆疊範例：函式呼叫 main() → funcA() → funcB()，funcB執行完回到funcA，funcA執行完回到main。

  void funcA() {
      int x = 10;  // 壓入stack
      funcB();
  }  // x彈出stack
  

• 佇列範例：訊息系統，使用者依序發送訊息1、2、3，伺服器依序處理1、2、3。

  queue.put("訊息1")
  queue.put("訊息2")
  msg = queue.get()  # 取得"訊息1"
  

• 變體：
  • 雙端佇列（Deque）：兩端都可以插入和刪除
  • 優先佇列（Priority Queue）：依優先權而非順序取出

16. Hash Table vs Tree (雜湊表 vs 樹)

詳細說明：

• Hash Table範例：查詢學生成績，用學號hash後直接找到。

  grades = {"A001": 85, "A002": 92}
  score = grades["A001"]  # O(1)
  

• Tree範例：查詢薪水在50K-80K的員工，可以用樹快速範圍查詢。

  SELECT * FROM employees WHERE salary BETWEEN 50000 AND 80000;
  -- 使用B-tree索引
  

• 碰撞處理：Hash Table碰撞時用鏈結串列（Chaining）或開放定址法（Open Addressing）。
• 實務應用：資料庫同時使用Hash Index（點查詢）和B-tree Index（範圍查詢）。

快取策略

17. LRU vs LFU vs FIFO (替換演算法)

詳細說明：

• LRU範例：瀏覽器快取，最近看過的網頁保留，很久沒看的清除。

  快取容量3，存取順序：A B C A D
  - 初始：[]
  - A：[A]
  - B：[A, B]
  - C：[A, B, C]
  - A：[B, C, A]（A移到最前）
  - D：[C, A, D]（移除B）
  

• LFU範例：影片推薦系統，記錄觀看次數，保留熱門影片。

  存取次數：A(5次) B(2次) C(8次) D(1次)
  快取滿時，移除D（最少被存取）
  

• FIFO範例：簡單的緩衝區，先進先出。

  快取容量3，存取順序：A B C D
  - D進入時，移除A（最早的）
  - 結果：[B, C, D]
  

18. 直接映射 vs 全相聯 vs 組相聯 (Cache Mapping)

詳細說明：

• 直接映射範例：記憶體位址0x1000只能映射到快取位置0，位址0x2000也映射到位置0，會產生衝突。

  快取8個位置（0-7）
  位址0x08 → 位置0
  位址0x10 → 位置0（衝突！）
  

• 全相聯範例：任何記憶體位址都能放入任何快取位置，需要比較所有tag。

  位址0x1000可以放在位置0-7的任何一個
  查找時需要檢查全部8個位置
  

• 組相聯範例：8-way組相聯，快取分成多組，每組8個位置。

  64個快取位置，分成8組
  位址0x1000 → 映射到組0，可放組0的任何8個位置
  查找時只需檢查組0的8個位置
  

網路與通訊

19. Push vs Pull (推送 vs 拉取)

詳細說明：

• Push範例：Line訊息，朋友傳訊息時伺服器立即推送到你的手機。

  // WebSocket Push
  socket.on('message', (data) => {
      displayMessage(data); // 收到訊息立即顯示
  });
  

• Pull範例：Email客戶端每15分鐘自動檢查一次新郵件。

  while True:
      emails = fetch_new_emails()  # 主動拉取
      time.sleep(900)  # 等15分鐘
  

• 混合模式：
  • Long Polling：Pull但保持連接直到有新資料
  • Server-Sent Events（SSE）：單向Push

20. TCP vs UDP

詳細說明：

• TCP範例：下載檔案，必須確保每個byte都正確且依序到達。

  三次握手：
  1. Client → Server: SYN
  2. Server → Client: SYN-ACK
  3. Client → Server: ACK
  然後才能傳輸資料
  

• UDP範例：視訊通話，掉幾個封包無所謂，重要的是即時性。

  sock.sendto(video_frame, (ip, port))  # 直接發送
  # 不等待確認，不重傳遺失的封包
  

• 效能對比：
  • TCP：100ms延遲（含握手、確認）
  • UDP：10ms延遲（直接發送）
• 實務應用：
  • HTTP/3使用QUIC（基於UDP但加入可靠性）
  • 遊戲混用：重要資料用TCP，位置更新用UDP

21. 短連接 vs 長連接 (Short-lived vs Persistent Connection)

詳細說明：

• 短連接範例：每次瀏覽網頁都建立新連接。

  1. 建立TCP連接（三次握手）
  2. 發送HTTP請求
  3. 接收HTTP回應
  4. 關閉TCP連接（四次揮手）
  

• 長連接範例：聊天應用，建立一次WebSocket連接後持續使用。

  const ws = new WebSocket('wss://chat.example.com');
  ws.send('Hello');  // 使用已建立的連接
  ws.send('World');  // 重複使用同一連接
  

• HTTP演進：
  • HTTP/1.0：短連接
  • HTTP/1.1：引入 Connection: keep-alive 支援長連接
  • HTTP/2：多路複用，一個連接處理多個請求
• 心跳機制：長連接需要定期發送心跳包，確保連接存活。

  while True:
      send_heartbeat()
      time.sleep(30)
  

儲存策略

22. 順序讀寫 vs 隨機讀寫 (Sequential vs Random Access)

詳細說明：

• 順序讀寫範例：寫日誌檔案，每次追加到檔案尾端。

  with open('log.txt', 'a') as f:
      f.write('新的日誌\n')  # 順序寫入
  

• 隨機讀寫範例：資料庫更新，可能要存取不同位置的資料。

  UPDATE users SET name = 'Alice' WHERE id = 1000;
  UPDATE users SET name = 'Bob' WHERE id = 50;
  -- 存取位置可能相距很遠
  

• 效能差異（HDD）：
  • 順序讀取：100-200 MB/s
  • 隨機讀取：0.5-2 MB/s（慢100倍！）
• SSD優勢：
  • 順序讀取：500-3500 MB/s
  • 隨機讀取：300-3000 MB/s（差異小很多）
• 優化策略：資料庫使用寫前日誌（WAL），隨機寫轉換為順序寫。

23. 集中式 vs 分散式 (Centralized vs Distributed)

詳細說明：

• 集中式範例：小型電商網站，單一伺服器處理所有訂單。

  [所有使用者] → [單一伺服器] → [單一資料庫]
  伺服器故障 = 整個網站停擺
  

• 分散式範例：YouTube影片存儲，分散在全球數千台伺服器。

  [美國使用者] → [美國伺服器]
  [台灣使用者] → [台灣伺服器]
  任一伺服器故障不影響其他地區
  

• CAP定理：分散式系統無法同時滿足一致性、可用性、分區容錯性。
• 分散式挑戰：
  • 資料同步：如何保持各節點資料一致
  • 時鐘同步：不同伺服器時間可能不一致
  • 網路分區：節點間無法通訊時如何處理

24. 複製 vs 分片 (Replication vs Sharding)

詳細說明：

• 複製範例：電商網站有3個資料庫副本。

  Master DB（主）：處理寫入
  Slave DB 1（從）：處理讀取
  Slave DB 2（從）：處理讀取
  → 讀取效能提升3倍，任一故障不影響服務
  

• 分片範例：社群網站依使用者ID分片。

  Shard 1：使用者 ID 0-999999
  Shard 2：使用者 ID 1000000-1999999
  Shard 3：使用者 ID 2000000-2999999
  → 每個分片只處理部分資料，容量可無限擴展
  

• 混合使用：每個分片內部做複製。

  Shard 1 Master + 2 Slaves
  Shard 2 Master + 2 Slaves
  → 既能擴容又能容錯
  

• 分片鍵選擇：
  • 好的分片鍵：使用者ID（均勻分佈）
  • 壞的分片鍵：註冊日期（新使用者集中在一個分片）

一致性模型

25. 強一致性 vs 最終一致性 (Strong vs Eventual Consistency)

詳細說明：

• 強一致性範例：銀行轉帳，A轉1000元給B，必須確保兩邊同時生效。

  1. A帳戶 -1000（所有副本都確認）
  2. B帳戶 +1000（所有副本都確認）
  3. 交易完成
  如果任一步驟失敗，整個交易回滾
  

• 最終一致性範例：Facebook貼文按讚。

  時間 0秒：Alice按讚，美國伺服器記錄
  時間 1秒：按讚數顯示+1（在美國）
  時間 5秒：資料同步到亞洲伺服器
  時間 5秒：按讚數顯示+1（在台灣）
  → 短期內不同地區看到不同數字，但最終會一致
  

• 一致性級別（由強到弱）：
  1. 線性一致性（Linearizability）：最強
  2. 順序一致性（Sequential Consistency）
  3. 因果一致性（Causal Consistency）
  4. 最終一致性（Eventual Consistency）：最弱

26. CP vs AP (CAP定理)

詳細說明：

• CAP定理：一致性（Consistency）、可用性（Availability）、分區容錯性（Partition Tolerance）三者只能取其二。
• CP範例：訂票系統，網路分區時寧可停止售票，也不能超賣。

  情境：兩個資料中心失去連接
  CP做法：停止售票，等網路恢復
  → 確保不會把同一個座位賣給兩個人
  

• AP範例：購物車，網路分區時繼續加商品，稍後合併。

  情境：使用者在美國加商品A，網路分區
  AP做法：先加入本地購物車
  → 稍後網路恢復，與其他資料中心的購物車合併
  可能出現：短期內不同地區看到不同購物車內容
  

• 實務選擇：
  • 金融：選CP（寧可暫停服務，不能出錯）
  • 社群：選AP（暫時不一致沒關係，服務可用更重要）

執行模式

27. 單執行緒 vs 多執行緒 vs 多程序 (Single-threaded vs Multi-threaded vs Multi-process)

詳細說明：

• 單執行緒範例：Node.js使用事件迴圈處理多個請求。

  // 雖然只有一個執行緒，但可以處理多個請求
  server.on('request', (req, res) => {
      // 非阻塞I/O，不會卡住其他請求
      fs.readFile('file.txt', (err, data) => {
          res.end(data);
      });
  });
  

• 多執行緒範例：影片處理軟體，每個執行緒處理一段影片。

  import threading
  
  def process_chunk(start, end):
      # 處理影片的一部分
      pass
  
  threads = []
  for i in range(4):  # 4個執行緒
      t = threading.Thread(target=process_chunk, args=(i*100, (i+1)*100))
      threads.append(t)
      t.start()
  

• 多程序範例：Chrome每個分頁一個程序，一個分頁崩潰不影響其他。

  from multiprocessing import Process
  
  def worker(data):
      # 完全獨立的處理
      pass
  
  processes = []
  for i in range(4):
      p = Process(target=worker, args=(data[i],))
      processes.append(p)
      p.start()
  

• 效能對比：
  • 單執行緒：1核心100%，其他核心閒置
  • 多執行緒：4核心各100%（4倍效能）
  • 多程序：4核心各100%，但記憶體佔用是多執行緒的4倍

28. 事件驅動 vs 多執行緒 (Event-driven vs Multi-threaded)

詳細說明：

• 事件驅動範例：Node.js處理10000個同時連接。

  // 單執行緒處理多個連接
  const server = http.createServer();
  server.on('request', async (req, res) => {
      const data = await db.query();  // 非阻塞
      res.end(data);
  });
  // 10000個連接只需要一個執行緒
  

• 多執行緒範例：Apache為每個連接建立執行緒。

  連接1 → 執行緒1
  連接2 → 執行緒2
  連接3 → 執行緒3
  ...
  → 10000個連接需要10000個執行緒（記憶體爆炸）
  

• C10K問題：如何讓一台伺服器處理10000個同時連接。
  • 傳統多執行緒：失敗（記憶體不足）
  • 事件驅動：成功（低記憶體佔用）
• 混合模式：
  • Node.js：主執行緒事件驅動 + Worker執行緒處理CPU密集
  • Nginx：事件驅動處理連接 + Worker程序平行處理

29. 同步執行 vs 平行執行 vs 並發執行 (Synchronous vs Parallel vs Concurrent)

詳細說明：

• 同步執行範例：煮飯流程。

  煮飯()    # 30分鐘
  炒菜()    # 20分鐘
  煮湯()    # 15分鐘
  總時間：65分鐘
  

• 平行執行範例：三個人同時煮。

  # 3個CPU核心
  Thread1: 煮飯()  # 30分鐘
  Thread2: 炒菜()  # 20分鐘
  Thread3: 煮湯()  # 15分鐘
  總時間：30分鐘（最長的任務）
  

• 並發執行範例：一個人快速切換。

  # 單核心，快速切換
  0-10分鐘：煮飯
  10-15分鐘：炒菜
  15-20分鐘：煮湯
  20-25分鐘：煮飯
  ...（不斷切換）
  總時間：接近65分鐘（因為有切換開銷）
  

• Python範例：

  # 同步
  result1 = task1()
  result2 = task2()
  
  # 並發（I/O）
  import asyncio
  result1, result2 = await asyncio.gather(task1(), task2())
  
  # 平行（CPU）
  from multiprocessing import Pool
  pool = Pool(4)
  results = pool.map(task, data)
  

設計模式

30. 單體 vs 微服務 (Monolithic vs Microservices)

詳細說明：

• 單體範例：傳統電商系統。

  單一應用程式包含：
  - 使用者管理
  - 商品管理
  - 訂單處理
  - 付款處理
  - 物流追蹤
  → 改一個功能要重新部署整個應用
  

• 微服務範例：Netflix架構。

  獨立服務：
  - User Service（使用者服務）
  - Video Service（影片服務）
  - Recommendation Service（推薦服務）
  - Billing Service（計費服務）
  → 每個服務可以獨立開發、部署、擴展
  

• 演進過程：
  1. 小型新創：單體（快速開發）
  2. 業務成長：單體開始變慢、難維護
  3. 拆分服務：逐步轉為微服務
• 挑戰：
  • 服務間通訊：需要API Gateway
  • 資料一致性：分散式交易
  • 服務發現：如何找到其他服務
  • 監控除錯：需要分散式追蹤

31. 拉模型 vs 推模型 (Pull vs Push Model - 資料流)

詳細說明：

• 拉模型範例：Kafka消費者。

  # 消費者主動拉取
  while True:
      messages = consumer.poll(timeout=1.0)
      for message in messages:
          process(message)
      # 處理完一批再拉取下一批，速度自己控制
  

• 推模型範例：WebSocket推送。

  // 伺服器主動推送
  socket.on('connect', () => {
      socket.emit('newMessage', message);  // 有訊息就推送
  });
  // 消費者被動接收，無法控制速度
  

• 背壓問題：推模型可能壓垮慢速消費者。

  生產者：每秒產生10000條訊息
  消費者：每秒只能處理1000條
  → 推模型：消費者記憶體爆炸
  → 拉模型：消費者慢慢拉，不會過載
  

• 混合模式：
  • RabbitMQ：支援推和拉兩種模式
  • gRPC Streaming：可以雙向推送

選擇決策樹

選擇技術時的考量順序：

1. 業務需求
   ├─ 一致性要求高？ → 強一致性、CP
   └─ 可用性要求高？ → 最終一致性、AP

2. 資料特性
   ├─ 資料量大？ → 分片
   ├─ 讀多寫少？ → 複製 + 快取
   └─ 寫多讀少？ → 寫優化的資料結構

3. 效能需求
   ├─ 低延遲？ → 快取、異步
   ├─ 高吞吐？ → 平行處理、批次
   └─ 即時性？ → Push、WebSocket

4. 系統規模
   ├─ 小型？ → 單體、集中式
   ├─ 中型？ → 垂直擴展、複製
   └─ 大型？ → 微服務、分散式

5. 團隊能力
   ├─ 經驗少？ → 選擇簡單方案
   └─ 經驗多？ → 可選複雜但效能好的方案

實務建議

1. 不要過度設計

• 從簡單開始，需要時再優化
• 單體 → 垂直擴展 → 水平擴展 → 微服務

2. 測量再優化

• 先測量瓶頸在哪
• 不要憑感覺優化

3. 權衡取捨

• 沒有完美方案，只有適合的方案
• 考慮維護成本、開發時間、效能

4. 關注變化

• 技術持續演進
• 保持學習，適時調整

5. 文件化決策

• 記錄為什麼選擇這個方案
• 未來回顧時有依據

總結對照表

最後提醒： 選擇技術方案沒有絕對的對錯，關鍵是：

1. 理解每種方案的優缺點
2. 評估你的實際需求和限制
3. 做出合理的權衡
4. 持續監控和優化

希望這份整理能幫助你在系統設計時做出更好的決策！ 🚀