Exactly-once семантикасы

exactly-once дегеніміз не?

• Жеткізу: хабарлама тұтынушыға дәл бір рет жеткізіледі.
• Өңдеу: соңғы жанама әсер (ДБ-ға жазу, баланстың өзгеруі, басқа оқиғаның эмиссиясы) жеткізу немесе әрекеттер көп болса да тура бір рет болады.

Бөлінген жүйелерде өңдеу семантикасы туралы айту сенімдірек. Жеткізуді дәл бір рет қамтамасыз ету қиын (телнұсқалар мен қайталаулар болмай қоймайды), бірақ қорытынды жай-күй жалғыз өңдеуге баламалы болатындай етіп жасауға болады.

EOS қажет болғанда және қажет болмағанда

• Ақшалай транзакциялар мен баланстар: екі рет есептен шығаруға жол берілмейді.
• Лицензияларды/квоталарды, биллингтік есептеуіштерді есепке алу.
• Қайтымсыз сыртқы шақырулар (мысалы, кілттің біржолғы белсендірілуі).

• Әсерлер қайтарымды немесе өтелетін (сағалар, қайтарымдар).
• Витриналарда/сөрелерде уақытша телнұсқаларға жол беріледі.
• Транзакцияларды бүкіл тракт арқылы сүйретуден гөрі, демпотенттік sink қамтамасыз ету арзан.

Модель: end-to-end vs. hop-by-hop

Hop-by-hop EOS: әрбір учаске (дереккөз → процессор → қабылдағыш) өзінің әрекетін дәл бір рет қолданатынына кепілдік береді.
End-to-end EOS: бүкіл тізбек «фактіден» «саид-әсерге» дейінгі нәтиже жалғыз өңдеуге баламалы болуына кепілдік береді.

Практикада end-to-end әрбір хопта транзакциялар және/немесе демпотенттілік комбинациясымен қол жеткізіледі.

Базалық құрылыс блоктары

1. Демпотенттік операциялар

Әрекет кілті бойынша бір сұрауды қайталау сол нәтижені береді.

Ключи: `idempotency_key`/`event_id`/`operation_id`.
Іске асыру: кіріс блогы ретенциясының TTL ≥ «көрінген» операциялар кестесі.

2. «Оқу-өңдеу-жазу» транзакциялары (read-process-write)

Жұмыстың бір атомарлық бірлігінде оқудың жанама әсері де, ілгерілеуі де (офсеттер/позиция) тіркеледі. Бұл қадамдар арасына құлаған кезде «арбаларды» жояды.

3. Нұсқалау/SEQUENCE

Агрегат үшін нұсқа/санауыш сақталады; егер 'expected _ version' сәйкес келсе ғана өзгертулер қолданылады. Бір оқиғаны қайталау → нәтижесін бір рет арттырмайды.

4. Дедупликация

'(consumer_id, event_id)' бойынша немесе табиғи 'business _ id' операциясы бойынша индекс.

Сату үлгілері

1) Транзакциялық журнал + офсетті тіркеумен транзакциялық sink

Стрим-процессинг үшін өте ыңғайлы.

Логтан оқимыз (тек расталған жазбалар ғана).
Өңдеу жүргізілуде.

• a) әсерді sink (ДБ/кестеге) жазамыз,
• b) «N офсетке дейін оқылды» деп белгілейміз (осы ДБ-да).
• Коммит. Қайта қараған кезде не бәрі құпияланған (және офсет жылжытылған), не ештеңе жоқ.

Қасиеттері: қайта орындау зиян келтірмейді; «дәл бір рет» әсері бойынша, тіпті хабар екі рет оқылса да.

2) Outbox + демпотенттік консюмер

Транзакциялық сервис-продюсерлер үшін.

Бір ДБ транзакциясында: домендік жазбаны өзгертіп, оқиғаны outbox бағдарламасына жазамыз.
Републикатор оқиғаны сол 'event _ id' бар шинаға жеткізеді.
Консьюмерлер оқиғаларды іспеттес қолданады (дедуп бойынша 'event _ id').

