Համապատասխանություն՝ տրանզակցիաներ, idempotency, outbox և saga-ներ

01ACID և isolation-ի մակարդակներ

Տվյալների բազայի տրանզակցիան խմբավորում է փոփոխությունները, որպեսզի դրանք միասին հաջողվեն կամ ձախողվեն։ ACID-ը նկարագրում է խոստումը․ Atomicity (ամեն ինչ կամ ոչինչ), Consistency (սահմանափակումները պահպանվում են), Isolation (զուգահեռ տրանզակցիաները չեն տեսնում միմյանց կիսատ աշխատանքը) և Durability (commit արված տվյալները գոյատևում են crash-ը)։ Isolation-ն ունի մակարդակներ։ Read committed-ը՝ PostgreSQL-ի լռելյայնը, ցույց է տալիս միայն commit արված տվյալները, բայց թույլ է տալիս, որ արժեքը փոխվի նույն տրանզակցիայի երկու կարդալների միջև։ Repeatable read-ը տալիս է կայուն snapshot, և դա MySQL InnoDB-ի լռելյայնն է։ Serializable-ը ստիպում է զուգահեռ տրանզակցիաներին վարվել այնպես, կարծես դրանք կատարվել են մեկը մյուսից հետո՝ կոնֆլիկտների դեպքում կրկնակի փորձերի գնով։ Դասական անոմալիաներն են lost update-ները (երկու օգտատեր միաժամանակ նվազեցնում են պաշարը) և write skew-ը։ Կանխիր դրանք row lock-երով (SELECT ... FOR UPDATE), ատոմար թարմացումներով (SET stock = stock - 1 WHERE stock > 0), unique constraint-ներով կամ serializable isolation-ով՝ կրկնակի փորձով։

02Ինչու են բաշխված տրանզակցիաները դժվար

Երբ պատվերը դիպչում է քո տվյալների բազային, վճարային պրովայդերին և հաղորդագրությունների հերթին, ոչ մի տրանզակցիա չի ծածկում երեքը միասին։ Two-phase commit-ը (2PC) փորձում է․ կոորդինատորը յուրաքանչյուր մասնակցի խնդրում է պատրաստվել, հետո՝ commit անել։ Այն աշխատում է որոշ փակ համակարգերում, բայց արգելափակվում է, երբ կոորդինատորը ձախողվում է, lock-եր է պահում ցանցային round-trip-ների ընթացքում և չի աջակցվում հերթերի մեծ մասի և ցանկացած երրորդ կողմի HTTP API-ի կողմից։ Հիմնարար խնդիրը dual write-ն է․ պահպանում ես պատվերը, հետո հրապարակում «order created»։ Եթե պրոցեսը crash է լինում այդ երկուսի միջև, կամ իրադարձությունը կորչում է, կամ, եթե նախ հրապարակես, գոյություն ունի իրադարձություն մի պատվերի համար, որը երբեք չի պահպանվել։ Կրկնակի փորձն ավելացնում է ևս մեկ խնդիր․ timeout-ը չի ասում, թե արդյոք մյուս կողմը կատարել է աշխատանքը։ Այս ձախողումները չես կարող վերացնել, ուստի նախագծում ես դրանց համար։

• Timeout-ը նշանակում է «անհայտ», ոչ թե «ձախողված»։
• Սահմանը հատող յուրաքանչյուր քայլ պետք է կրկնվի առանց կողմնակի էֆեկտների։
• Պահիր reconciliation-ի ուղի այն վիճակների համար, որոնք չես կարող ավտոմատ որոշել։

03Idempotency key-եր

Գործողությունը idempotent է, երբ այն երկու անգամ կատարելը նույն էֆեկտն ունի, ինչ մեկ անգամ կատարելը։ GET-ը, PUT-ը և DELETE-ը idempotent են ըստ սահմանման, իսկ POST-ը, որը ստեղծում է բաներ կամ գանձում քարտերից, idempotent չէ։ Լուծումը idempotency key-ն է․ կլիենտը յուրաքանչյուր տրամաբանական գործողության համար գեներացնում է եզակի ID (UUID) և ուղարկում այն, սովորաբար Idempotency-Key header-ում։ Սերվերը պահում է key-ը արդյունքի հետ նույն տրանզակցիայում, ինչ աշխատանքը՝ պաշտպանված tenant-ով կամ օգտատիրոջով սահմանափակված unique constraint-ով։ Նույն key-ով կրկնակի փորձը վերադարձնում է պահված արդյունքը՝ գործողությունը կրկնելու փոխարեն, իսկ զուգահեռ կրկնօրինակը բախվում է unique constraint-ին և սպասում կամ մաքուր ձախողվում է։ Key-երի ժամկետը պետք է լրանա խելամիտ պատուհանից հետո, իսկ այլ request body-ով կրկին օգտագործված key-ը պետք է մերժվի։ Նույն գաղափարը կիրառիր consumer-ների համար․ գրանցիր մշակված հաղորդագրությունների ID-ները։

