Držte čítač zásob na jednom atomickém místě a atomicky ho dekrementujte — Redis DECR (nebo Lua skript), který vrátí zbývající hodnotu. Pokud je výsledek < 0, tento požadavek prohrál; databáze nikdy není bránou souběžnosti (concurrency gate). Vše ostatní je o tom levně odbourat zbylých 999 000 požadavků.
1M clients ─▶ CDN/edge (waiting room, drop bots) ─▶ LB
│
Stateless API pods
│
Redis: DECR stock (Lua: check+dec+record)
│hit>=0 │miss<0
▼ ▼
enqueue order ─▶ DB reject "sold out"
DECR stock:sale123 je atomický — žádné dva požadavky nemohou oba přečíst „zbývá 1“. Lua skript to udělá v jednom round tripu: zkontroluje zbytek, dekrementuje a zaznamená SADD winners:{sale} {user}, aby jeden uživatel nemohl vyhrát dvakrát. Lua běží v Redisu single-threadově, takže celé check-and-set je jeden atomický krok.>= 0) jsou vloženi do fronty; worker asynchronně zapíše objednávku do Postgresu. Databáze nikdy nevidí 1 milion souběžných zápisů — jen ~1000 zápisů výherců.Tazatel chce vidět, že přesně pojmenujete race condition: SELECT stock a poté UPDATE ve dvou příkazech dovolí dvěma požadavkům přečíst 1000 a oba prodat — klasický přeprodej. „Dobré“ je „použij transakci / SELECT ... FOR UPDATE“; „skvělé“ je uvědomit si, že zámky řádků serializují 1 milion požadavků na jeden hot row a zhroutí throughput, takže contention přesunete na single-threadovou atomickou operaci v Redisu a perzistujete jen výherce. Pastí je důvěřovat kontrolám na úrovni aplikace (if (stock > 0)) bez atomicity.
FOR UPDATE: Redis zvládne 100k+ operací/s na jednom hot key; zámek řádku v Postgresu serializuje a při flash sale se roztaví. Databázi vyhraďte pro trvanlivé záznamy objednávek.Knihovna IT otázek k pohovoru s podrobnými odpověďmi — od Junior po Senior.
Přispět