Қасиеттері: продюсер фактінің жоғалмайтынына кепілдік береді; консьюмерлер дәл бір әсерге кепілдік береді.

3) Kafka/Flink ұқсас жүйелердегі EOS (тұжырымдамалық)

Идемпотенттік продюсер: жөнелту ретраларында дубльдерден қорғайды.
Продюсердің транзакциялары: топиктерге жазбалар тобы + консюмердің ауысуы атомарлық түрде қосылады; оқырмандар 'read _ committed' оқшаулағышын пайдаланады.
Процессинг тарабы жай-күйін (state store) сақтайды және оны транзакциямен бірге коммитититтейді.

Қасиеттері: есік/таспаны қайта іске қосу екі есе әсер етпейді; көшірмелері «көрінбейді» downstream.

4) upsert/merge арқылы теңдессіз «сики» (sinks)

Sink 'operation _ id '/' event _ id' дегенді қабылдап, 'UPSERT... WHERE NOT EXISTS`.
Жанама әсер (мысалы, есептеу) «қолданылған жоқ па» тексеруімен атомарлық орындалады.

Қасиеттері: EOS арзан тәсілі қойма шекарасында, бөлінген транзакцияларсыз.

Іске асырудың негізгі бөлшектері

Әрекет идентификаторлары

Қайталау үшін детерминацияланған болу керек (ретра кезінде жаңа UUID жасамаңыз).
Тұрақты көріну аймағының болуы (консьюмерге/агрегатқа/жүйеге).

Дедупликация кестесі

Колонки: `consumer_id`, `operation_id`, `applied_at`, `ttl_expires_at`.
'(consumer_id, operation_id)' бойынша индекстер.
TTL ≥ қайталаудың ең үлкен терезесі (логтың ретенциясы + ықтимал кідірістер).

Оптимистік бәсекелестік

write үлгісінде агрегаттың нұсқасын сақтаңыз.
Оқиға/пәрменді қолданғанда 'WHERE version =: expected'; көшірмесі нұсқасын үлкейтпейді.

Тапсырыс/тәртіп

EOS «дәл сол тәртіппен» тең емес. Топтама кілті (агрегаттың барлық оқиғалары → бір топтама) және/немесе «sequence» салыстыру арқылы тұрақтылықты қамтамасыз етіңіз.

Іспеттес сыртқы шақырулар

Қауіпсіз емес әдістер үшін (мысалы, үшінші тараптың қызметіне HTTP-веб-хаттар) 'Idempotency-Key' дегенді қосып, серіктестің оны қолдауын талап етіңіз.

Жиі тұзақтар

EOS тек бір жерде: егер sink іспеттес болса, бірақ сіз іспеттілігі жоқ екінші оқиғаларды шығарсаңыз, «тура бірнеше рет» downstream аласыз.
Екі коммита: алдымен ДБ-да, сосын брокердегі офсет коммиті - олардың арасындағы құлдырау әсерлердің көшірмесін жасайды.
Шикі CDC сыртқа: ДБ схемасының өзгеруі тұтынушылардың біртұтастығын бұзады.
Тұрақсыз кілттер: 'operation _ id' уақыт/рандомға байланысты және ретра кезінде өзгереді.

Құны және ымыраға келу

Жасырындылық: транзакциялар/оқшауланған оқу → p95/p99.
Сақтау орындарының оверхеді: дедуп кестелері, state stores, транзакция логтары.
Пайдалану күрделілігі: транзакция таймауттары, ағындардың ребалансы, «жабысқан» сессиялар.
Диагностика: көп жағдайлар ("камитада", "read_committed", "сырғып кетті").

EOS нүктесін таңдаңыз: сыни агрегаттар мен әсерлер үшін; қалғандарын демпотенттілікпен және өтемақымен жабыңыз.

exactly-once тестілеу

