Сага-үлгү жана бөлүштүрүлгөн бүтүмдөр

Сага-үлгү жана бөлүштүрүлгөн бүтүмдөр

1) Эмне үчүн сагалар керек

Классикалык 2PC (эки фазалуу бекитүү) начар масштабдалат, ийгиликсиз жана ресурстарды бөгөттөйт. Сага жалпы бизнес-процессти жергиликтүү транзакциялардын (кадамдардын) ырааттуулугуна бөлөт, алардын ар бири өз алдынча биригет. Ката болгон учурда кийинки кадамдар жокко чыгарылат, ал эми аткарылгандар - тескери операциялар менен компенсацияланат.
натыйжасы: башкарылуучу eventual consistency эч кандай глобалдык бөгөт коюу, жогорку жашоо жана так калыбына келтирүү протоколу.

2) Негизги моделдер

2. 1 Оркестр

Саганын атайын координатору кадамдарды башкарат: буйруктарды жөнөтөт, жоопторду/окуяларды күтөт, компенсацияларды баштайт.
Артыкчылыктары: борборлоштурулган көзөмөл, жөнөкөй байкоо, айкын мөөнөтү. Кемчиликтери: кошумча компонент.

2. 2 Хореография

Эч кандай координатору; Кызматтар бири-биринин окуяларына жооп берет ("OrderPlaced" → "PaymentCaptured" → "InventoryReserved"...).
Артыкчылыктары: начар байланыш. Кемчиликтери: байкоо кыйын, так эрежелери жок "өлүм бий" коркунучу.

2. 3 TCC (Try-Confirm/Cancel)

1. Try - даярдоо/камдык,

2. Confirm - бекитүү,

3. Cancel - артка.

Кепилдиктер жогору, бирок контракттар жана резервдердин таймауттары кыйыныраак.

3) Кадам келишимдери жана компенсациялар

Ар бир кадам = жергиликтүү бүтүм + компенсация (демпотенттик, кайталоого жол берет).
Компенсация толугу менен "дүйнөнү кайтарууга" милдеттүү эмес - домендик эквиваленттүүлүк жетиштүү (мисалы, "төлөмдү алып салуу" ордуна "кайтарып берүү").
Инварианттарды аныктаңыз: акча үчүн - баланс минуска кетпейт; үчүн - "илинген" статустар жок.
Мөөнөтү өтүп кеткен аракеттер үчүн/TTL резервдерин жана "garbage collector" киргизиңиз.

4) ырааттуулук жана семантика жеткирүү

Жеткирүү билдирүүлөр: at-least-once (дефолт) → бардык иш-аракет болуп саналат.
Тартип: корреляциялык ачкыч боюнча маанилүү (мисалы, 'order _ id', 'player _ id').
Exactly-once - саганын максаты эмес; Демпотенттик ачкычтар, outbox/inbox жана туура коммитация аркылуу натыйжалуу тегиз-бир жолу жетишүү.

5) Саганын абалы жана анын лог

• 'saga _ id', 'correlation _ id', учурдагы абалы (Running/Completed/Compensating/Compensated/Failed),
• кадам жана анын өзгөрмөлүү (ID төлөмдөр/камдар),
• окуялардын/чечимдердин тарыхы (журналы), таймстемптер, мөөнөтү, ретрациялардын саны.

• Өзүнчө Saga Store (жадыбал/документ) координатору үчүн жеткиликтүү.
• Хореография үчүн - дастандын жергиликтүү "агенттери" статустагы окуяларды жалпы топикке жарыялашат.

6) ишенимдүү жарыялоо үлгүлөрү: outbox/inbox

Outbox: кадам өзгөрүүлөрдү коммитит жана бир бүтүмдүн outbox таблицасына окуя/команданы жаздырат; Уоркер шинага жарыялайт.
Inbox: керектөөчү иштетилген таблицаны алып барат 'message _ id' → дедуп + идемотенттүүлүк.
Ийгиликтүү терс таасиринен кийин коммитим offset/ACK (Kafka/RabbitMQ) - мурда эмес.

