შაბლონის საგა და განაწილებული გარიგებები

საგა შაბლონი და განაწილებული გარიგებები

1) რატომ გვჭირდება საგები

კლასიკური 2PC (ორფაზიანი ფიქსაცია) ცუდად მასშტაბურია, უარის თქმის ქვეშ არის და ბლოკავს რესურსებს. საგა არღვევს საერთო ბიზნეს პროცესს ადგილობრივი გარიგების (ნაბიჯების) თანმიმდევრობით, რომელთაგან თითოეული დამოუკიდებლად აკრედიტებულია. წარუმატებლობის შემთხვევაში, შემდგომი ნაბიჯები გაუქმებულია, ხოლო უკვე შესრულებული - ანაზღაურდება საპირისპირო ოპერაციებით.
შედეგი: კონტროლირებადი ღონისძიების შემოწმება გლობალური დაბლოკვის გარეშე, მაღალი გადარჩენა და აღდგენის აშკარა პროტოკოლი.

2) ძირითადი მოდელები

2. 1 ორკესტრი

საგას გამოყოფილი კოორდინატორი აკონტროლებს ნაბიჯებს: აგზავნის ბრძანებებს, ელოდება პასუხებს/მოვლენებს, იწყებს კომპენსაციას.
უპირატესობები: ცენტრალიზებული კონტროლი, მარტივი დაკვირვება, აშკარა ვადები. უარყოფითი მხარეები: დამატებითი კომპონენტი.

2. 2 ქორეოგრაფია

კოორდინატორი არ არის; სერვისები რეაგირებენ ერთმანეთის მოვლენებზე (OrderPlaced და PayseCaptured და InventoryReserved...).
დადებითი: სუსტი კავშირი. უარყოფითი მხარეები: უფრო რთულია თვალყურის დევნება, „სიკვდილის ცეკვის“ რისკი მკაფიო წესების გარეშე.

2. 3 TCC (Try-Confirm/Cancel)

1. Try - ტრენინგი/რეზერვი,

2. Confirm - ფიქსაცია,

3. კანკელი არის უკან დაბრუნება.

გარანტიები უფრო მაღალია, მაგრამ უფრო რთულია კონტრაქტები და რეზერვების ტაიმაუტები.

3) ნაბიჯებისა და კომპენსაციის ხელშეკრულებები

თითოეული ნაბიჯი = ადგილობრივი გარიგება + ანაზღაურება (იდემპოტენტი, განმეორება).
ანაზღაურება არ არის ვალდებული მთლიანად „დაუბრუნოს სამყარო“ - საკმარისია აფეთქების ღუმელის ეკვივალენტი (მაგალითად, „დაბრუნების გადახდა“ „გადახდის ამოღების“ ნაცვლად).
განსაზღვრეთ ინვარიანტები: ფულისთვის - ბალანსი არ მიდის მინუსში; შეკვეთებისთვის - არ არსებობს „ჩამოკიდებული“ სტატუსები.
შეიყვანეთ ვადები/TTL რეზერვები და „garbage კოლექციონერი“ ვადაგადაცილებული მცდელობებისთვის.

4) მიწოდების კოორდინაცია და სემანტიკა

შეტყობინებების მიწოდება: at-least-once (ნაგულისხმევი), ყველა ოპერაცია უნდა იყოს იდემპოტენტური.
ბრძანება: მნიშვნელოვანია კორელაციის ღილაკით (მაგალითად, 'order _ id', 'player _ id').
Exactly-once არ არის საგის მიზანი; ჩვენ მივაღწევთ ეფექტურ ერთჯერადობას idempotent გასაღებების, outbox/inbox და სწორი კომიტაციის საშუალებით.

5) საგას მდგომარეობა და მისი საწოლი

• 'saga _ id', 'correlation _ id', მიმდინარე სტატუსი (Running/Completed/Compensating/Compensated/Failed),
• ნაბიჯი და მისი ცვლადები (IDS გადახდები/რეზერვები),
• მოვლენების/გადაწყვეტილებების ისტორია (ჟურნალი), დრო, ვადა, რეციდივების რაოდენობა.

• ცალკეული საგა მაღაზია (ცხრილი/დოკუმენტი), რომელიც ხელმისაწვდომია კოორდინატორისთვის.
• ქორეოგრაფიისთვის - ადგილობრივი „აგენტები“ საგები, რომლებიც აქვეყნებენ სტატუსის მოვლენებს საერთო ტოპიკაში.

