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

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

1) რა უნდა აირჩიოს

RabbitMQ (AMQP 0-9-1 / 1. 0, კლასიკური ხაზები, ~ rum Queues, Streams)

შესაფერისია: RPC/გუნდები, workflow, მოკლე დავალებები, fanout/topic მარშრუტიზაცია, მოქნილი მტკიცებულებები, პრიორიტეტების მართვა.
დადებითი: მდიდარი მარშრუტიზაციის სემანტიკა (exchanges), 'basic. qos '(prefetch), per მესიჯი TTL/delay, მოსახერხებელი RPC ნიმუშები (reply-to), მარტივი დასაწყისი.
უარყოფითი: ისტორია ინახება რიგში, ჰორიზონტალური სკალირება რიგების/შარდების მიხედვით; მაღალი throughput ღირებულება ძალიან დიდი ნაკადებით.

Apache Kafka (მოვლენების ლოგო, წვეულება, consumer groups)

შესაფერისია: ღონისძიების ნაკადები, აუდიტი, ღონისძიების sourcing, ETL/ინტეგრაცია (Connect), მაღალი RPS/MBps, replay/re- დამუშავება, ნაკადის დამუშავება (Streams/ksqlDB).
დადებითი: გრძელვადიანი ჟურნალი, პარტიების მასშტაბები, სტაბილური რეპლიკა, საკვანძო კონტროლი.
უარყოფითი: „pull + წვეულება“ მოდელი - არა მცირე RPC- სთვის; შეკვეთა მხოლოდ პარტიაში; სქემების/თავსებადობის მართვა გუნდის მოვალეობაა.

2) მიწოდების სემანტიკა და ინვარიანტები

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

დომენის ინვარიანტები: ფული/ბალანსი - ჟურნალების/საგებისა და იდემპოტენტური გუნდების საშუალებით; ნუ დაეყრდნობით LWW- ს.

3) ინტეგრაციის ნიმუშები

Outbox/InBox: ღონისძიების ატომური ჩანაწერი BD- ში - პუბლიკაცია რიგში (outbox) და idempotent მოხმარება დამუშავების ლოგოთი (inbox).
DLQ (მკვდარი წერილები): N მცდელობების/შეცდომების შემდეგ - DLQ + ალერტში.
Retry/Delay: RabbitMQ — TTL + dead-letter exchange; Kafka - retry ტოპები backoff- ით.
Request/Reply: RabbitMQ — `reply_to` + `correlation_id`; კაფკა იშვიათია, მხოლოდ სპეციალური ნიმუშებით.
ანაზღაურება: საგნები მოვლენებზე; თითოეულ ოპერაციას აქვს საპირისპირო.

4) გასაღებების და ტოპოლოგიის დიზაინი

RabbitMQ

Exchanges: `direct`, `topic`, `fanout`, `headers`.
Routing key: განსაზღვრავს დარტყმას რიგში (და). პრიორიტეტისთვის - ინდივიდუალური ხაზები.
QoS: 'prefetch' (მაგალითად, 50-300) დაბალანსებს სიჩქარეს/ლატენტობას.
É rum Queues: რეპლიკირებული ხაზები რაფტისთვის; mirrored კლასიკური ჩანაცვლება.
Streams: ნაკადი offsets (Kafka-fan) მაღალი სიჩქარის-throughput/raple- ისთვის.

Kafka

Topic-partitions: დაგეგმეთ '# პარტნიორები "სამიზნე throughput- ისა და პარალელიზმის მიხედვით (საპირისპიროდ, გაზრდა უფრო ადვილია, ვიდრე შემცირება).
კეი: ერთი გასაღების ყველა ჩანაწერი ერთ ნაწილშია (გასაღები წესრიგის გარანტია).
რეპლიკაციის ფაქტორი: 3 პროდუქტიული თემებისთვის, 'min. insync. replicas = 2 '+' acks = all 'საიმედოობისთვის.
Retention: დროულად/ზომით; compaction - ინახავს ბოლო მნიშვნელობებს + tombstones გასაღების ამოღებისთვის.

5) Retrai, DLQ, idempotence

RabbitMQ

