Skalbarhetsmönster

Få reda på mer om välarkitekturerad tillförlitlighet → Skalbarhet och kapacitetsplanering

Mönster

Var man ska letaHur bra ser ut
SOQL-frågeeffektivitetSlå samman sökfrågor med relationsfrågor (Kontakter, Kundcase__r) istället för separata sökfrågor per relaterat objekt. Fråga alla data som behövs en gång per transaktion. Mål <50 sökfrågor i synkrona transaktioner, <100 i asynkrona (gränser: 100 synkroniserade, 200 asynkrona). Håll 30-50% buffer under gränser.
Bulk för DML-operationSamla in poster i listor, kör ett enskilt DML-uttryck per objekttyp per transaktion. Använd Database.insert/update/delete med parametern allOrNone som styr delvis lyckat beteende. Mål <75 DML-uttryck per transaktion (gräns: 150). Batch minskar DML-användningen från N-uttryck till 1.
Hantering av heapstorlekFråga endast obligatoriska fält (undvik SELECT *-mönster). Bearbeta stora resultatuppsättningar i delar. Rensa samlingar efter bearbetning för att frigöra minne. Mål <4MB heap i synkront sammanhang (gräns: 6MB), <8MB asynkron (gräns: 12MB). Heapöverskridna fel indikerar behov av uppdelning eller streamingmönster.
Optimering av CPU-tidMinimera beräkningskomplexitet i loopar. Använd Kartor för sökningar (O(1)) istället för kapslade listupprepningar (O(n2)). Ladda av tunga beräkningar till asynkront sammanhang. Mål <7 000 ms CPU i synkrona transaktioner (gräns: 10,000ms), <40 000ms asynkron (gräns: 60 000ms).
SOQL-frågeraderDesignfrågor som returnerar rimliga storlekar på resultatuppsättningar. Använd LIMIT-klausul för att begränsa resultat. Mål <25 000 rader per sökfråga i synkront sammanhang (gräns: 50,000). Sökfrågor som närmar sig gränser ska använda paginering eller flyttas till asynkron bearbetning med Batch Apex eller Queueable.
API-anropsallokeringÖvervaka 24-timmars API-gränsanvändning via Systemöversikt. Batch API-operationer istället för post-för-post-anrop. Cache ofta besökta referensdata med plattformscache. Mål <70% av daglig API-gräns för att tillgodose ökningar. API-gränsen varierar beroende på version och licensantal.
AnropsgränserSlå samman externa anrop: batcha flera poster till en enskild API-begäran när det externa systemet stöder den. Implementera begäranköer för att serialisera anrop. Respektera den totala anropstiden på 120 sekunder per transaktion. Gräns: 100 anrop per transaktion. Utforma asynkron bearbetning för anropstunga integreringar.
Kod (Apex, Aura, LWC)Implementera buntningsmönster: processsamlingar inte individuella poster, fråga en gång och cache i kartor, kör enskild DML per objekttyp. Använd relationsfrågor för att minimera SOQL-användning. Tillämpa effektiva algoritmer för att undvika kapslade loopar på stora datauppsättningar.

Antimönster

Var man ska letaHur dåligt ser ut
SOQL i looparProblem: Utföra SOQL-frågor inuti för loopar som bearbetar postsamlingar. Påverkan: Sökfrågegränsen överskred felet vid över 100 poster (gräns: 100 sökfrågor per transaktion). Lösning: Fråga en gång innan loop, lagra resultat i Karta nyckelad efter relationsfält. Sökning från karta inuti loop (buntmönster).
DML i looparProblem: Utföra infoga/uppdatera/ta bort-uttryck inuti för loopar. Påverkan: DML-gränsen överskred felet vid 150+ poster (gräns: 150 DML-uttryck per transaktion). Lösning: Samla in poster i Lista inuti loop, kör ett enskilt DML-uttryck efter att loopen har slutförts.
Ingen styrande gränsbuffertProblem: Utforma transaktioner som upptar 95 %+ av styrande begränsningar under normala förhållanden. Påverkan: Produktionsfel vid liten belastning ökar, ingen kapacitet för kantfall. Lösning: Mål 70 % av gränserna som driftstak. Reservera 30% buffer för spikar och kantfall.
Kapslade kartesiska produkterProblem: Kapslade loopar som upprepar två stora samlingar som skapar O(n2)-operationer. Påverkan: CPU-gräns överskred fel, heapgräns överskreds från tillfälliga objekt. Lösning: Använd kartbaserade sökningar som konverterar O(n2) till O(n). Samla in nycklar för yttre loop, fråga relaterade poster en gång, sök i inre loop.
HeapackumuleringProblem: Att läsa in stora sökfrågeresultat i minnet utan bearbetning i delar. Påverkan: Heapgräns överskred felet (6MB synkronisering, 12MB asynkronisering). Lösning: Fråga endast efter fält som behövs. Bearbeta i satser för att rensa samlingar efter varje sats. Använd QueryLocator med Batch Apex för bearbetning av flera miljoner poster.
Ingen fältnivåfiltreringProblem: Välja alla fält (explicit eller implicit) när endast underuppsättning behövs. Påverkan: Överdriven heapkonsumtion, långsammare körning av sökfrågor, SOQL-radgränsen närmade sig i onödan. Lösning: VÄLJ endast fält som behövs för bearbetning. Använd relationsnotation för att hämta relaterade data i enskilda sökfrågor istället för separata sökfrågor.
Synkron överanvändning av bearbetningProblem: Bearbetning av stora datavolymer synkront inom användartransaktioner. Påverkan: Användare som väntar på flersekundersoperationer, CPU/heap-gränser överskred blockering av användare. Lösning: Flytta tung bearbetning till asynkront sammanhang (Batch, Köbar, Plattformshändelser). Ge användare omedelbara svar med statusomröstning.