6) საიმედო პუბლიკაციის ნიმუშები: outebox/inbox

Outbox: ნაბიჯი აკავშირებს ცვლილებებს და წერს მოვლენას/გუნდს outbox ცხრილში ერთ გარიგებაში; ვორკერი აქვეყნებს საბურავებს.
Inbox: მომხმარებელი აწარმოებს დამუშავებული „მესიჯის _ id“ ცხრილს + idempotence.
წარმატებული გვერდითი ეფექტის შემდეგ, 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) ვერ მოხერხდა 'CancelPaysHold';
• თუ (4) ვერ მოხერხდა (3) შემდეგ 'ReleaseInventory';
• თუ (5) ვერ მოხერხდა 'RefundPayment' და 'ReleaseInventory'.

7. 2 ვადა/აღდგენა

მაქსიმალური N რეაგირება ექსპონენციალური შეფერხებით + ჯიტერი.
გადაჭარბების შემდეგ - გადასვლა „კომპენსაციაში“.
შეინახეთ შემდეგი _ attempt _ at და deadline _ at თითოეული ნაბიჯისთვის.

8) ორკესტრის პლატფორმა

• მსუბუქი სახლის ორკესტრი (მიკრო სერვისი + საგა ცხრილი).
• პლატფორმები: Temporal/Cadence, Camunda, Netflix Conductor, Zeebe - იძლევა ტაიმერებს, retrai- ს, ხანგრძლივ ვარჯიშს, ხილვადობას და ვებ კონსოლს.
• ქორეოგრაფიისთვის გამოიყენეთ ღონისძიებების კატალოგი და მკაცრი ხელშეკრულება სტატუსის/გასაღებების შესახებ.

9) ინტეგრაციის ოქმები

9. 1 ასინქრონო (კაფკა/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) ნაბიჯის შიგნით

დასაშვებია „მოკლე“ ნაბიჯებისთვის, მაგრამ ყოველთვის ტაიმაუტებით/რეპრესიებით/იდემპოტენტურობით და ასინქრონული კომპენსაციით.

10) Idempotence და გასაღებები

გუნდების მოთხოვნით და კომპენსაციით, გადაიტანეთ 'idempotency _ key ".
გვერდითი მოვლენები (BD/ჩამოწერის ჩანაწერი) პირობითად ხორციელდება: "თუ თქვენ ჯერ კიდევ არ გინახავთ" idempotence _ key ".
კომპენსაცია ასევე იდემპოტენტურია: 'RefundPayment (id = X)' გამეორება უსაფრთხოა.

11) შეცდომის დამუშავება

• გადამისამართება (ქსელები/ტაიმაუტები) - rettrai/backoff.
• ბიზნესი (საკმარისი სახსრები, შეზღუდვები) არის დაუყოვნებელი ანაზღაურება/ალტერნატიული გზა.
• Irrecoverable (ინვარიანტის დარღვევა) - სახელმძღვანელო ჩარევა, „სახელმძღვანელო“ ანაზღაურება.
• ააშენეთ გადაწყვეტილებების მატრიცა: შეცდომის ტიპი - მოქმედება (retry/compensate/escalate).

12) დაკვირვება და SLO საგნები

• საგნების დასასრული (p50/p95/p99).
• Success rate (კომპენსაციის გარეშე დასრულებული წილი).
• Mean time to compensate и compensation rate.
• Orphaned sagas (ჩამოკიდებული) და დრო GC- მდე.
• კვალი: 'trace _ id '/' saga _ id', როგორც span link ნაბიჯებს შორის; შეცდომების საბიუჯეტო მეტრიკა.