განმეორებები: per-მესიჯი TTL + DLX (dead-letter Exchange) backoff- დან (მაგალითად, 1m-5m-15m).
Idempotention: 'correlation _ id '/' message-id' + დამუშავებული შეტყობინებების ცხრილი (TTL) ან დეტერმინისტული ბრძანებები.
დადასტურება: manual 'basic. ack 'წარმატებული გარიგების შემდეგ;' basic. nack(requeue=false)` в DLQ.

Kafka

გამეორებები: ინდივიდუალური retry ტოპიკა; consumer აკავშირებს ოფისს წარმატებული side-effect შემდეგ.
Exactly-once processing (EOS): Producer `enable. idempotence = true ', გარიგების produmer/consumer,' read _ committed 'მომხმარებელზე; sink (მაგალითად, Kafka - Kafka ან Kafka - DB გარიგების საშუალებით) არის ზუსტად სინქრონიზაცია.
დედაპი: გასაღები/იდემპოტენტური გასაღები ბაზის მხარეს, ან კომპაქტური ტოპიკის საშუალებით.

6) პროდუქტიულობა და ზომა

Little კანონი

მძღოლებისთვის: საჭირო პარალელიზმი 'N - arrival _ rate × avg _ processing _ time × რეზერვი (1. 2–1. 5)`.
RabbitMQ prefetch: დაიწყეთ 'prefetch = 100' - ით და გაზომეთ r99/დრო „in-flight“.
Kafka partitions: გაანგარიშება სასურველი consumer პარალელიზმისა და მიზნის მიხედვით throughput (მაგალითად, 1 წვეულება სტაბილურად 5-20 MB/s SSD/10GbE).

7) დაკვირვება და ალერტა

• Lag/Backlog (შეტყობინებები/ბაიტი), შეტყობინებების განყოფილება (p95/p99), error-rate დამუშავება, DLQ-rate.
• დრო „გამოცემა-დამუშავება“ (end-end).
• დამოკიდებულების რუკა: მწარმოებელი - ბროკერი და კონსიუმერი.

• კავშირები, არხები, არაკომერციული შეტყობინებები, 'memory _ alarm', 'disk _ free _ limit', 'queue lengtht' p95.
• მოხსენებები # rum- ის შესახებ (leader, Raft log, გამოტოვება 'érum not enough').

• Under-replicated partitions, ISR shrink/expand, controller changes.
• Producer errors (timeouts, `request latency`), consumer lag per group/partition.
• Broker I/O, page cache hit, GC, ZooKeeper/KRaft health.

8) უსაფრთხოება და მრავალ ტენანტობა

TLS დაშიფვრა Transit, ავთენტიფიკაცია (SASL/PLAIN/SCRAM/OAuth, mTLS).
საავტორო უფლებები: vhost/permissions (RabbitMQ), ACL ტოპიკებზე/ჯგუფებზე (Kafka).
კვოტები: კავშირებზე, არხებზე, რიგის/ტოპიკის ზომაზე, გამოქვეყნების/კითხვის სიჩქარეზე.
იზოლაცია ოთხშაბათისთვის (dev/stage/with) და namespace/vhost.

9) ოპერაცია და tuning

RabbitMQ

გადაიტანეთ exchanges/queues კვანძებში (CPU/IO კაპიტული).
Lazy queues (შეტყობინებები დისკზე) დიდი ბუფერებისთვის; მოერიდეთ ცხელი ხაზების გარეშე.
~ rum Queues for HA; დაგეგმეთ რაფტის ჟურნალის ზომა და დისკი.
TTL/length-limit პოლიტიკოსები, პრიორიტეტული რიგები მხოლოდ რეალური საჭიროებისთვის (ძვირი).

bash rabbitmqctl set_policy DLX "^task\." \
'{"dead-letter-exchange":"dlx","message-ttl":60000,"max-length":100000}' --apply-to queues

Kafka

SSD/NVMe, სწრაფი ქსელები; OS tuning (დაბალი, ფაილური ლიმიტები).
`acks=all`, `linger. ms '(batching),' compression. ტიპი = zstd '/lz4 გამტარობისთვის.
მომხმარებლის პარამეტრები: 'max. poll. interval. ms`, `max. poll. records`, `fetch. min. bytes`.
Retention და compaction - საცავის/ფრენის ბალანსი.

java props. put("acks","all");
props. put("enable. idempotence", "true");
props. put("max. in. flight. requests. per. connection","1");
props. put("retries","10");

10) ინტეგრაცია და ეკოსისტემა