1. Fault-injection: қадамдар арасындағы процестің құлдырауы «нәтижені жазды» және «офсетті жазды».
2. Телнұсқалар: Сол хабарды 2-5 рет айдаңыз, бір эффектіге көз жеткізіңіз.
3. Қайта құру және ребаланс: воркерлерді тоқтату/қайта қосу, екі рет өңдеудің жоқтығын тексеру.
4. Желілік флаппи: транзакция ортасындағы таймауттар, коммитті қайталау.
5. Жүктеме тесттері: кезектердің өсуі → «транзакцияда мәңгілік» деградация жоқ па.

Шағын үлгілер (жалған)

Офсетті бекіткен іспеттес sink

pseudo begin tx if not exists(select 1 from dedup where consumer_id=:c and op_id=:id)
then apply_effect(...)    -- upsert / merge / add_one_time_action insert into dedup(c, id, applied_at) values(:c,:id, now)
end if update offsets set pos=:pos where consumer_id=:c commit

Агрегат нұсқасы бар команда

pseudo begin tx update account set balance = balance +:delta,
version = version + 1 where id=:account_id and version=:expected_version;
if row_count=0 then error CONCURRENT_MODIFICATION commit

Қауіпсіздік және комплаенс

PII/PCI дедуп кестелерінде: минимумды сақтаңыз, «шикі» деректердің орнына белгілерді пайдаланыңыз.
Аудит: логин 'operation _ id', 'trace _ id', нәтиже (APPLIED/ALREADY_APPLIED).
Сақтау саясаты: Дедуп-кестелерде TTL, офсеттерді/логтарды мұрағаттау.

Қарсы үлгілер

«Осы exactly-once жеткізу»: көліктік протокол деңгейіндегі дубльді болдырмау әрекеті.
Жаһандық таратылған транзакциялар бәріне: барлық сервистер арқылы XA/2PC - нәзік және баяу.
Демпотенттік емес жанама әсерлерді араластыру (мысалы, e-mail офсет коммитіне дейін жіберілді).
Операция кілттерінің болмауы: пайдалы жүктеменің «бірегейлігіне» сүйену.

Шығарылған чек парағы

• Әрбір сыни әсерде идемпотенттік кілт бар.
• Офсет/оқу орны эффектімен бір транзакцияда тіркеледі.
• Дедуп кестелері индекстелген; TTL лог ретенциясының ≥.
• Агрегаттар үшін оптимистік бәсекелестік бар (нұсқа/sequence).
• Ағындар/топиктер «тек ықшамдалған» күйінде оқылады (егер бар болса).
• Көшірме және құлау тестілері CI/CD-де бар.
• Дашбордтар: қайталау үлесі, сәтсіз транзакциялар, блоктау уақыты, лагтар.
• 'Idempotency-Кеу '/қайталау/таймауттар бойынша интеграторларға арналған құжаттама.

FAQ

EOS-ты транзакциясыз қамтамасыз етуге бола ма?
Жиі иә - sink 'oв (upsert/merge) және агрегаттарды нұсқалау арқылы. Транзакциялар кепілдіктерді жеңілдетеді, бірақ құнын көтереді.

Барлығына «exactly-once» керек пе?
Жоқ. Ол қымбат. Өтемақы/жол мүмкін емес жерде нүктелі қолданыңыз.

EOS-пен хаттарды/веб-хаттарды қалай байланыстыруға болады?
Хабарламаны коммитке дейін буферлеңіз, эффектті бекіткеннен кейін жіберіңіз; 'notification _ id' дегенді сақтаңыз және жіберуді іспотенттік етіп жасаңыз.

Не маңызды - жеткізу немесе өңдеу?
Өңдеу. Жеткізу қайталануы мүмкін; қорытынды жағдай дұрыс және жалғыз болуы тиіс.

Жиынтық

Exactly-once - бұл өткізгіште қосулардың жоқтығы туралы емес, әсердің дұрыстығы туралы. Оған идемпотенттілік, оқу әсері мен прогресін атомарлық бекіту, ақылға қонымды партияландыру және нұсқалау тәртібін үйлестіру арқылы қол жеткізіледі. EOS-ты қате құны қабылданбайтын жерде қолданыңыз және оның шынайылығын көлікке сенбейтін құлау және қосарлану сынақтарымен тексеріңіз.