ლოგიკა: საგას სტატუსის თითოეული ცვლილება = სტრუქტურირებული ჩანაწერი მიზეზით.

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. კომპენსაცია 'დაწყებულია' payments. cancel/refund`, `inventory. release`.

14) შედარება 2PC და ES

2PC: ძლიერი კოორდინაცია, მაგრამ ბლოკირება, ვიწრო ადგილები, „სპილენძის მილები“.
საგა: საღამოს კონსულტაცია, საჭიროა კომპენსაციისა და ტელემეტრიის დისციპლინა.
ღონისძიება Sourcing: იცავს მოვლენებს, როგორც ჭეშმარიტების წყაროს; მასზე საგები ბუნებრივია, მაგრამ ამატებენ მიგრაციის/სნაიპშოტების სირთულეს.

15) უსაფრთხოება და შესაბამისობა

ტრანსპორტის თავისებურება (TLS/mTLS), ACL per topic/queue.
მოვლენებში - მინიმუმ PII, მგრძნობიარე ველების დაშიფვრა, ტოკენიზაცია.
საგებსა და კომპენსაციის ჟურნალებზე წვდომის აუდიტი.
SLA გარე პროვაიდერებით (გადახდა/მიწოდება) = ვადაგადაცილებული პარამეტრები და მიმღების ლიმიტები.

16) განხორციელების სიის სია (0-45 დღე)

0-10 დღე

განასხვავეთ კანდიდატის პროცესები (მრავალ სერვისით, კომპენსაციით).
შეარჩიეთ მოდელი (ორკესტრი/ქორეოგრაფია/TSS) და კორელაციის გასაღები.
აღწერეთ ნაბიჯები/ანაზღაურება, ინვარიანტები და ვადები. ასწიეთ ცხრილები 'saga', 'outbox', 'inbox'.

11-25 დღე

ჩართეთ outbox/inbox, idempotence და retrais backoff- ით.
გამოიცანით პირველი საგები; დაამატეთ დაშბორდები SLI/SLO და ტრეკერი.
დაწერეთ runbook ანაზღაურება (ხელის ჩათვლით) და ესკალაცია.

26-45 დღე

ავტომატიზირებული GC „ჩამოკიდებული“ საგნები, პერიოდული გადატვირთვა/გაგრძელება ვადაზე.
გაატარეთ თამაშის დღე: ნაბიჯის უკმარისობა, ვადის გადალახვა, ბროკერის მიუწვდომლობა.
სტანდარტიზებული ღონისძიებების კონტრაქტები (ვერსიები, თავსებადობა), ჩამოაყალიბეთ „საგნების კატალოგი“.

17) ანტი შაბლონები

„ანაზღაურება = delete BD- დან“ დომენური სწორი საპირისპირო მოქმედების ნაცვლად.
არ არსებობს outbox/inbox - მოვლენების დაკარგვა/ორმაგი ეფექტები.
Retrai ჯიტერის გარეშე - თავად DDoS დამოკიდებულებები.
ძლიერი თანმიმდევრობის მოლოდინი კითხვაზე „დამუშავების გარეშე“...
ერთი გიგანტური ორკესტრი ყველა საკონტროლო მონოლითისთვის.
ტოტალური ქორეოგრაფია ხილვადობის გარეშე და SLA არის უკონტროლო ცეკვა.
ვადების უგულებელყოფა - მარადიული რეზერვები/ჰოლები.

18) სიმწიფის მეტრიკა

კრიტიკული პროცესების 90% -ზე მეტი დაფარულია საგებით/კომპენსაციებით და აქვთ აღწერილი ინვარიანტები.
Outbox/inbox ინტეგრირებულია ყველა მწარმოებლისთვის/Tier-0/1 კონსიუმისთვის.
SLO: p95 end-to-end საგა ნორმალურად, სტაბილური success, orphaned <სამიზნე.
გამჭვირვალე ტრეკერი და დაშბორდები „ნაბიჯებზე“, ხრახნიანი ალერტა.
კვარტალური თამაშის დღე და ხელით runbook კომპენსაციის შემოწმება.

19) დასკვნა

საგა არის პრაქტიკული თანმიმდევრული ხელშეკრულება განაწილებული სისტემებისთვის: მკაფიო ნაბიჯები და საპირისპირო მოქმედებები, პუბლიკაციის დისციპლინა (outbox/inbox), ვადები და რეაგირება, დაკვირვება და კომპენსაციის პროცესები. შეარჩიეთ მოდელი (ორკესტრი/ქორეოგრაფია/TSS), დააფიქსირეთ ინვარიანტები და გასაღებები, გააკეთეთ იდემპოტური დამამზადებლები - და თქვენი მრავალ სერვისის ბიზნეს პროცესები გახდება პროგნოზირებული და სტაბილური ძვირადღირებული 2PC- ის გარეშე.