Broker მესიჯი და მოვლენების მარშრუტი

(განყოფილება: ტექნოლოგიები და ინფრასტრუქტურა)

მოკლე რეზიუმე

Broker მესიჯი არის ინტეგრაციისა და მოვლენის საბურავის ფუნდამენტური ფენა iGaming- ში. იგი ახორციელებს შეტყობინებების მიწოდებას, ბუფერიზაციას და მარშრუტიზაციას მიკრო სერვისებს შორის განაკვეთების, გადახდების, ანტიფროდის, KYC, CRM და ანალიტიკოსებს შორის. კომპეტენტურად შემუშავებული გამყიდველები (exchanges), რიგები, მარშრუტიზაციის გასაღებები და ხელახალი მიწოდების წესები უზრუნველყოფენ დაბალ შეფერხებას, ტრაფიკის გამძლეობას და პროგნოზირებადი SLO.

ბროკერის როლი iGaming პლატფორმაში

სერვისების დეკუპლინგი: მოვლენების გამოქვეყნება მკაცრი სინქრონული ზარების ნაცვლად.
მოქნილი მარშრუტიზაცია: ერთი ivent - ბევრი მომხმარებელი (CRM, რისკი, ანალიტიკა).
დატვირთვის კონტროლი: რიგები, prefetch/QoS, backpresher.
საიმედოობა და აღდგენა: დადასტურება, აღდგენა, DLQ, რეპლიკაცია.
აუდიტი და შესაბამისობა: მოვლენების ტრეკირება, PII შენიღბვა, შენახვის პოლიტიკა.

შეტყობინებების მოდელები

Point to-Point (დავალებების ჯერი): ერთი მომხმარებელი ამუშავებს დავალებას (KYC, ელექტრონული ფოსტა, PSP webhook).
Pub/Sub (დომენის მოვლენები): გაცვლის გამოცემა გულშემატკივართა გადაადგილებით რამდენიმე რიგისთვის.
RPC ბროკერის საშუალებით: მოთხოვნა/პასუხი კორელაციასთან (იშვიათად „ცხელ“ ტრასებზე, მაგრამ სასარგებლოა ინტეგრაციისთვის).

მარშრუტიზაციის ცნებები (AMQP კლასიკა)

1. პირდაპირი - ზუსტი დამთხვევა „routing _ key“.

2. topic - შაბლონები 'a. b. c's "(ერთი სიტყვა) და '#' (0 + სიტყვები). უნივერსალური არჩევანი.

3. fanout - სამაუწყებლო ყველა დაკავშირებული ხაზი.

4. headers - მარშრუტიზაცია სათაურებით (გასაღები/მნიშვნელობა), სასარგებლოა რთული პოლიტიკოსისთვის.

• `payments. psp. stripe. succeeded`, `payments. psp..failed`, `bets. live. #`, `rg. limit. breach`.
• დომენების გაცვლა: 'payments. topic`, `bets. topic`, `risk. topic`; ცალკეული - სისტემის მოვლენებისთვის 'platform. audit`.

რიგები და პოლიტიკა

სამუშაო ეტაპი: მოიხმარს ბიზნეს ჰენდლერები.
Retry რიგები: TTL (delay) და DLX- ით ექსპონენციალური bacofs (მაგალითად, '5s-1m-5m-1h').
DLQ (Dead-Letter Queue): საბოლოო „ნაგავსაყრელი“ ჭიდაობის ამოწურვის შემდეგ.
Priorities: გადაუდებელი დავალებებისთვის (დასკვნები> წერილები).
Lazy/Qurum: lazy - RAM დაზოგვა დიდი ბეკლოგებით; -- rum - HA კონსენსუსის საფუძველზე.

• `work. q` → `x-dead-letter-exchange=retry. ex`
• `retry. 1m. q` → `x-message-ttl=60000`, `x-dead-letter-exchange=work. ex`
• `dlq. q '- მონიტორინგი და სახელმძღვანელო რემედიაცია

მიწოდებისა და წესრიგის გარანტიები

At-least-once - ნაგულისხმევი: დუბლიკატები შესაძლებელია, ხოლო იდემპოტენტურობა სავალდებულოა.
At-most-once არის მინიმალური შეფერხება, მაგრამ ზარალის რისკი („არა კრიტიკული“ სიგნალებისთვის).
Exactly-once - იშვიათად პრაქტიკულია ბროკერებში; მიიღწევა უფრო რთული და ძვირი. ფულისთვის: at-least-once + მკაცრი იდემპოტენტობა.

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

Idempotence და გარიგების პუბლიკაცია

