Tartsd a készletszámlálót egyetlen atomi helyen, és csökkentsd atomian — egy Redis DECR (vagy egy Lua script), amely visszaadja a maradék értéket. Ha az eredmény < 0, az a request veszített; az adatbázis soha nem a konkurrencia kapuja. Minden más arról szól, hogy a másik 999 000 requestet olcsón dobd le.
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 atomi — két request nem olvashat egyszerre "1 maradt"-at. Egy Lua script egyetlen körben elvégzi: ellenőrzi a maradékot, csökkent, és rögzít SADD winners:{sale} {user}-t, hogy egy felhasználó ne nyerhessen kétszer. A Lua egyszálon fut a Redisen, így az egész check-and-set egyetlen atomi lépés.>= 0) egy queue-ba kerülnek; egy worker aszinkron kiírja a rendelést Postgresbe. Az adatbázis soha nem lát 1M konkurens írást — csak ~1000 nyertes írást.Az interjúztató azt akarja látni, hogy pontosan megnevezed a versenyhelyzetet (race condition): SELECT stock majd UPDATE két utasításban lehetővé teszi, hogy két request is 1000-et olvasson és mindkettő eladjon — klasszikus túleladás. A "jó" a "használj tranzakciót / SELECT ... FOR UPDATE"; a "kiváló" annak felismerése, hogy a sorzárolások (row lock) 1M requestet szerializálnak egyetlen forró sorra és összeomlasztják a throughputot, ezért a versengést egyetlen egyszálú atomi műveletbe helyezed át a Redisben, és csak a nyerteseket perzisztálod. A csapda az alkalmazásszintű ellenőrzésekben (if (stock > 0)) bízni atomicitás nélkül.
FOR UPDATE: a Redis 100k+ op/s-t kezel egy forró kulcson; egy Postgres row lock szerializál és megolvad egy flash sale alatt. Tartsd fenn az adatbázist a tartós rendelésrekordokhoz.IT interjúkérdések gyűjteménye részletes válaszokkal — Juniortól Seniorig.
Adományozás