在分散式系統中，錯誤處理常常是我們第一個想到的事（Timeout、Retry、冪等性）。但實際上，系統掛掉的原因，更多時候是「流量過大」把自己或下游撐爆。
要同時顧好 上游請求進來時 Worker 能存活，以及 下游服務不被一波流量打掛，Temporal Worker 提供了兩個重要的保護機制：Concurrency Control（併發控制） 與 Rate Control（速率控制）。

1. Concurrency Control 與 Rate Control 的本質

• Concurrency（併發）：資源保護機制（限制同時處理中的任務數，避免 CPU/記憶體/DB 連線被吃光）。
• Rate（速率）：流量整形與配額保護（限制單位時間任務數，平滑尖峰、對齊下游 QPS/配額）。
• 兩者的互動：
  • 缺少併發限制 → 瞬間爆量易把 Worker/DB 壓垮。
  • 併發太大 → CPU/記憶體/DB 連線耗盡、延遲飆升。
  • 併發太小 → ScheduleToStart 排隊上升、吞吐不足。
  • 缺少速率限制 → 全域 QPS 易超標打掛下游。
  • 速率太低 → 任務堆積、尾延遲上升。
  • 速率太高 → 下游產生 429/503、配額超標。

1.2 Concurrency Control：控制同時併發數

Concurrency 指的是 Worker 同時可以執行多少個任務。
舉例來說：

• 如果 Worker 一次開 100 個 thread 同時打資料庫，DB 連線池可能瞬間被用光，其他服務也跟著掛。
• 合理做法是先限制併發，例如「最多 10 個 Activity 同時跑」，確保機器資源跟連線池不會瞬間爆掉。

1.3 Rate Control：控制每秒執行速率

Rate 指的是 Worker 每秒最多可以處理多少次任務。
舉例來說：

• 設定「每秒最多 50 次」，尖峰時 Worker 會以固定節奏往下游送，不會在一秒鐘內衝出 200 次請求把資料庫打掛。
• 這對於後端 DB 或外部 API 服務特別重要，因為很多系統都有 QPS 上限，沒控速就會直接超標。

2. Concurrency Policy & Rate Policy 的類型

3. Concurrency + Rate Control 的設計思維

• 只設定 Concurrency → 能保護自己，不會瞬間把 Worker 或 DB 壓爆。
• 只設定 Rate → 能保護下游，但如果 Worker 單次併發開太大，還是可能吃滿執行緒。
• 兩者都設 → 最穩健，但也不要一開始就鎖太死。先從保守數值起跑，透過監控（metrics / dashboard）觀察後，再慢慢調整。
• 須與 Timeout/Retry 協同：過短 Timeout、過密 Retry 配上過大的併發/速率，容易形成重試風暴。
• 參數提示：
  • ScheduleToStart 高且 CPU 寬鬆 → 提升併發或擴 Worker；
  • 429/503 上升 → 下修單機或全域速率、放大退避；
  • CPU/GC 飆高 → 降併發、將部分 Local Activity 外移、或擴容；
  • 尾延遲高但下游正常 → 提升併發或擴 Worker，並檢查速率是否過低。
  • 協同校準：MaxWorkerActivitiesPerSecond × Worker 數 ≤ MaxTaskQueueActivitiesPerSecond ≤ 下游限制。

3.1 常見陷阱

1. 只開併發、不限速
   • Worker 撐得住，但尖峰期會直接把下游或資料庫打爆。
   • 典型結果：DB 出現 Connection refused、CPU 飆 100%。
2. 只限速、不限併發
   • 流量總量是受控的，但瞬間爆量還是可能吃光執行緒。
   • 典型結果：Worker 卡死、延遲爆炸。
3. 數值一開始就亂設
   • 設太小 → 系統看起來慢吞吞，還沒發揮硬體效能。
   • 設太大 → 撐不住就雪崩。
   • 最佳做法：觀測 → 微調 → 再觀測。

4. 程式碼範例

// 建立 WorkerFactory 與 Worker，並同時設定 Concurrency 與 Rate 上限
WorkerFactory factory = WorkerFactory.newInstance(client);

WorkerOptions workerOptions = WorkerOptions.newBuilder()
    // Concurrency：同時處理數（以機器資源/DB 連線池為邊界）
    .setMaxConcurrentActivityExecutionSize(50)        // 單 Worker 同時執行的 Activity 上限
    .setMaxConcurrentWorkflowTaskExecutionSize(20)    // 同時處理的 Workflow Task 上限
    .setMaxConcurrentLocalActivityExecutionSize(20)   // Local Activity 上限
    // Rate：速率上限（單機與 Task Queue 全域）
    .setMaxWorkerActivitiesPerSecond(50.0)            // 每個 Worker 的每秒 Activity 上限（單機）
    .setMaxTaskQueueActivitiesPerSecond(100.0)        // 整個 Task Queue 的每秒 Activity 上限（多 Worker 共享）
    .build();

Worker worker = factory.newWorker("MAIN_TASK_QUEUE", workerOptions);
worker.registerWorkflowImplementationTypes(MyWorkflowImpl.class);
worker.registerActivitiesImplementations(new MyActivitiesImpl());

factory.start();

5. 結語

在 Temporal 裡，Timeout 保護 Worker、Retry 爭取恢復；而併發守住機器、速率對齊下游，搭配監控與調整，才能在高流量下維持穩定。

• Day08 - 分散式流程的順序性（Ordering）挑戰
• Day09 - 不管是一次、一百次還是一萬次，我還是想跟你說我愛...冪等性 （Idempotency）
• Day10 - 重試之前先判斷：錯誤分類與處理路徑設計
• Day11 - 不要讓流程無限等：Timeout Policy 的設計思維
• Day12 - 錯誤難免，重試要有策略：Retry Policy 的設計思維
• Day13 - 流量高峰不失控：併發與限速的設計指南

好的，這幾天一口氣展開分散式流程會遇到的關鍵課題，藉此讓我們不僅在開發上有框架，也在維運的設計上有了依據參考。

下一篇，要來解決分散式交易的問題，讓我們談談 Saga Pattern！