延展性模式

深入瞭解結構正確的 可靠性 → 延展性和產能計畫

模式

要尋找的位置良好的外觀
SOQL 查詢效率使用關係查詢 (Contacts、Cases__r) 合併查詢,而非使用每個相關物件的個別查詢。針對每個交易查詢所有必要資料一次。目標為同步交易中的 <50 個查詢,非同步交易中的 <100 個 (限制:100 同步,200 非同步)。維持低於限制的 30-50% 緩衝時間。
DML 作業大量處理收集記錄至「清單」,為每個交易的每個物件類型執行單一 DML 陳述式。使用 Database.insert/update/delete 搭配控制部分成功行為的 allOrNone 參數。目標為每個交易 <75 個 DML 陳述式 (限制:150).批次會將 DML 耗用從 N 個陳述式減少為 1。
堆疊大小管理僅查詢必要欄位 (避免 SELECT * 模式)。以區塊的方式處理大型結果集。處理後清除集合至自由記憶體。同步環境中的目標 <4MB 堆疊 (限制:6MB)、<8MB 非同步 (限制:12MB)。堆疊超過的錯誤表示需要切分或串流模式。
CPU 時間最佳化將迴圈中的運算複雜度降到最低。使用對應地圖 (O(1)),而非巢狀清單迭代 (O(n2))。將繁量計算卸載至非同步內容。同步交易中的目標 <7,000ms CPU (限制:10,000 毫秒)、<40,000 毫秒非同步 (限制:60,000 毫秒)。
SOQL 查詢列傳回合理結果集大小的設計查詢。使用 LIMIT 子句來限制結果。目標為同步環境中的每個查詢 <25,000 列 (限制:50,000).即將達到限制的查詢應使用分頁,或移至使用批次 Apex 或 Queueable 的非同步處理。
API 呼叫配置透過「系統概觀」監視 24 小時 API 限制耗用。批次 API 作業,而非逐筆記錄呼叫。使用平台快取快取頻繁存取的參照資料。目標為 <70% 的每日 API 限制以容納高峰。API 限制會因版本和授權計數而有所不同。
呼叫限制合併外部呼叫:在外部系統支援時,將多個記錄批次至單一 API 要求。實作要求排列以序列化呼叫。遵循每個交易的總呼叫時間 120 秒。限制:每個交易 100 個呼叫。為呼叫繁多的整合設計非同步處理。
程式碼 (Apex、Aura、LWC)實作大量處理模式:處理非個別記錄的集合、在 Maps 中查詢一次並快取、為每個物件類型執行單一 DML。使用關係查詢來最小化 SOQL 耗用。套用有效率的演算法,避免在大型資料集中產生巢狀迴圈。

反模式

要尋找的位置看起來怎麼壞
迴圈中的 SOQL問題:在內部針對處理記錄集合的迴圈執行 SOQL 查詢。影響:超過 100 筆記錄的查詢限制錯誤 (限制:每個交易 100 次查詢)。解決方法:在迴圈之前查詢一次,將結果儲存在「對應」按關係欄位進行鍵值。從「對應內部迴圈」對應 (大量處理模式)。
迴圈中的 DML問題:在迴圈中執行插入/更新/刪除陳述式。影響:超過 150 筆記錄的 DML 限制錯誤 (限制:每個交易 150 個 DML 陳述式)。解決方法:在迴圈內收集記錄至「清單」,在迴圈完成後執行單一 DML 陳述式。
無管理員限制緩衝時間問題:在正常情況下,設計耗用 95% 以上管理員限制的交易。影響:輕量載入期間的生產失敗增加,邊緣個案沒有容量。解決方法:將 70% 的限制目標設為作業上限。為高峰與邊緣個案保留 30% 緩衝。
巢狀迴圈卡塞西亞產品問題:嵌套迴圈會迭代兩個大型集合,以建立 O(n2) 作業。影響:CPU 限制超過錯誤,暫時物件超過堆疊限制。解決方法:使用以地圖為基礎的對應,將 O(n2) 轉換為 O(n)。收集外部迴圈索引鍵、查詢相關記錄一次,並在內部迴圈中對應。
堆疊累積問題:將大型查詢載入至記憶體,而無須在區塊中處理。影響:堆疊限制超過錯誤 (6MB 同步,12MB 非同步)。解決方法:僅查詢必要欄位。在每個批次後批次處理清除集合。將 QueryLocator 與批次 Apex 搭配使用,以處理數百萬筆記錄。
無欄位級篩選問題:僅在需要子集時選取所有欄位 (明確或隱含)。影響:過度堆疊耗用、查詢執行速度變慢、SOQL 列限制不必要接近。解決方法:僅選取處理所需的欄位。使用關係標記法以在單一查詢中提取相關資料,而非個別查詢。
同步處理過多使用問題:在使用者交易中同步處理大量資料。影響:使用者等待多秒作業,CPU/堆疊限制超過封鎖使用者。解決方法:將粗體處理移至非同步內容 (批次、可排列、平台事件)。使用狀態輪詢提供使用者立即回應。

