Worker Concurrency
工作程序並行上限
工作程序並行上限是多個消費者同時能執行的工作數。設定上限可以保護伺服器，以及工作會呼叫的其他服務。
queue depth + max active consumers + claim/lease + dependency capacity -> throughputqueue depth + max active consumers + claim/lease + dependency capacity -> throughputJOB另一個例子
收據佇列有 120 則訊息。三個工作程序各取一則可用訊息，因此一次最多產生三張收據。佇列變長時，自動擴縮工具可以增加工作程序。工作池不能超過儲存服務能安全承受的上限。
主要部分
- 01佇列長度
- 02工作程序池
- 03執行中工作上限
- 04訊息領取或租期
- 05下游服務容量
- 06增減工作程序訊號
什麼時候用
排隊工作彼此獨立，而且可以一起處理時，可以設定同時處理上限。上限要依實測工作成本、排隊時間，以及下一個服務能安全處理的工作量決定。
什麼時候不要用
工作共用一個不能並行使用的資源，或必須照順序處理時，不要一直增加工作程序。工作程序太多，可能增加重複處理，也可能壓垮相依服務。
程式裡的名稱
queue depth + max active consumers + claim/lease + dependency capacity -> throughput 上線前要檢查
檢查介面約定、任何情況都不能破壞的規則、授權與輸入限制。測試重試、重複執行只生效一次、逾時與部分失敗。驗證資料完整性、相容性、監控、復原與回復上一版。
預期成果：為這套系統設計或檢查 工作程序並行上限 (Worker Concurrency)，並讓資料保持正確、安全且容易維護。 使用者情境：收據佇列有 120 則訊息。三個工作程序各取一則可用訊息，因此一次最多產生三張收據。佇列變長時，自動擴縮工具可以增加工作程序。工作池不能超過儲存服務能安全承受的上限。 技術概念或控制措施：工作程序並行上限 (Worker Concurrency)。 適用理由：排隊工作彼此獨立，而且可以一起處理時，可以設定同時處理上限。上限要依實測工作成本、排隊時間，以及下一個服務能安全處理的工作量決定。 不應使用的情況：工作共用一個不能並行使用的資源，或必須照順序處理時，不要一直增加工作程序。工作程序太多，可能增加重複處理，也可能壓垮相依服務。 工程要求：定義輸入、輸出、介面約定，以及任何情況都不能破壞的規則。說明授權與輸入檢查範圍。定義失敗、逾時、重試和重複執行只生效一次的規則。也要定義資料搬移與相容限制。 營運要求：加入監控訊號與隱藏敏感資料的記錄。設定容量上限並寫好操作手冊。測試復原與回復上一版的流程。 驗收條件：介面約定與失敗路徑測試通過。重試或部分失敗時，資料與授權規則仍正確。效能上限、監控、復原與回復上一版的方法都已驗證。 證據與限制（證據邊界）：沒有一份官方標準能管到全部內容。不同團隊、平台或框架的用法可能不同。 待確認：程式執行環境、資料位置、流量形態、資料一致需求和安全邊界。也要確認相容期間、服務目標（SLO）與回復上一版的限制。
檢查這份需求
請 AI 程式助手檢查目前如何使用 工作程序並行上限 (Worker Concurrency)。 定義：工作程序並行上限是多個消費者同時能執行的工作數。設定上限可以保護伺服器，以及工作會呼叫的其他服務。 正式環境檢查：檢查介面約定、任何情況都不能破壞的規則、授權與輸入限制。測試重試、重複執行只生效一次、逾時與部分失敗。驗證資料完整性、相容性、監控、復原與回復上一版。 修改程式前，先列出看到的證據、缺口、嚴重程度，以及最小且安全的修正。