Idempotence-Key შეტყობინებაში (ULID/UUID), დედაპლატი TTL- ით ან upsert გასაღებით.
Outbox შაბლონი: ღონისძიების ჩაწერა Outbox ცხრილში, როგორც ბიზნეს გარიგების ნაწილი, კონექტორი აქვეყნებს ბროკერს და გამორიცხავს „ორმაგ ჩანაწერს „/ზარალს.
კორელაციის მეტამონაცემები: 'მესიჯები _ id', 'trace _ id', 'causation _ id', 'tenant _ id'.

RPC ბროკერის საშუალებით (საჭიროებისამებრ)

მოთხოვნა ქვეყნდება 'reply _ to' და 'correlation _ id', პასუხი მოცემულია რიგში.
გამოიყენეთ შეზღუდული (გარე პროვაიდერები, სინქრონული შემოწმებები), გააკონტროლეთ ტაიმაუტები და ჩატის ტენდენცია (წინააღმდეგ შემთხვევაში, გადანაწილებულ მონოლითში დეგრადაცია).
ცხელი მომხმარებლის ბილიკებისთვის სასურველია ასინქრონული მოვლენები + სახელმწიფოს პროექცია.

მონაცემთა და სქემების კონტრაქტები

ფორმატები: Avro/Protobuf/JSON-Schema. JSON- სთვის - ჩაწერეთ ვერსია და სავალდებულო ველები.
ევოლუციის პოლიტიკა: backward-compatible ცვლილებები; აკრძალულია მიგრაციის გარეშე დარღვევა.
PII - ველების ტოქსიკაცია/დაშიფვრა; დანიშნულება (საიტი) და შენახვის ვადა.

შეცდომების დამუშავება, ჭიდაობა, DLQ

კლასიფიკაცია: დროებითი (ქსელი/5xx) - retrai; Fatal (validation/სქემა) - DLQ.
Exponential backoff + jitter, „poison-pill“ ეტიკეტის მცდელობების რაოდენობის შეზღუდვა.
გადავადებული მიწოდება: TTL/Delayed ბირჟის საშუალებით.
DLQ- ის ინსტრუმენტი „რეინჟექტორი მუშაობაში“ მიზეზის გაყალბების შემდეგ.

დაკვირვება და SLO

მწარმოებლის მეტრიკა: პუბლიკაციის სიჩქარე, შეცდომები/დადასტურება.
რიგების მეტრიკა: სიგრძე, მოხმარების სიჩქარე, ჭიდაობის პროცენტი, რიგში p99 დრო.
კონსიუმერები: lag, throughput, დამუშავების დრო, NACC- ის წილი.
SLO: p99 E2E ღონისძიების მიწოდების ლატენტობა X წამში; ხელმისაწვდომობა 99. 9%; DLQ-rate ≤ Y%.
ტრეისი: 'trace _ id '/' span _ id', logs 'მესიჯი _ id'.
ალერტები: DLQ/lage- ის ზრდა, კვორუმის ვარდნა, NACC- ის ზრდა, retry სტადიების „ჩამოსხმა“.

უსაფრთხოება და წვდომა

TLS/MTLS ტრანზიტში; კონფიდენციალური რიგების შენახვის დროს დისკზე დაშიფვრა.
RBAC/ACL: უფლებები საჯარო/საკონსულო vhost/namespace/ტოპიკაზე.
სეგმენტი: მგრძნობიარე დომენები (გადახდები/CCC) - ინდივიდუალური გადამცვლელი/მტევანი.
საიდუმლოებები Vault/SOPS; პუბლიკაციების/ხელმოწერების აუდიტის ჟურნალი.
მონაცემთა ლოკალიზაცია: რეგიონებში შენახვა და გადაშენება (ევროკავშირი, თურქეთი, ლატამი).

მაღალი წვდომა და DR

კვორუმის ხაზები/რეპლიკაცია, უცნაური რიცხვები, AZ- ის ანტი-აფინიტები.
კრიტიკული დომენებისთვის რეგიონალური რეპლიკაცია (federation/shovel).
რეგულაციები (runbook), პერიოდული DR სწავლებები (თამაშის დღე).
ტოპოლოგიის, როგორც კოდის (IaC) ვერსია არის განმეორებითი დეპოზიტები და სწრაფი მიმღები.

შესრულება და tuning

Projecer: Publisher Confirms, არხების ხელახალი გამოყენება, ასინქრონული პუბლიკაციები.
რიგები: prefetch დავალების საშუალო ხანგრძლივობისთვის; ლაზი ღრმა ბეკლოგებისთვის; „ცხელი“ რიგების ერთობლიობა.
ქსელი/OS: 10/25G, file descriptors, TCP tuning. JVM/GC - დატვირთვის პროფილის ქვეშ.
ტესტები ბურსტის დატვირთვაზე (მატჩები, ტურნირები, პიკის გადახდები).

ტიპიური მარშრუტიზაციის ნიმუშები iGaming- ისთვის

1. გადახდის მოვლენები:

Exchange: `payments. topic`