7) Дастандын кадамдарын долбоорлоо

7. 1 Мисал (iGaming/e-commerce сатып алуу)

1. PlaceOrder → 'PENDING' статусу.
2. AuthorizePayment (Try) → `payment_hold_id`.
3. ReserveInventory → `reservation_id`.
4. CapturePayment (Confirm).
5. FinalizeOrder → `COMPLETED`.

• (3) ишке ашпай калса → 'CancelPaymentHold';
• эгерде (4) (3) → 'ReleaseInventory' кийин ишке ашкан жок;
• эгерде (5) → 'RefundPayment' жана 'ReleaseInventory' ишке ашпай калган.

7. 2 Мөөнөтү/Retry

Максимум N экспоненциалдык кечигүү + Jitler менен retrains.
ашып кеткенден кийин - "Compensating" өтүү.
Ар бир кадам үчүн next_attempt_at жана deadline_at сактоо.

8) Оркестр vs платформа

• Light үй оркестр (микросервис + Saga таблица).
• Платформалар: Temporal/Cadence, Camunda, Netflix Conductor, Zeebe - таймер, ретра, узакка созулган workflow, көрүү жана веб консол берет.
• Хореография үчүн окуялардын каталогун жана статустар/ачкычтар боюнча катуу келишимди колдонуңуз.

9) Интеграция протоколдору

9. 1 Асинхрондук (Kafka/RabbitMQ)

Командалар: 'payments. authorize. v1`, `inventory. reserve. v1`.
Окуялар: 'payments. authorized. v1`, `inventory. reserved. v1`, `payments. captured. v1`, `payments. refunded. v1`.
Партия ачкычы = 'order _ id '/' player _ id' тартиби үчүн.

9. 2 Синхрондук (HTTP/gRPC) кадам ичинде

"Кыска" кадамдар үчүн алгылыктуу, бирок ар дайым тайм/ретр/демпотенттик жана асинхрондук компенсация үчүн fallback менен.

10) Идемпотенттүүлүк жана ачкычтар

Командалардын жана компенсациялардын суроосунда 'idempotency _ key'.
Терс таасирлери (DD/эсептен чыгаруу) шарттуу түрдө аткарылат: "Эгер 'idempotency _ key' көрбөсөңүз аткарыңыз".
Компенсация да демпотенттик: кайталоо 'RefundPayment (id = X)' коопсуз.

11) Каталарды иштетүү

• Transient (тармактар/убакыт) → Retry/backoff.
• Бизнес (жетишсиз каражаттар, лимиттер) → тез арада компенсация/альтернативалуу жол.
• Irrecoverable (инварианттын бузулушу) → кол менен кийлигишүү, "кол" компенсация.
• чечим матрицасын куруу: ката түрү → аракет (retry/compensate/escalate).

12) Байкоо жана SLO саг

• End-to-end latency сагасы (p50/p95/p99).
• Success rate (компенсациясыз бүткөн үлүш).
• Mean time to compensate и compensation rate.
• Orphaned sagas (илинип) жана GC чейин убакыт.
• Trace: 'trace _ id '/' saga _ id' кадамдардын ортосундагы span link катары; бюджет каталар үчүн бурн-rate метрика.

Логи: ар бир өзгөртүү статус сагасы = себеп менен структураланган жазуу.

13) Мисалдар (псевдокод)

13. 1 Оркестр (идея)

python def handle(OrderPlaced e):
saga = Saga. start(e. order_id)
saga. run(step=authorize_payment, compensate=cancel_payment)
saga. run(step=reserve_inventory, compensate=release_inventory)
saga. run(step=capture_payment, compensate=refund_payment)
saga. run(step=finalize_order, compensate=refund_and_release)
saga. complete()

def run(step, compensate):
try:
step () # local transaction + outbox except Transient:
schedule_retry()
except Business as err:
start_compensation(err)

13. 2 Outbox (стол идеясы)

outbox(id PK, aggregate_id, event_type, payload, created_at, sent_at NULL)
inbox(message_id PK, processed_at, status)
saga(order_id PK, state, step, next_attempt_at, deadline_at, context JSONB)
saga_log(id PK, order_id, time, event, details)