Mönster

Var man ska letaHur bra ser ut
Asynkron bearbetningAnvänd Batch Apex för att bearbeta stora postvolymer (miljoner). Använd Queueable Apex för komplex orkestrering i flera steg med kedja. Använd Plattformshändelser för händelsedriven frånkoppling. Använd Schemalagd Apex för periodiskt underhåll. Matcha asynkront mönster att använda kundcase: Batch för volym, Köbar för komplexitet, Händelser för frånkoppling.
Implementering av batch ApexUtforma startmetod som returnerar selektiv QueryLocator för att minimera bearbetade poster. Konfigurera batchstorlek baserat på postkomplexitet (200-2 000 poster per körning). Implementera endast statusbaserat gränssnitt vid behov eftersom det minskar genomströmningen. Övervaka AsyncApexJob för framgång/misslyckande. Batch tillhandahåller dedikerade styrande gränser per bit.
PlattformshändelsearkitekturPublicera händelser för lägesändringar som kräver bearbetning längre ner. Prenumerera med Apex utlösare på plattformshändelseobjekt eller externa prenumeranter via CometD. Utforma idempotenta prenumeranter (repris kan leverera händelser flera gånger). Använd 72-timmarslagring för återställning från tillfälliga prenumerantfel.
Datumbaserad partitioneringBearbeta data i tidsfönster: innevarande månad, senaste kvartal, detta år. Arkivera historiska data till stora objekt eller extern lagring. Tidsbaserad partitionering möjliggör parallella batchjobb som bearbetar olika datumintervall samtidigt. De flesta sökfrågor filtrerar naturligt efter datum vilket gör detta effektivt.
PosttyppartitioneringBearbeta olika posttyper oberoende av varandra. Schemalägg separata batchjobb per posttyp för att aktivera parallellisering. Posttyper korrelerar ofta med unika verksamhetsprocesser som motiverar oberoende bearbetning. Högst 5 samtidiga batchjobb per organisation kräver strategisk partitionering.
Geografibaserad partitioneringPartition efter ägare, avdelning eller område för bearbetning av distribution. Bearbeta varje region, affärsenhet eller säljområde i parallella batchjobb. Geografibaserad partitionering utnyttjar delningsmodellen: varje batchjobb körs i sammanhanget för en specifik användargrupp och filtrerar data naturligt.
CachingstrategiAnvänd plattformscache (org-/sessionspartitioner) för ofta besökta referensdata. Cache minskar användningen av sökfrågor och API. Allokera organisations- och sessionspartitioner i steg om hela MB. Standardkapacitet varierar beroende på version, med ytterligare kapacitet som kan köpas i block. Cache-missen borde smidigt gå tillbaka till sökfrågan. Cache-TTL ska matcha dataändringsfrekvens: timmar för statiska referensdata, minuter för semidynamiska.
FlödesbuntningUtforma flöden som bearbetar postsamlingar med hjälp av variablerna Loop och Samling. Skapa samling av poster, utför enskilda Hämta poster, uppdatera samling med ett enskilt element för Uppdatera poster. Undvik individuella postoperationer inuti loopar. Flödesbuntningsmönster återspeglar Apex rekommenderade metoder.

Antimönster