1CREATE TABLE idempotency_keys (
2  tenant_id     uuid        NOT NULL,
3  key           text        NOT NULL,
4  request_hash  text        NOT NULL,
5  response      jsonb,
6  created_at    timestamptz NOT NULL DEFAULT now(),
7  PRIMARY KEY (tenant_id, key)
8);
9 
10-- Inside the same transaction as the business write:
11INSERT INTO idempotency_keys (tenant_id, key, request_hash)
12VALUES ($1, $2, $3)
13ON CONFLICT (tenant_id, key) DO NOTHING
14RETURNING key;
15-- No row returned? It is a retry: load and return the stored response.

04Transactional outbox

Outbox պատերնը լուծում է dual write-ը։ Բրոքերում ուղղակի հրապարակելու փոխարեն իրադարձությունը ավելացնում ես outbox աղյուսակում՝ նույն տվյալների բազայի տրանզակցիայում, ինչ բիզնես փոփոխությունը։ Կամ երկուսն էլ commit են արվում, կամ ոչ մեկը։ Հետո առանձին relay պրոցես կարդում է չհրապարակված տողերը, հրապարակում դրանք հերթում կամ բրոքերում և նշում որպես ուղարկված։ Եթե relay-ը crash է լինում հրապարակելուց հետո, բայց նշելուց առաջ, իրադարձությունը կրկին է հրապարակվում, ուստի առաքումը at-least-once է, և consumer-ները պետք է idempotent լինեն։ Օգտագործիր FOR UPDATE SKIP LOCKED, որպեսզի մի քանի relay worker կարողանան կիսել աշխատանքը առանց բախումների, և մաքրիր հին հրապարակված տողերը։ Այլընտրանքային relay է change data capture-ը (օրինակ՝ Debezium-ը, որը կարդում է տվյալների բազայի log-ը), որը խուսափում է polling-ից։ Հակառակ պատերնը՝ inbox-ը, պահում է մուտքային հաղորդագրությունների ID-ները՝ consumer-ի կողմում կրկնօրինակները հեռացնելու համար։

1BEGIN;
2UPDATE orders SET status = 'paid' WHERE id = $1;
3INSERT INTO outbox (aggregate_id, type, payload)
4VALUES ($1, 'order.paid', $2);
5COMMIT;
6 
7-- Relay worker, in a loop:
8SELECT id, type, payload
9FROM outbox
10WHERE published_at IS NULL
11ORDER BY created_at
12LIMIT 100
13FOR UPDATE SKIP LOCKED;
14-- publish each row, then:
15UPDATE outbox SET published_at = now() WHERE id = ANY($1);

05Saga-ներ՝ orchestration ընդդեմ choreography

Saga-ն երկար բիզնես տրանզակցիա է՝ բաժանված լոկալ քայլերի, որոնցից յուրաքանչյուրն ունի փոխհատուցող գործողություն, որը իմաստային առումով չեղարկում է այն։ Պատվերի ձևակերպումը կարող է լինել՝ ամրագրել պաշարը, գանձել քարտից, ստեղծել առաքում։ Եթե գանձումը ձախողվում է, saga-ն ազատում է պաշարը։ Փոխհատուցումը rollback չէ․ ուղարկված email-ը չես կարող «չուղարկել», ուստի ուղարկում ես ուղղում, գանձված վճարումը վերադարձվում է, ոչ թե ջնջվում։ Choreography-ում յուրաքանչյուր ծառայություն լսում է իրադարձությունները և արձակում հաջորդը («StockReserved»-ը գործարկում է վճարումը)։ Այն թույլ կապակցված է, բայց դժվար է հետևել, երբ քայլերը շատ են։ Orchestration-ում մեկ կոմպոնենտ՝ բացահայտ state machine, յուրաքանչյուր մասնակցի ասում է՝ ինչ անել, և գրանցում առաջընթացը։ Այն ավելի հեշտ է մոնիթորինգ անել, թեստավորել և փոխել, և դա իմ լռելյայն ընտրությունն է երկու-երեքից ավելի քայլ ունեցող հոսքերի համար։ Ամեն դեպքում պահպանիր saga-ի վիճակը, յուրաքանչյուր քայլ դարձրու idempotent և խրված saga-ները տեսանելի դարձրու օպերատորներին։