13. 3 Хореография (темалардын идеялары)

`orders. placed '→ керектөөчүлөр: ' payments. authorize`, `inventory. reserve`

`payments. authorized` + `inventory. reserved` → `orders. try_finalize`

Ар кандай баш → 'orders. compensate '→ демилгеленген' payments. cancel/refund`, `inventory. release`.

14) 2PC жана ES менен салыштыруу

2PC: күчтүү ырааттуулук, бирок блоктор, тар жерлер, "жез түтүктөр".
Сага: eventual consistency, компенсация жана телеметрия дисциплинасы керек.
Event Sourcing: чындыктын булагы катары окуяларды сактайт; сагалар табигый, бирок миграциянын/снапшоттун татаалдыгын кошот.

15) Коопсуздук жана комплаенс

транспорт Security (TLS/mTLS), ACL per topic/queue.
Окуяларда - минималдуу PII, сезгич талааларды шифрлөө, токенизация.
Дастан жана компенсация журналдарына жетүү аудити.
Тышкы провайдерлер менен SLA (төлөмдөр/жеткирүү) = ретрациялардын мөөнөтүнүн жана лимитинин параметрлери.

16) киргизүү чек-тизмеси (0-45 күн)

0-10 күн

Талапкер процесстерди бөлүңүз (мультисервис, компенсация менен).
Тандоо модель (оркестр/хореография/TSS) жана корреляциялык ачкыч.
Кадамдарды/компенсацияларды, инварианттарды жана мөөнөтүн сүрөттөп бериңиз. Таблицаларды көтөрүү 'saga', 'outbox', 'inbox'.

11-25 күн

outbox/inbox, демпотенттик жана backoff менен retrains кирет.
Деплойт биринчи сагалар; SLI/SLO дашбордддорун жана трассасын кошуу.
Runbook компенсацияларды (анын ичинде кол менен) жана эскалацияларды жазыңыз.

26-45 күн

Автоматташтыруу GC "илинип" Сагды, мезгил-мезгили менен кайра баштоо/мөөнөтү улантуу.
Оюн-күндү өткөрүңүз: кадамдан баш тартуу, мөөнөтүнөн ашуу, брокердин жеткиликсиздиги.
Иш-чаралардын келишимдерин стандартташтырыңыз (версиялар, шайкештик), "саг каталогун" түзүңүз.

17) Анти-үлгүлөрү

"Компенсация = delete from DD" ордуна домендик туура тескери аракет.
Жок outbox/inbox → жоготуу окуялар/кош таасирлери.
Jitter → өзүн-DDoS көз карандылыгы жок Retray.
"Иштеп жатат" жок окууда күчтүү ырааттуулукту күтүү....
бардык → монолит башкаруу үчүн бир ири оркестр.
Жалпы хореография көрүнбөйт жана SLA → башкарылбаган бий.
мөөнөтүн четке → түбөлүк камдар/Hold.

18) Жетилүү метрикасы

≥ 90% критикалык процесстер сагалар/компенсациялар менен капталган жана сүрөттөлгөн инварианттар бар.
Outbox/Inbox бардык өндүрүүчүлөр/ Tier-0/1.
SLO: p95 end-to-end дастан нормалдуу, success rate туруктуу, orphaned <максаттуу.
Ачык трасса жана дашборддор "кадамдар боюнча", burn-rate алерта.
Чейрек game-day жана кол runbook ордун текшерүү.

19) Корутунду

Сага бөлүштүрүлгөн системалар үчүн практикалык шайкештик келишими болуп саналат: так кадамдар жана тескери иш-аракеттер, жарыялоо тартиби (outbox/inbox), мөөнөт жана ретра, байкоо жана компенсация процесстери. моделин тандоо (оркестр/хореография/TSS), invariants жана ачкычтарды бекитүү, иштеткичтерди демпотенттик кылуу - жана сиздин көп кызматтуу бизнес-процесстер кымбат 2PC жок алдын ала жана туруктуу болуп калат.