Var man ska letaHur dåligt ser ut
Endast sekventiell bearbetningProblem: Enskilt batchjobb som bearbetar alla 50 miljoner poster sekventiellt tar över 24 timmar. Påverkan: Blockerar annan bearbetning, uttömning av underhållsfönster, förseningar för användare. Lösning: Partitionera data efter datum, posttyp eller geografi. Kör parallella batchjobb som bearbetar oberoende partitioner samtidigt.
Synkrona integreringsberoendenProblem: Användartransaktioner blockerade som väntar på externa systemsvar via synkrona anrop. Påverkan: Användarupplevelse knuten till externa systemprestanda, timeoutfel under externa avbrott. Lösning: Använd plattformshändelser för asynkron integrering. Koppla bort användartransaktion från extern systemtillgänglighet.
Inget cachlagerProblem: Fråga samma referensdata upprepade gånger över transaktioner. Påverkan: Överdriven SOQL-konsumtion, API-begränsningsslöseri, långsammare transaktionsutförande. Lösning: Implementera plattformscache för ofta besökta referensdata. Cache minskar regulatorbegränsning och förbättrar prestandan.
Stapling av batchjobbProblem: Schemaläggning av 20+ batchjobb som startar samtidigt. Påverkan: Uppbyggnad av ködjup, 5 samtidiga jobbgränser orsakar serialisering, oförutsägbara slutförandetider. Lösning: Spridningsscheman distribuerar belastning över timmar. Slå samman liknande jobb i en enda sats med dynamisk utskickslogik.
Statusfull överanvändning av batchProblem: Implementera Batch Apex med Database.Stateful när det inte behövs. Påverkan: Onödig serialisering av instansmedlemsvariabler över execute() åberopningar och potentiell heapackumulering från behållet läge. Lösning: Använd endast statusfull när status måste kvarstå över utföra åberopningar. Föredrar lägeslösa satser för att undvika onödig överlagring av lägesserialisering.
Design med enkelgängat flödeProblem: Flödesbearbetningsposter en och en inuti Loop med individuella element för Hämta/uppdatera post per upprepning. Påverkan: Styrande begränsar konsumtionen proportionellt till antalet poster, transaktionsfel i stor skala. Lösning: Samla poster till samlingsvariabel, utför enskilda Hämta poster, uppdatera samling med ett enskilt element för Uppdatera poster utanför loopen.
Ingen asynkron försöksstrategiProblem: Misslyckade asynkrona jobb försöks inte automatiskt, vilket kräver manuellt ingripande. Påverkan: Datainkonsekvens, manuell operativ börda, servicenivåavtalsmissar. Lösning: Implementera automatiskt återförsök med exponentiell backoff. Använd Plattformshändelser för hållbar köaktivering för repris. Övervaka AsyncApexJob och varna om kvarstående fel.

Mönster

Var man ska letaHur bra ser ut
Val av sats vs köAnvänd Batch Apex för: bearbeta miljoner poster i delar, schemalagda massoperationer, datamigreringar. Använd Queueable Apex för: arbetsflöden med flerstegsintegrering med kedja, operationer som kräver komplexa objektparametrar, jobb som behöver bättre övervakning än @future. Asynkrona Apex delar en gräns på 250 000 körningar per 24 timmar (DailyAsyncApexExecutions) över batch, köbar, framtida och schemalagd Apex, istället för en köspecifik allokering.
Köbar kedjaImplementera arbetsflöden i flera steg genom att placera nästa jobb i kö från det aktuella jobbets utförandemetod. Kedja aktiverar sekventiell bearbetning: anrop → tolka svar → köuppföljningsåtgärd. Högst 1 kö per kökörning förhindrar skenande kedjor. Utforma kedjor med slutförandedetektering för att undvika oändliga loopar.
Användning av @future-metodAnvänd @future för enkla asynkrona operationer som inte kräver några komplexa parametrar (endast primitiver) och ingen kedja. Gräns: 50 @future-anrop per Apex transaktion. @future tillhandahåller det enklaste asynkrona mönstret men saknar synlighet: ingen jobbbevakning, ingen kedja, inga komplexa parametrar. Föredrar Köbar för ny utveckling.
Schemalagd Apex optimeringSlå samman schemalagda operationer till enskilda schemaläggningsbara utskick till specifika hanterare. Högst 100 schemalagda jobb per organisation kräver strategisk sammanslagning. Schemalägg utanför arbetstid för att minska tvister med användaråtgärder. Använd Schemalagd Apex för orkestrering, delegera tung bearbetning till Batch Apex.
Repris för plattformshändelseUtforma prenumeranter som hanterar reprisscenarion: dubbletthändelser efter prenumerantfel, mellanrumshändelser efter utökat avbrott. Behåll senast bearbetat ReplayId per prenumerant. Använd EventBus.getReplayId() för att upptäcka repris vs nya händelser. Implementera idempotent bearbetning (bearbetning av samma händelse två gånger ger samma resultat).
FortsättningsmönsterAnvänd Fortsättning för långa anrop från Lightning komponenter som kräver >5 sekunders svarstider. Fortsättning aktiverar flera samtidiga 120-sekundersanrop för att förbättra upplevd prestanda för parallella operationer. Gräns: 3 fortsättningar per begäran. Implementera timeouthantering och användarfeedback.

Infogade exempel och detaljerad vägledning finns i pelaren Tillförlitlighet eller i utforskaren Mönster och antimönster.