გარიგების მესიჯი

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

1) მიწოდების სემანტიკა

At-most-once: სწრაფი და იაფი, დანაკარგები შესაძლებელია, დუბლი არ არის.
At-least-once: არ კარგავს შეტყობინებებს, შესაძლებელია დუბლირება, საჭიროა იდემპოტენტობა.
(ეფექტური) Exactly-once: არ არსებობს ზარალი და არ არსებობს ხილული დუბლები ბიზნეს ეფექტებისთვის, მიიღწევა ტექნიკის ერთობლიობით (outbox/inbox, მწარმოებლის/კონსუტერის გარიგებები, დედაპლატი).

2) რატომ არის „ორი წერილი“ საშიში

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

3) ძირითადი ნიმუშები

3. 1 Outbox (მწარმოებელი)

ერთ ადგილობრივ გარიგებაში ჩაწერეთ ბიზნეს ცვლილება და სტრიქონი „outbox“ ცხრილში; ცალკე publisher კითხულობს outbox- ს და აქვეყნებს ბროკერს traves და backoff. ზარალი გამორიცხულია; ჩვენ მომხმარებლებს შორის idempotenture.

3. 2 Inbox/Idempotent Consumer (მომხმარებელი)

ეფექტის შესრულებამდე, კონსუტერს აკეთებს 'INSERT' inbox- ში (consumer, event _ id) 'როგორც პირველადი გასაღები. საკვანძო კონფლიქტი = მოვლენა უკვე დამუშავებულია და გამოტოვებულია. ეს მიიღწევა „ეფექტური exactly-once“.

3. 3 Read-Process-Write ოფსეტური გარიგებით

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

3. 4 TSS/საგები ოფისის ეფექტებისთვის

როდესაც საჭიროა შეთანხმებული მულტიშაგის პროცესი, ჩვენ ვიყენებთ TCC ან საგებს; შეტყობინებები - ბრძანებების/ღონისძიებების ტრანსპორტი, ხოლო გარიგება - ნაბიჯებისა და კომპენსაციის დონეზე.

4) Idempotent Projecers და Consumers

პროდიუსერი: სტაბილური 'მესიჯი _ id '/' idempotency _ key', იგივე გასაღებით ხელახალი გაგზავნა არ ქმნის ახალ ეფექტებს აბონენტებს შორის; შეინარჩუნეთ თანმიმდევრობა.
კონსიუმერი: 'inbox' + ბიზნეს idempotence (upsert/merge, ბოლო ვერსიის გადამოწმება/გადასინჯვა).

5) წესრიგი და მიზეზი

გაატარეთ ბიზნეს გასაღები (მაგალითად, 'aggregate _ id', 'tenant _ id') ისე, რომ ერთი ობიექტის მოვლენები წესრიგში მოვიდეს.
პარტიის შიგნით შეინარჩუნეთ თანმიმდევრული ნომრები/დროებითი ეტიკეტები; DLQ- ის რედაქციის დროს დაიცავით „გასაღები და თანმიმდევრულად“.
თუ გლობალური წესრიგი არ არის კრიტიკული, უზრუნველყეთ ადგილობრივი წესრიგი და დააფიქსირეთ დომენის ინვარიანტები.

6) ოფსეტები და ეფექტების დაფიქსირება

ვარიანტი A: „ოფსეტი მონაცემთა ბაზაში“

ჩაწერეთ „ბოლო დამუშავებული ოფსეტი (წვეულება, ოფსეტი)“ იმავე გარიგებაში, სადაც შეცვალეთ დომენის მონაცემები. რესტავრაციის დროს გააგრძელეთ შემდეგი ოფსეტიდან, თავიდან აიცილეთ ხელახალი ეფექტი.

ვარიანტი B: ბროკერის გარიგება

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

7) Retrai, backoff, DLQ

გაიმეორეთ მხოლოდ retraible შეცდომები (taymauts, 5xx), ექსპონენციალური backoff და jitter.
Non retraible (schema/validation) - დაუყოვნებლივ DLQ- ში მეტამონაცემებით (tenant, key, offset, მიზეზი).
DLQ redrive dotch (batch, rate limit), შეამოწმეთ სქემა გამეორების წინ, დააკვირდით წესრიგს.

8) მულტფილმები და რეგიონები

ჩართეთ 'tenant _ id', 'plan', 'region' მეტამონაცემებში და განაწილების გასაღებებში.
Per-tenant fairness: შეზღუდეთ პუბლიკაცია/დამუშავება ისე, რომ „ხმაურიანმა“ კლიენტმა არ ამოიღო ბიუჯეტი დანარჩენისგან.
Residence: შეინახეთ შეტყობინებები და გარედან იმავე რეგიონში, როგორც დომენის მონაცემები; ინტერრეგიონალური რეპლიკაციები - ასინქრონული ერთეულები.

9) დაკვირვება და აუდიტი

ტრეისი: კორელაცია 'event _ id '/' aggregate _ id '/' saga _ id', სპა „read 'process' write/commit“.
მეტრიკა: პუბლიკაციის/დამუშავების ლაგი (p95/p99), წარმატების წილი, DLQ-rate, რადარის წარმატება, „დუბლიკატები დათრგუნულია“.
ლოგიკა: მოკლედ წარმატებისკენ; შეცდომებზე დეტალურად (მიზეზი, მცდელობა, გასაღები, ოფსეტი).
აუდიტი: ვინ იშვიათი/გამოტოვა, რა ბრძოლა და რა შედეგით.

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