06Eventual consistency, exactly-once-ի առասպելներ և CAP

Eventual consistency-ն նշանակում է, որ եթե նոր փոփոխություններ չեն գալիս, տվյալների բոլոր պատճենները կհամընկնեն, բայց կարճ ժամանակով կարող են տարբերվել։ Գործնականում սա լավ է լոյալության միավորների համար, որոնք հայտնվում են մեկ վայրկյան ուշ, բայց լավ չէ այնպիսի հաշվեկշիռ ցույց տալու համար, որը օգտատերը կարող է գերծախսել։ Օգտատիրոջ փորձառությունը նախագծիր դրա համար․ ցույց տուր «մշակվում է» վիճակներ, քո իսկ գրառումները կարդա primary-ից և պարբերաբար համադրիր ճշմարտության աղբյուրի հետ, օրինակ՝ վճարային պրովայդերի հաշվետվության։ Ցանցով «exactly-once delivery»-ն առասպել է․ այն, ինչ կարող ես կառուցել, exactly-once էֆեկտն է՝ at-least-once առաքում գումարած idempotent մշակում։ CAP-ը պարզ բառերով․ երբ ցանցը համակարգդ բաժանում է երկու մասի, յուրաքանչյուր կողմ պետք է կամ մերժի որոշ հարցումներ (ընտրի consistency), կամ շարունակի պատասխանել հնարավոր հնացած տվյալներով (ընտրի availability)։ Առանց partition-ի իրական փոխզիջումը latency-ն ընդդեմ consistency-ի է։

07MVCC, serializable isolation և retry ցիկլեր

PostgreSQL-ը և MySQL InnoDB-ն օգտագործում են multi-version concurrency control․ գրողները ստեղծում են տողերի նոր տարբերակներ, իսկ ընթերցողները տեսնում են snapshot, այնպես որ ընթերցումները չեն արգելափակում գրառումները։ Ահա թե ինչու են անոմալիաներ առաջանում․ երկու տրանզակցիա կարող են յուրաքանչյուրը կարդալ snapshot, որոշում կայացնել և գրել՝ առանց միմյանց տեսնելու։ PostgreSQL-ի serializable մակարդակն օգտագործում է Serializable Snapshot Isolation, որը հետևում է read-write կախվածություններին և վտանգավոր պատերն ձևավորվելիս ընդհատում է տրանզակցիաներից մեկը SQLSTATE 40001-ով (serialization_failure)։ Այն տալիս է ամենաուժեղ երաշխիքը՝ առանց ամեն տող lock անելու, բայց միայն եթե հավելվածը 40001-ի դեպքում retry է անում ամբողջ տրանզակցիան, իդեալում՝ փոքր backoff-ով և retry-ների սահմանով։ Serializable տրանզակցիաները պահիր կարճ, դրանց ներսում խուսափիր արտաքին կանչերից և օգտագործիր դրանք մի քանի տող ընդգրկող ինվարիանտների համար, օրինակ՝ «առնվազն մեկ բժիշկ հերթապահ», որտեղ պարզ row lock-ը բավարար չէ։

1async function withSerializableRetry<T>(fn: (tx: Tx) => Promise<T>, attempts = 5): Promise<T> {
2  for (let i = 1; ; i++) {
3    try {
4      return await db.transaction(fn, { isolationLevel: "serializable" });
5    } catch (err: any) {
6      const retryable = err?.code === "40001" || err?.code === "40P01"; // serialization / deadlock
7      if (!retryable || i >= attempts) throw err;
8      await new Promise((r) => setTimeout(r, Math.random() * 50 * i));
9    }
10  }
11}

08Իդեմպոտենտությունը խորությամբ․ ընթացքի մեջ գտնվող հարցումներ և fingerprint-ներ