• `payments. psp. stripe. succeeded`
• `payments. psp..failed`
• `withdrawal. requested. #`

• `ledger. writer. q '(bind:' payments. #`)
• `crm. triggers. q '(bind:' payments... succeeded ')
• `risk. reviews. q '(bind:' withdrawal. #`)

2. ანტი-frodection (პირდაპირი + retry):

`risk. work. q` ← `risk. direct` (`routing_key=risk. check`)

`risk. retry. 1m. q '(TTL 60s-DLX უკან დაბრუნება' risk. direct`)

`risk. dlq. q 'საბედისწერო.

3. ნოტიფიკაცია (პრიორიტეტი):

`notify. fanout` → `email. q (prio)`, `sms. q`, `push. q`

პრიორიტეტები: დასკვნები/ლიმიტები უფრო მაღალია, ვიდრე მარკეტინგული ბიულეტენები.

4. აუდიტი და ტრეკები:

Bindings სათაურებით „{“ tenant „:“ X „“, critical „:“ ნამდვილი „“ - ცალკეული აუდიტის ხაზი.

მინიმალური შეტყობინებების სქემის მაგალითი (JSON)

json
{
"message_id": "01HX8H8Y6D6W0T1S2A3B4C5D6E",
"trace_id": "f4d2a1...e9",
"occurred_at": "2025-11-05T11:20:45. 321Z",
"tenant_id": "eu-1",
"schema_version": 3,
"event": "payments. psp. stripe. succeeded",
"payload": {
"payment_id": "pay_123",
"player_id": "p_987",
"amount": { "currency": "EUR", "value": 50. 00 },
"psp_tx": "tx_456",
"idempotency_key": "ulid_..."
}
}

ინტეგრაცია სხვა კონტურებთან

ნაკადი/ანალიტიკა: მნიშვნელოვანი თემები შეიძლება დუბლირებული იყოს დენის საბურავზე (Kafka/Redpanda) retenshing და reprocessing.
Fichestor: ონლაინ ფიჩების (Redis) და ოფლაინ წვეულებების (Parquet/OLAP) მოვლენები.
საგა ორკესტრი: ბრძანებები პირდაპირი/ტოპიკის საშუალებით, მოვლენები - pub/sub; კომპენსაციის ნაბიჯები - როგორც ცალკეული შეტყობინებები.

ჩეკის განხორციელების სია

1. განსაზღვრეთ დომენის მეტაბოლისტები და მარშრუტიზაციის გასაღებების სტანდარტი.
2. შეიმუშავეთ work/retry/DLQ თითოეული კრიტიკული ნაკადისთვის.
3. ჩართეთ publisher confirms, 'prefetch', პრიორიტეტები და სესხი, სადაც საჭიროა.
4. შეიყვანეთ idempotence-key, outbox და კორელაციის ID.
5. დაამტკიცეთ მონაცემთა სქემები და ევოლუციის წესები.
6. TLS/RBAC პარამეტრები, სეგმენტი დომენებზე/ტენანტებზე.
7. დაუსვით SLO და ალერტები (lag, DLQ-rate, p99).
8. მოამზადეთ DR გეგმა და ავტომატიზირებული IaC ტოპოლოგია.
9. ჩაატარეთ დატვირთული და ქაოსის ტესტები.
10. დოკუმენტირება მოახდინეთ ინციდენტებისა და DLQ- ის re-intect- ისთვის.

ანტიპატერები

ერთი „გიგანტური“ გადამცვლელი საკვანძო დისციპლინის გარეშე; შემთხვევითი ბინდი „როგორ უნდა“.
retry/DLQ- ის ნაკლებობა და დროებითი/საბედისწერო შეცდომების შერევა.
სინქრონული RPC ბროკერის თავზე მომხმარებლის ცხელ გზებზე.
Idempotence და outbox ნაკლებობა ორმაგი/ფულის დაკარგვა.
PII- ის ღია შენახვა, ყველასთვის საჯარო/საკონსულტაციო მთლიანი წვდომა.

შედეგები

კარგად შემუშავებული Messess Broker არის მოვლენების საიმედო არტერია, სადაც მარშრუტიზაცია პროგნოზირებულია, ხოლო უკონტროლო წინააღმდეგობა ინტეგრირებულია ტოპოლოგიის დონეზე. გამოიყენეთ topic გადამცვლელი, ერთი გასაღების სტანდარტი, work/retry/DLQ თითოეული კრიტიკული ნაკადისთვის, idempotence და outbox, მკაცრი SLO და დაკვირვებისთვის. ნაკადის საბურავთან და სახელმწიფო პროექციებთან ერთად, ეს აძლევს iGaming პლატფორმას სტაბილურ სიჩქარეს, გამჭვირვალობას და კონტროლს სირთულეზე, რადგან დატვირთვა იზრდება.