模式

要尋找的位置良好的外觀
非同步處理使用批次 Apex 處理大量記錄 (數百萬筆)。將 Apex 用於具有鏈結的複雜多步驟協調流程。使用「平台事件」進行以事件為導向的分離。使用「排程的 Apex」進行定期維護。比對非同步模式以使用 case:批次表示量、可排入複雜度表示,事件表示分離。
批次 Apex 實作傳回選擇性 QueryLocator 的設計起始方法,以將已處理的記錄最小化。根據記錄複雜度設定批次大小 (200-2,000 個記錄每個執行)。僅在需要時實作狀態介面,因為其會減少輸送量。監視 AsyncApexJob 以瞭解成功/失敗。批次提供每個區段的專用管理員限制。
平台事件結構發佈需要下游處理的狀態變更事件。透過 CometD 在平台事件物件或外部訂閱者上使用 Apex 觸發進行訂閱。設計 idempotent 訂閱者 (重複執行可能會多次傳送事件)。使用 72 小時保留來復原暫時訂閱者失敗。
以日期為基礎的分割在時間範圍中處理資料:本月、上一季、今年。將歷程記錄資料歸檔至大型物件或外部儲存空間。以時間為基礎的分割可讓並列批次工作同時處理不同的日期範圍。大多數查詢自然會依日期篩選,以提高效率。
記錄類型分割獨立處理不同的記錄類型。為每個記錄類型排程個別的批次工作,以啟用並列化。記錄類型通常會與不同的業務流程相關聯,以證明獨立處理。每個組織最多 5 個同時批次工作需要策略性分割。
以地理位置為基礎的分割依處理散佈的擁有者、分部或區域範圍分割。在並列批次工作中處理每個區域、業務單位或銷售區域範圍。以地理位置為基礎的分割利用共用模式:每個批次工作都會在特定使用者群組內容中執行,以自然篩選資料。
快取策略針對經常存取的參考資料,使用平台快取 (組織/工作階段分割)。快取會減少查詢和 API 耗用。以整 MB 的增量配置組織和工作階段分割;預設容量會因版本而有所不同,而可透過區塊購買額外的容量。快取遺漏應順暢地回復查詢。快取 TTL 應符合資料變更頻率:靜態參考資料的時數,半動態參考資料的分鐘數。
流程大量處理使用「迴圈」和「集合」變數處理記錄集合的設計流程。建立記錄集合、執行單一「取得記錄」、使用單一「更新記錄」元素更新集合。避免在迴圈內進行個別記錄作業。流程大量處理模式會反映 Apex 最佳作法。

反模式