Իդեմպոտենտության պարզունակ աղյուսակն ունի բաց․ առաջին հարցումը դեռ աշխատում է, երբ retry-ը հասնում է։ Key-ի հետ պահիր վիճակ․ in_progress, հետո completed՝ պատասխանով, կամ failed՝ retryable դրոշակով։ Retry-ը, որը գտնում է in_progress, ստանում է 409 Conflict (կամ կարճ սպասում է), բայց երբեք երկրորդ կատարում։ Հարցման համար ստեղծիր fingerprint (method, path, body-ի կանոնական hash) և մերժիր key-ի կրկնակի օգտագործումը այլ fingerprint-ով։ Որոշիր, թե ինչ պահել․ վերջնական հաջողությունը և դետերմինիստիկ վալիդացիայի սխալները վերարտադրվում են, իսկ անցողիկ սխալները, օրինակ՝ downstream timeout-ը, չեն քեշավորվում, որպեսզի կլիենտը կարողանա retry անել։ Key-երը սահմանափակիր ըստ account-ի՝ բախումներից խուսափելու համար, ժամկետանց դարձրու դրանք կլիենտի retry-ի պատուհանից հետո, և երբ գործողությունը կանչում է երրորդ կողմի, downstream փոխանցիր դրանից ստացված idempotency key, որպեսզի ամբողջ շղթան անվտանգ լինի սկզբից մինչև վերջ։

• Վիճակներ․ in_progress, completed (պատասխանով), failed։
• Նույն key + այլ body = 422, ոչ թե replay։
• Ստացված key-ը փոխանցիր վճարային provider-ներին և այլ API-ներին։

09Outbox մեծ մասշտաբով․ հերթականություն, CDC և replication slot-եր

SKIP LOCKED-ով polling relay-ը պարզ է, բայց կարող է խառնել իրադարձությունների հերթականությունը, որովհետև մի քանի worker հրապարակում են զուգահեռ։ Եթե consumer-ներին պետք է հերթականություն յուրաքանչյուր էնտիտիի համար, աշխատանքը բաժանիր ըստ aggregate ID-ի կամ օգտագործիր մեկ relay յուրաքանչյուր partition-ի համար, և ամեն իրադարձության մեջ ներառիր aggregate-ի տարբերակը, որպեսզի consumer-ները կարողանան մերժել հնացածները։ Change data capture գործիքները, օրինակ՝ Debezium-ը, կարդում են write-ahead log-ը logical replication slot-ի միջոցով՝ polling-ի փոխարեն, տալով ցածր latency և commit-ի հերթականություն։ Օպերացիոն թակարդը․ replication slot-ը WAL-ը պահում է primary-ի վրա, մինչև consumer-ը հաստատի այն։ Եթե CDC connector-ը կանգնում է, WAL-ը կուտակվում է և կարող է լցնել դիսկը։ Մոնիթորինգ արա slot-ի lag-ը, դիր max_slot_wal_keep_size (PostgreSQL 13+)՝ որպես անվտանգության սահման, և ջնջիր լքված slot-երը։ Outbox աղյուսակը պարբերաբար մաքրիր, իդեալում՝ ըստ partition-ի, որպեսզի այն մնա փոքր և արագ։

1-- How much WAL each replication slot is holding back
2SELECT slot_name, active,
3       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained
4FROM pg_replication_slots;
5 
6-- postgresql.conf: never let a stuck slot fill the disk
7-- max_slot_wal_keep_size = '20GB'

10Saga-ի դիզայն․ pivot քայլեր և isolation-ի հակաքայլեր

Saga-ները հրաժարվում են isolation-ից․ այլ տրանզակցիաներ կարող են տեսնել միջանկյալ վիճակներ, օրինակ՝ ամրագրված պաշար պատվերի համար, որը չեղարկվելու է։ Քայլերը դասավորիր գիտակցված։ Սկզբում գալիս են փոխհատուցելի քայլերը (պաշարի ամրագրում, գումարի hold), հետո pivot քայլը՝ անվերադարձ կետը, օրինակ՝ վճարման capture-ը, հետո retriable քայլերը, որոնք վերջիվերջո պետք է հաջողվեն (առաքման ստեղծում, անդորրագրի ուղարկում) և retry են արվում, ոչ թե փոխհատուցվում։ Անոմալիաները սահմանափակելու համար օգտագործիր հակաքայլեր։ Semantic lock-ը գրառումները նշում է որպես pending, որպեսզի այլ հոսքերը զգույշ վարվեն դրանց հետ։ Commutative թարմացումները (մնացորդների գումարում և հանում) հերթականությունը դարձնում են անկարևոր։ Արժեքը թարմացումից առաջ նորից կարդալը հայտնաբերում է, որ այն փոխվել է։ Version դաշտերը մերժում են հնացած գրառումները։ Saga-ի վիճակը պահպանիր՝ ամեն քայլի համար timeout-ներով, որպեսզի կորած պատասխանի անվերջ սպասող saga-ն դառնա տեսանելի, գործողության ենթակա տարր, ոչ թե ամրագրված պաշարի լուռ արտահոսք։