მინიმუმამდე დაიყვანეთ PII payload- ში; შენიღბვა DLQ/loga- ში გადატანისას.
ხელი მოაწერეთ/დაშიფვრეთ შეტყობინებები გარე საბურავებისთვის; გამოიყენეთ mTLS სერვისებს შორის.
აკონტროლეთ შენახვის ვადა და „დავიწყების უფლება“ per tenant/region.

11) სტანდარტული ინტეგრაციის სქემები

1. სერვისის წყარო (write-side)

ადგილობრივი გარიგება: დომენის ჩაწერა + გარეთ.
Pablisher: batch, 'SKIP LOCKED', backoff, per tenant ლიმიტები.
lage 'now − occurred _ at' - ის მონიტორინგი.

2. სამომხმარებლო მომსახურება (read-side)

Butch- ის კითხვა - მცდელობა 'INSERT inbox (consumer, event _ id)', წარმატების მისაღწევად.
ამავე გარიგებაში, ჩვენ აღვნიშნავთ „დასრულებულ ოფსეტს“ (ვარიანტი A) ან ეყრდნობა ბროკერის გარიგებას (ვარიანტი B).
შეცდომით: retray ან DLQ პოლიტიკა.

3. პროექცია/მატერიალიზებული სახეობა

მხოლოდ idempotent apdates (upsert), ბაბუის კომპაქტური გასაღებები, საკონტროლო თანხების პერიოდული შერწყმა.

12) კონფიგურაციის შაბლონები (მაგალითი)

yaml producer:
idempotency_key: event_id partition_key: "{tenant_id}:{aggregate_id}"
retry:
max_attempts: 8 initial_ms: 200 max_ms: 8000 strategy: exponential_full_jitter

consumer:
batch: 500 offset_commit: "with_domain_tx"  # или "broker_tx"
inbox_enabled: true concurrency_per_partition: 4 dlq:
enabled: true batch_redrive: 200 rate_limit_per_sec: 50 order_by_key: true

observability:
metrics:
- processing_lag_ms
- publish_success_ratio
- dlq_rate
- redrive_success_ratio tracing_tags: [event_id, tenant_id, aggregate_id, partition, offset]

13) ჩეკის სია გაყიდვამდე

• აღმოფხვრილი იქნა „ორი წერილი“: Outbox პროვაიზერზე ან ოფსეტის დაფიქსირება და ეფექტი ერთ გარიგებაში კონსიუმერთან.
• Idempotent Consumer: 'inbox '/dedup ჟურნალი, ოპერაციების ბიზნეს idempotence.
• ბიზნეს გასაღები, ადგილობრივი წესრიგი დაცულია.
• Retrai ერთად backoff + jitter, შეცდომების კლასიფიკაცია, DLQ მდიდარი მეტამონაცემებით.
• რედრივი დოზირებული, უსაფრთხო; არის playbooks.
• მულტფილმები-ჩრდილოვანი ლიმიტები და პრიორიტეტები; ჭდეები 'tenant _ id/plan/region'.
• ტელემეტრია: ლაგები, წარმატების წილი, „დუბლიკატები ჩახშობილი“, ალერტები p95/p99.
• პოლიტიკოსები PII/retenshna/დაშიფვრა დაცულია.
• ტესტები: ნაბიჯებს შორის ვარდნა, დუბლიკატები, გასაღები შეკვეთა, მასობრივი რადარი.

14) ტიპიური შეცდომები

საბურავზე გაგზავნა და მონაცემთა ბაზაში ჩაწერა ცალკეული ნაბიჯებით offset/გარიგების გარეშე.
Idempotence Consumer დუბლირებას უწევს გვერდითი მოვლენებს.
გლობალური წესრიგი „ნებისმიერ ფასად“ - გზები და იშვიათად გამართლებულია; საკმარისია გასაღები.
მასობრივი რადარი შეზღუდვების გარეშე - მეორადი ინციდენტი.
ტრეისინგის/ლაგ მეტრიკის არარსებობა არის „ფარული დეგრადაცია“.
PII ნაზავი DLQ/ლოგოებში.

15) სწრაფი რეცეპტები

SaaS მოვლენები: Outbox + idempotent Consumer (inbox), 'tenant _ id განაწილება: aggregate _ id'.
ETL/პროექციები: Read-process-write, ოფსეტების დაფიქსირება ერთ გარიგებაში, 500-1000 ბატები, upsert.
მაღალი დატვირთვა: საზოგადოებრივი შარდვა, 'SKIP LOCKED', WFQ per tenant, ლაგამის კონტროლი.
მკაცრი შესაბამისობის ზონა: რეგიონალური გარე ბოქსი, payload დაშიფვრა, retenshny და რედაქციის აუდიტი.

დასკვნა

გარიგების მესიჯი არის მონაცემთა და შეტყობინებების ერთობლიობის დისციპლინა. Outobox/inbox- ის კომბინაციით, idempotence, offsets- ის დაფიქსირება ეფექტებთან ერთად და კონტროლირებადი retrais ერთად DLQ, თქვენ იღებთ პრაქტიკულ exactly-once ქცევას გლობალური საკეტების გარეშე და ინარჩუნებთ SLO- ს, თუნდაც წარუმატებლობის, მწვერვალების და რთული და რთული მულტფილმების დროს.