要尋找的位置看起來怎麼壞
僅依序處理問題:單一批次工作,會依序處理所有 5 千萬筆記錄,時間超過 24 小時。影響:封鎖其他處理、維護期間疲勞、使用者面向的延遲。解決方法:依日期、記錄類型或地理位置來分割資料。同時執行並列批次工作來處理獨立分割。
同步整合相依性問題:使用者交易已透過同步呼叫封鎖等待外部系統回應。影響:與外部系統效能繫結的使用者體驗、外部中斷期間逾時失敗。解決方法:使用「平台事件」進行非同步整合。將使用者交易與外部系統可用性分離。
無快取層級問題:重複在交易之間查詢相同的參考資料。影響:過度 SOQL 耗用、API 限制浪費、交易執行速度變慢。解決方法:針對經常存取的參考資料實作平台快取。快取可減少管理員限制耗用並改善效能。
批次工作堆疊問題:同時排程 20 個以上的批次工作啟動。影響:5 個並行工作限制會造成序列化、無法預測的完成時間。解決方法:暫存會排程在整個小時散佈負載。使用動態分派邏輯將類似工作合併為單一批次。
狀態批次過多使用問題:不需要時使用 Database.Stateful 實作批次 Apex。影響:跨 execute() 叫用的例項成員變數不必要的序列化,以及來自保留狀態的可能堆疊累積。解決方法:只有在狀態必須在執行叫用中持續時才使用 stateful。偏好無狀態批次,以避免不必要的州序列化負擔。
單串流程設計問題:在「迴圈」內逐一處理流程記錄,每個迭代具有個別「取得/更新記錄」元素。影響:管理員限制耗用量與記錄計數比例,大規模交易失敗。解決方法:收集記錄至集合變數、執行單一「取得記錄」、使用迴圈外單一「更新記錄」元素更新集合。
無非同步重試策略問題:失敗的非同步工作未自動重試,需要手動介入。影響:資料不一致、手動作業負擔、SLA 遺漏。解決方法:使用指數反向方式實作自動重試。使用「平台事件」來啟用可持續持續排入的重新執行。監視 AsyncApexJob 並警示持續失敗。

模式

要尋找的位置良好的外觀
批次與可排入的選項將批次 Apex 用於:以區塊方式處理數百萬筆記錄、排程大量作業、資料移轉。將 Apex 用於:具有鏈結的多步驟整合工作流程、需要複雜物件參數的作業,以及需要比 @future 更完善監視的工作。非同步 Apex 每 24 小時共用 250,000 次執行 (DailyAsyncApexExecutions) 在批次、可排列、未來和排程的 Apex 中,而不是在特定於 Queueable 的配置中。
可排列鏈結透過從目前工作執行方法建立下一個工作,實作多步驟工作流程。鏈結可啟用依序處理:callout → parse response → enqueue 追蹤動作。每個可排列執行最多可排入 1 列,可防止流失鏈結。設計具有完成偵測的鏈結,以避免無限迴圈。
@future 方法使用狀況將 @future 用於不需要複雜參數 (僅限原始值) 和無鏈結的簡單非同步作業。限制:每個 Apex 交易 50 個 @future 呼叫。@future 提供最簡單的非同步模式,但缺乏可視性:無工作監視、無鏈結、無複雜參數。針對新開發,偏好「可排列」。
排程的 Apex 最佳化將已排程作業合併為單一可排程類別分派給特定處理常式。每個組織最多 100 個排程工作需要策略式合併。在休假時間排程,以減少使用者作業的爭用。使用排程的 Apex 進行協調流程,將繁重的處理委派給批次 Apex。
平台事件重新執行設計訂閱者處理重新執行情況:訂閱者失敗後的重複事件、延長中斷後的缺勤事件。維護每個訂閱者的上次處理 ReplayId。使用 EventBus.getReplayId() 來偵測重新執行與新事件。實作 idempotent 處理 (處理相同事件兩次會產生相同的結果)。
繼續模式針對需要 > 5 秒回應時間的 Lightning 元件中長時間執行呼叫,使用「繼續」。繼續功能可啟用多個同時 120 秒的呼叫,以改善並列作業的認知效能。限制:每要求 3 個繼續。實作逾時處理和使用者回饋意見。

如需內嵌範例和詳細指引,請參閱「可靠性」支柱,或瀏覽「模式和反模式」探索器。