შეტყობინებების რიგები: Kafka და RabbitMQ

შეტყობინებების რიგები: Kafka, RabbitMQ

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

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

• Apache Kafka არის განაწილებული ღონისძიების ჟურნალი (ჟურნალი), რომელიც ორიენტირებულია ნაკადის დამუშავებაზე, რეპლიკაციაზე და ჰორიზონტალური სკეილინგის საშუალებით.
• RabbitMQ არის AMQP ხაზის ბროკერი მოქნილი მარშრუტიზაციით (exchanges/bindings), პრიორიტეტებით, TTL, დადასტურებებით და რიგების კლასიკური ამოცანებით.

ორივე ინსტრუმენტი სექსუალურია, მაგრამ გადაჭრის სხვადასხვა პრობლემას: კაფკა - მასშტაბური ნაკადებისა და ანალიტიკოსებისთვის, RabbitMQ - დავალებების ოპერატიული ორკესტრისთვის, RPC და მრავალფეროვანი მარშრუტიზაციისთვის.

სადაც შესაფერისია iGaming

• ჩვენ გვჭირდება მაღალი TPS მოვლენები (ფსონები, თამაშის მოვლენები, ტელემეტრია) და ჰორიზონტალური სკეიტი ნაწილების საშუალებით.
• ცივი/ცხელი რ-კონსიუმი (ლენტიანი მონაცემების ხელახალი კითხვა), რეტენინგი და აგრეგატებისთვის კომპაქტური (ბალანსი, მოთამაშის მდგომარეობა) მნიშვნელოვანია.
• ჩვენ გვჭირდება ნაკადის პროცესები (Kafka Streams/ksqlDB/Flink) რეალითი აგრეგატებისთვის: ტურნირების ლიდერები, საპასუხო თამაშის ლიმიტები, ანტიფროდიული სიგნალები.

• ჩვენ გვჭირდება დავალებების კლასიკური რიგები: KYC შემოწმება, გადავადებული/განმეორებითი გადახდები, ელექტრონული ფოსტის/SMS/push- ის გაგზავნა, webhooks PSP- ზე.
• მოქნილი მარშრუტიზაცია (topic/პირდაპირი/fanout), პრიორიტეტები, TTL, delay, dead-letter და RPC ნიმუშები.
• საჭიროა მკაცრი per-consumer შეზღუდვები (prefetch/QoS), დატვირთვის მარტივი კონტროლი და სწრაფი ჭრილობები.

ხშირი შედეგი: კაფკა მოვლენებისა და ანალიტიკოსებისთვის + RabbitMQ ორკესტრისა და ინტეგრაციისთვის.

მონაცემთა მოდელი და მარშრუტიზაცია

Kafka

ტოპიკები დაყოფილია ნაწილებად, თითოეული არის შეკვეთილი ლოგი.
შეტყობინებების გასაღები განსაზღვრავს წვეულებას - შეკვეთას, როგორც გასაღების ნაწილს.
კონსიუმერები კითხულობენ offset- ს, საკონსულტაციო ჯგუფები ამუშავებენ დამუშავებას.
დროის/მოცულობის ჭრა; log compaction ინახავს გასაღების ბოლო ვერსიას.

RabbitMQ

Exchanges (პირდაპირი/fanout/topic/headers) + bindings შეტყობინებები მოხვდება queues- ში.
დადასტურებები (ack/nack/requeue), publisher confirms, priorities, TTL, dead-letter (DLX/DLQ).
Érum queues (რაფტი) მაღალი ხელმისაწვდომობისთვის; lazy queues RAM დაზოგვისთვის.

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

At-most-once: რეაგირების გარეშე; ზარალის რისკი, მინიმალური შეფერხება.
At-least-once: სტანდარტული სტანდარტი - შესაძლებელია დუბლიკატები - idempotent hundlers (მოთხოვნის/გარიგების გასაღები, upsert, dedup ცხრილი, outbox).
Exactly-once: Kafka- ში, idempotent მწარმოებელი + გარიგების ტოპები + შეთანხმებული მოხმარება მიიღწევა, მაგრამ უფრო ძვირი და რთულია; RabbitMQ- ში - შეზღუდული და ძვლები. რეალურ გადახდის/განაკვეთების ნაკადებში გამოიყენება at-least-once + მკაცრი იდემპოტენტობა.

• უნიკალური idempotence-keys (UUID/ULID) ღონისძიება/გუნდი.
• Outbox შაბლონი სერვისის BD + Change Data Capture (Debezium) - „ორმაგი ჩაწერის“ თავიდან აცილება.
• Dedup (key, created _ at) ცალკე სვეტში TTL- ით.

შეკვეთა/შეტყობინებების რიგი

