Flashsalg og billetsalg: håndtering af 10-trafik med yndefuld komfort
Et flash salg er en trafik spike med et stopur på det - og et andet problem mest skalering råd ignorerer helt: der er kun så meget lager, og alle ønsker det på samme øjeblik.
Et flash-salg ligner en mindre sort fredag, og at forberede sig på det, som om det var en, er, hvordan dråber går galt.
Black Friday er et kapacitetsproblem: flere mennesker end normalt, fordelt over flere timer, der køber fra et bredt katalog. En dråbe er en påstand problem. Ti tusinde mennesker vil have de samme 200 ting på de samme 60 sekunder. Trafikken er den lette halvdel. Den hårde halvdel er, at din beholdning er et lille antal, som mange samtidige processer alle forsøger at formindske, og hvert sekund af salget er et løb.
Så dette er organiseret omkring de tre problemer i den rækkefølge, de vil skade dig.
Problem 1: Alle kommer på én gang
Den gode nyhed er, at dette er den del, du allerede ved, hvordan man løser, og meget af den ankommende trafik beder om identiske ting. Landingssiden, nedtællingen, produktbillederne, CSS - alle de samme for alle, alle cacheable, alle servable fra kanten uden at din oprindelse bemærker.
Der er især to ting, der er vigtige for dråber. Varm cachen før annonceringen, fordi en kold cache i øjeblikket af en koordineret ankomst betyder tusindvis af samtidige savner alle stemplet din oprindelse for den samme side. Og sørg for, at dit CDN kollapser samtidige fejl for det samme objekt i en enkelt oprindelsesanmodning, i stedet for at videresende dem alle - denne adfærd går under flere navne, men dets fravær er præcis den fejl, der tager en oprindelse ned ved T-nul.
Opfriskningsadfærden er også værd at planlægge. I minuttet før en dråbe trykker en stor del af dine besøgende gentagne gange på F5. En nedtællingsside, der er fuldstændig cachelagret, absorberer dette. En nedtællingsside, der søger i databasen efter den aktuelle servertid, gør det ikke.
Problem nr. 2: Lagerbeholdningen er et tal, og alle vil have det
Dette er den del, der adskiller dråber fra alle andre trafikhændelser, og det er slet ikke et cacheproblem.
Når 5.000 personer klikker på "køb" på 200 enheder inden for samme sekund, skal dit system beslutte, hvem der får dem. Gør det skødesløst og du oversell du tager 400 ordrer på 200 varer og tilbringe den følgende uge annullere halvdelen af dem, refusion, og undskylder. Gør det for forsigtigt, og du serialiserer hele salget bag en enkelt lås, og alle venter.
- Decrement lager atomisk på databasen. En betinget opdatering, der kun lykkes, når lagerbeholdningen er tilbage, er sikker. Læs-og-skriv i programkode er ikke, uanset hvor hurtigt det ser ud.
- Reserver ved add-to-cart, ikke ved betaling. Med en kort udløbsdato. Ellers sælger du den samme enhed til alle, der når til kassen, og taberne finder ud af det på betalingstrinet, hvilket er det værst tænkelige øjeblik.
- Vis ikke levende lagerantal på en cachelagret side. Enten udelade dem eller indlæse dem separat. En cachelagret "3 venstre", der faktisk er nul, genererer mere supportmail end intet nummer overhovedet.
- Beslut din oversalgspolitik på forhånd. Nogle virksomheder accepterer en lille oversalg og ære det; nogle aldrig gøre. Begge dele kan forsvares. At opdage, at du ikke har nogen politik kl. 20.01, er ikke tilfældet.
- Loft pr. ordre og pr. konto. Enkel, og den gør mere mod forhandlere end de fleste bot-registreringer.
Problem 3: En meningsfuld andel af mængden er ikke menneskelig
Begrænsede lagerbeholdninger tiltrækker automatiserede købere, og de er gode til dette. Et script kan afslutte kassen på en brøkdel af den tid, en person har brug for at skrive et kortnummer, og de personer, der kører dem, gør det professionelt.
Hvis du ikke gør noget, er den ærlige beskrivelse af en dråbe, der sælger ud på elleve sekunder, ikke, at efterspørgslen var ekstraordinær. Det er, at bots købte din aktie for at videresælge den, dine faktiske kunder fik ingenting, og den goodwill, du byggede, gik til et sekundært marked i stedet.
Hvad der virker, i rækkefølge efter effektivitet for indsatsen:
| Måling | Virkning | Omkostninger for rigtige kunder |
|---|---|---|
| Mængdelofter pr. konto og betalingsmetode | Høj | Ingen |
| Udfordring i forbindelse med bevis på arbejde ved køb af tillægskort og betaling i kassen | Høj | Millisekunder |
| Rategrænser på købsendepunkterne | Høj | Ingen hvis indstillet fornuftigt |
| Kræver en konto oprettet før afleveringen | Meget høj | Ekskluderer nye kunder |
| Randomiseret køposition i stedet for streng ankomstordre | Moderat | Føles mindre retfærdigt at tidlige ankomster |
| CAPTCHA ved checkout | Lav – løsningsservice er billig | Høj friktion |
Hold øje med, at dråben bliver købt, før den åbnes. Bots finder rutinemæssigt produktwebadresser og API-endepunkter før det annoncerede tidspunkt ved at gætte URL-mønstre eller se dit sitemap. Hvis produktsiden findes kl. 19:55, og slutpunktet for tilføjelse til kurven fungerer, begyndte salget kl. 19:55, uanset hvad nedtællingen siger.
Sætter de tre sammen
Den arkitektur, der holder, er lagdelt, og hvert lag beskytter det bagvedliggende:
Edge cache absorberer ankomsten
Landing page, nedtælling, billeder og aktiver serveret helt fra kanten, opvarmet på forhånd, med samtidige misser kollapsede.
Et venteværelse måler strømmen
Indrøm købere til den pris, som din betaling virkelig kan opretholde, i stedet for at lade dem alle kollidere med det samtidig.
Udfordringer og begrænsninger filtrerer købsstien
Grænser for overførselsprocenten for add-to-cart og checkout samt en udfordring med at dokumentere arbejdet, så automatiseret volumen bliver uøkonomisk.
Databasen arbitrerer bestanden atomisk
Betingede fald, kortlivede reservationer og et mængdeloft. Dette er sidste linje, og den skal være korrekt.
Bemærk, at kun det sidste lag skal være helt rigtigt. De første tre eksisterer for at reducere hvor meget belastning og hvor meget modstridende trafik når det - hvilket er det generelle princip bag alt dette, og årsagen dråber er overhovedet overleves.
Bagefter
Skriv det ned, mens det er frisk: hvor længe bestanden varede, hvor mange ordrer blev annulleret, hvordan køen så ud, hvad brød, hvad du blev overrasket over. Dråber gentager sig, ofte med de samme kunder og de samme bots, og den anden er enormt roligere, hvis nogen skrev en side med noter efter den første.
Ofte stillede spørgsmål
Hvordan forhindrer jeg, at min hjemmeside går i stykker under et flashsalg?
Cache alt, der er identisk for alle besøgende - landingsside, nedtælling, billeder og aktiver - og varm den cache, før du annoncerer, så den koordinerede ankomst ikke producerer tusindvis af samtidige cache Savner. Sæt et venteværelse foran dig, så køberne kan få adgang til betalingen med en hastighed, som den kan opretholde, og begræns købsendepunkterne. Den uoverkommelige betalingssti mislykkes, så målet er at kontrollere, hvor meget trafik der når den.
Hvordan undgår jeg oversalg under et begrænset lagerfald?
Decrement lager atomisk i databasen ved hjælp af en betinget opdatering, der kun lykkes, mens enheder forbliver, snarere end at læse lager og derefter skrive i ansøgningskode, som racer under samtidighed. Reserve lager på add-to-cart med en kort udløb i stedet for ved betaling, så kunderne ikke opdager på betalingstrin, at deres vare er væk. Sæt loft over antallet pr. ordre og pr. konto, og bestem din politik for oversalg før salget i stedet for under salget.
Hvordan stopper jeg bots med at købe alt mit begrænsede lager?
Mængdelofter pr. konto og betalingsmetode er den mest effektive foranstaltning til mindst mulig friktion. Tilføj hastighedsgrænser og en proof-of-work-udfordring på add-to-cart og checkout, som koster en reel browser millisekunder og gør automatiseret volumen uøkonomisk. CAPTCHA'er er stort set ineffektive her, da løsningstjenester er billige, og forhandlere bruger dem rutinemæssigt. Bekræft også, at produktets webadresse og købsendepunkt ikke kan nås før det annoncerede starttidspunkt.
Skal jeg vise live lagerniveauer under en dråbe?
Ikke på en cachelagret side. En cachelagret side, der viser "3 tilbage", når det sande tal er nul, producerer mere kunde frustration end at vise intet nummer overhovedet. Enten udelade lager tæller fra cachelagrede sider, eller indlæse dem gennem en separat uncached anmodning, der kan sats-begrænset uafhængigt, accepterer den ekstra oprindelse belastning, der skaber.
Hvad er forskellen mellem at forberede sig til Black Friday og et flash-salg?
Black Friday er først og fremmest et kapacitetsproblem – flere besøgende end normalt, fordelt over timer og et bredt katalog. En dråbe er et problem: mange mennesker konkurrerer om en lille, fast mængde på få sekunder. Det tilføjer bekymringer Black Friday har ikke, især atomare lagerhåndtering for at forhindre oversalg og forsvar mod videresalg bots, oven på den trafik håndtering begge begivenheder kræver.
Design til koncentration og strid, ikke bare volumen, og et fald bliver en krævende 60 sekunder snarere end en dårlig aften.
Mads har arbejdet med IT – mest som vært – siden han var 16. Han tog tidligt ejerskab i en SaaS-virksomhed og var med til at udvide den til Visma, har opbygget og drevet datacenternetværk og fungeret som CTO for et dansk datacenter. Han startede NordicCDN for at gøre hurtig og sikker infrastruktur enkel at bruge.