Kafka Connect (Sinks/Sources), Schema Registry (Avro/JSON/Protobuf) და თავსებადობა ('BACKWARD/FORWARD D D D D D).
Kafka Streams/ksqlDB: stateful ოპერაციები, ფანჯრები, აგრეგატები.
RabbitMQ Shovel/Federation: გადაცემა მტევნებს/ცენტრებს შორის.
ოპერატორები K8s: Strimzi (Kafka), RabbitMQ Cluster Operator; GitOps მანიფესტები.

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

0-10 დღე

განსაზღვრეთ use-case's: ბრძანებები/ტასკები (RabbitMQ), მოვლენები/აუდიტი (Kafka).
შეარჩიეთ გასაღებები ('routing key '/' partition key'), მიუთითეთ SLO „პუბლიკაცია და დამუშავება“.
უსაფრთხოების ძირითადი პოლიტიკა (TLS, ACL), კვოტები, DLQ/TTL.

11-25 დღე

შემოიღეთ outbox/inbox, idempotence და dedup.
Rackoff- ის კონფიგურაცია backoff- ით (Rabbit: TTL + DLX; Kafka: retry topics).
დაშბორდები: lag, age, DLQ-rate, end-to-end latency; ალერტა.

26-45 დღე

Tuning: prefetch/acks (Rabbit); partitions/acks/batch (Kafka).
DR პროცედურები (მარცვლეული/რეპლიკაცია), კვანძების უკმარისობის ტესტები.
ღონისძიებების (სქემების) და თავსებადობის პოლიტიკის დოკუმენტირება.

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

ყველა ამოცანის ერთი „უნივერსალური“ ინსტრუმენტი.
DLQ/TTL- ის არარსებობა: მარადიული მოწამვლა (poison messages).
შეუზღუდავი „prefetch“ - მომხმარებელთა მარხვა, ზრდა p99.
Kafka კლავიშების გარეშე - ნაგულისხმევი შეკვეთის/ცხელი ნაწილების დაკარგვა.
„Exactly-once“ რეალური საჭიროების/დისციპლინის გარეშე არის უსაფრთხოების ყალბი გრძნობა.
საიდუმლოებები/ლოგინები კოდში, TLS/ACL გარეშე.
Registry- ისა და მიგრაციის გარეშე შეტყობინებების სქემების/ვერსიების სქემა.

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

Lag/age SLO ასრულებს დროის 99% -ზე მეტს; DLQ-rate კონტროლდება.
Idempotence მოიცავს კრიტიკულ ბილიკების 100% -ს; დაინერგა outbox/inbox.
Retention/compaction არის დოკუმენტირებული, აბრევიატურა არ არღვევს მომხმარებლებს.
ალერტას ISR/URP (Kafka) და Raft/დისკის ლიმიტები (Rabbit).
ღონისძიების კონტრაქტები განახლებულია (Schema Registry), თავსებადობა ტესტირდება CI- ში.
რეგულარული თამაშის დღეები: კვანძის/ბროკერის/AZ უკმარისობა, აღდგენის შემოწმება.

14) ჩამორთმევის მაგალითები (ანგარიში)

python channel. basic_qos(prefetch_count=200)
for msg in consume("tasks"):
try:
handle(msg)
channel. basic_ack(msg. delivery_tag)
except Transient:
channel. basic_nack(msg. delivery_tag, request = False) # will go to DLQ

java props. put("enable. auto. commit","false");
props. put("isolation. level","read_committed"); // при EOS
//...
poll -> process(idempotent) -> commitSync()

15) დასკვნა

RabbitMQ და Kafka წყვეტენ პრობლემების სხვადასხვა კლასებს: გუნდები/ტასკები და მდიდარი მარშრუტი გრძელვადიანი ღონისძიებების ჟურნალის წინააღმდეგ და მასშტაბური ნაკადი. წარმატება - სწორი მიწოდების სემანტიკაში, idempotenty დისციპლინა, გააზრებული საკვანძო, მიმოწერა/DLQ, დაკვირვება და მკაცრი უსაფრთხოება. რიგების გარშემო ააშენეთ საინჟინრო პრაქტიკა - outbox/inbox, სქემები და GitOps პოლიტიკა - და თქვენი ინტეგრაცია გახდება პროგნოზირებადი, მასშტაბური და სტაბილური.