კაფკა გარანტიას უწევს წესრიგს პარტიის შიგნით. შეარჩიეთ გასაღები ისე, რომ ერთი მხრივ აღმოჩნდეს არსის მთელი „ცხოვრება“ (მაგალითად, „თამაში _ id“ ბალანსისთვის).
RabbitMQ ბრძანება მკაცრად არ არის გარანტირებული განმეორებითი მიწოდების/რამდენიმე კონსუტერის დროს; Payplines- ის შეკვეთის კრიტიკა უკეთესია Kafka- ში ან single-act consumer- ის საშუალებით და ნაკადის სერიალიზაციით.

ტოპებისა და რიგების დიზაინი

• შეზღუდვა: 'domain. ღონისძიება '(მაგალითად,' payments. deposit. created`).
• გასაღებები: 'player _ id', 'account _ id', 'bet _ id' შეკვეთისთვის.
• წვეულებები = N სამიზნე TPS- ის მიხედვით (წესი: 1 წვეულება X შეტყობინებები/s/Consumer); გაზრდის მარაგი.
• Retenshn: მოვლენები - საათი/დღეები; კომპაქტური - „სახელმწიფოებისთვის“.

• Exchanges დომენებზე: 'payments. direct`, `risk. topic`.
• რიგები მომხმარებლებისთვის: 'kyc. checker. q`, `psp. webhooks. retry. q`.
• DLQ თითოეული სამუშაო; delay for backoff.
• Prefetch ადგენს პარალელიზმს, რიგს -- rum - HA- სთვის.

შეცდომები, რეტრაები და DLQ

შეცდომების კლასიფიკაცია: დროებითი (ქსელის/PSP 5xx) და retrai; ფატალური (სავალდებულო, სქემა) დაუყოვნებლივ DLQ.
Exponential backoff + jitter, retrais ლიმიტი, „poison-pill“ დეტექტივი.
ცალკეული retry queues ნაბიჯებზე (5s, 1m, 5m, 1h).
DLQ დამუშავება: ალერტი, ტრეისი, სახელმძღვანელო ანალიზი, რეინჟექცია პატჩით.

მონაცემთა და სქემების ხელშეკრულება

გამოიყენეთ Avro/Protobuf + Schema Registry (Kafka- სთვის - დე ფაქტო სტანდარტი).
ვარიანტირება: backward-compatible ცვლილებები (სურვილისამებრ ველების დამატება), დამანგრეველი მიგრაციის აკრძალვა.
PII ველები - დაშიფვრა/ტოქსიკაცია; დაიცავით GDPR და ადგილობრივი სტანდარტები.

მონიტორინგი, დაკვირვება და SLO

მწარმოებლების/კონსიუმერების მეტრიკა: lag, throughput, შეცდომები, ჭიდაობა, დამუშავების დრო.
Logs + tracing (კორელაციის ID: 'trace _ id', 'მესიჯი _ id').
SLO: პუბლიკაციის/მიწოდების p99 ლატენტობა, დასაშვები consumer lag, გამოჯანმრთელების დრო ყალბების შემდეგ.
ალერტები DLQ- ის ზრდისთვის, lag- ის გადაჭარბება, წვეულებების/კვორუმის ვარდნა.

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

TLS ტრანზიტში, საიდუმლოების დაშიფვრა (SOPS/Vault), შეზღუდული ACL/RBAC.
ინდივიდუალური ტოპიკა/ხაზები მგრძნობიარე დომენებისთვის (გადახდები, KYC).
პუბლიკაციების/ხელმოწერების აუდიტს, კლავიშების შენახვას კოდის გარეთ.
რეგიონალური მოთხოვნები (EU/თურქეთი/LatAm): გადაშენება, შენახვის ლოკალიზაცია, შენიღბვა.

მაღალი წვდომა, წინააღმდეგობა და DR

• მინიმუმ 3-5 ბროკერის მტევანი; replication. factor ≥ 3.
• min. insync. replicas და acks = all ძლიერი ჩანაწერებისთვის.
• ჯვარედინი რეგიონალური რეპლიკაცია (MirrorMaker-2) DR- სთვის.

• ~ rum queues for HA, თანაბარი/უცნაური ნომრები კვორუმით.
• Federation/Shovel ურთიერთგაგების ცენტრის რეპლიკაციისთვის, DR სცენარები.
• ცივი/თბილი სტენდი, გადართვის ტესტები.

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

• `linger. ms` и `batch. size 'batching;' compression. type` (lz4/zstd).
• 'acks = all', მაგრამ ლატენტობის მონიტორინგი; tun 'max. in. flight. requests. per. კავშირი "იდემპოტენტურობით.

• საკმარისია წვეულებები; NVMe დისკები; ქსელი 10/25G; GC პარამეტრები JVM.

• სწორი მენეჯმენტის ჯგუფი, 'მაქსი. poll. interval. ms ', შეაჩერეთ წვეულებები ზურგჩანთაში.

• Publisher confirms ბრძოლებში; არხების გამოყენება.

• 'prefetch' (მაგ. 50-300) დამუშავების დროს; lazy queues დიდი baclogs.
• ცხელი ხაზების გადატანა. Tun TSR/ფაილური აღწერილობა.

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

Outbox + Kafka დომენის მოვლენების საიმედო გამოქვეყნებისთვის (განაკვეთი განთავსებულია, ანაბარი ირიცხება).
RabbitMQ RPC ინტეგრაციის სინქრონული მოთხოვნებისთვის (KYC დოკუმენტის შემოწმება, ბონუსის გაანგარიშება).
საგა პატრონი: ორკესტრი ღონისძიებების საშუალებით (კაფკა) და გუნდები (RabbitMQ) კომპენსაციური ნაბიჯებით.
Fan-out შეტყობინებები: ერთი მოვლენიდან - CRM, ანტიფროდი, ანალიტიკა.
Smart-retry PSP ვებჰუკები პროგრესული შეფერხებებით და DLQ.

მიგრაცია და ჰიბრიდული არქიტექტურები

დაიწყეთ RabbitMQ- ით „ოპერატორისთვის“, დაამატეთ Kafka მოვლენებისა და ანალიტიკოსებისთვის.
დუბლირებული პუბლიკაციები: outbox სერვისი ორივე მიმართულებით კონექტორი (Kafka + RabbitMQ) სრულ სტაბილიზაციამდე.
თანდათანობით გადაიტანეთ ანალიტიკური/ნაკადის აგრეგატები Kafka Streams/ksqlDB- ში.

მინი შემოწმების სია

1. დატვირთვა/TPS> ათეული ათასი/წმ? - კაფკა.
2. გჭირდებათ რეტენშინი და ხელახალი კითხვა, როგორც ჟურნალიდან? - კაფკა.
3. მოქნილი მარშრუტიზაცია, პრიორიტეტები, გადავადებული მიწოდება, RPC? - RabbitMQ.
4. მკაცრი შეკვეთა და ჰორიზონტალური skale არის Kafka (გასაღები/ნაწილი).
5. მარტივი დავალებები/ქურდობა პარალელიზმის კონტროლით - RabbitMQ.
6. იდეალურ შემთხვევაში - კომბინაცია: Kafka (მოვლენები) + RabbitMQ (ორკესტრი).

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

მაგალითი: RabbitMQ- ში დაკავებული retrai და DLQ (პოლიტიკის საშუალებით)

სამუშაო ხაზი: 'psp. webhooks. q`

ჭიდაობის ხაზი: 'psp. webhooks. retry. 1m. q '(TTL = 60s, DLX მიუთითებს სამუშაო უკან)

DLQ: `psp. webhooks. dlq`

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

მაგალითი: კაფკას ტოპიკი განაკვეთებისთვის

ტოპიკი: 'bets. placed. v1 ', წვეულებები: 24, RF = 3, ჭრელი 7 დღე.
შეტყობინებების გასაღები: 'player _ id' ან 'bet _ id' (შეარჩიეთ რა არის უფრო მნიშვნელოვანი წესრიგისთვის).
Схема: Protobuf/Avro с `bet_id`, `player_id`, `stake`, `odds`, `ts`, `idempotency_key`.

ტესტირება და ხარისხი

Contract ტესტები Producer/Consumer + სქემების შემოწმება (Schema Registry).
Chaos ტესტები: ღამის ვარდნა, ქსელის შეფერხება, split-brain.
დატვირთული ბილიკები სამიზნე TPS- ით, p99 შემოწმება, lag ზრდა და აღდგენა.

შედეგები

კაფკა - ღონისძიების გზატკეცილი და ნაკადი: კლავიშების შეკვეთა, რეტენსი/კომპაქტური, მაღალი TPS, რეალურ დროში ანალიტიკა.
RabbitMQ - ამოცანების ოპერაციული ხაზი: მოქნილი მარშრუტიზაცია, დადასტურება, პრიორიტეტები, retray/DLQ, RPC.
IGaming- ს აქვს საუკეთესო პრაქტიკა - კომბინირებული გამოყენება: მოვლენები და ანალიტიკა კაფკაში, ინტეგრაციის/ორკესტრის დავალებები RabbitMQ- ში, სქემების ერთიანი სტანდარტებით, idempotention, მონიტორინგი და მკაცრი SLO.