შეტყობინებების პროცედურის გარანტიები

1) რა არის „წესრიგი“ და რატომ არის საჭირო

შეტყობინებების რიგი არის დამოკიდებულება „რაც ადრე უნდა დამუშავდეს“ ერთი არსების მოვლენებისთვის (შეკვეთა, მომხმარებელი, საფულე) ან მთელი ნაკადისთვის. ეს მნიშვნელოვანია ინვარიანტებისთვის: „სტატუსი A B“, „ბალანსი გაუქმებამდე“, „ვერსია n + 1“.
განაწილებულ სისტემებში, გლობალური გზების სრული რიგი იშვიათად არის საჭირო; ჩვეულებრივ, ადგილობრივი შეკვეთა საკმარისია „გასაღებისთვის“.

2) წესრიგის გარანტიების ტიპები

1. Per-partition (ადგილობრივი შეკვეთა ლოგის განყოფილებაში) - Kafka: რჩება შეკვეთა პარტიის შიგნით, არ არსებობს მხარეებს შორის.
2. Per-key (ordering key/message Group) - ერთი გასაღების მქონე ყველა შეტყობინება ბრუნავს ერთი დამუშავების „ნაკადში“ (Kafka key, SQS FIFO PARK Groopid, Pub/Sub ordering key key).
3. გლობალური ტოტალური წესრიგი - მთელი სისტემა ხედავს ერთ წესრიგს (განაწილებული ჟურნალი/მიმდევარი). ძვირია, გაუარესდება წვდომა და throughput.
4. Causal order (მიზეზობრივი) - „მოვლენა B A შემდეგ, თუ B აკვირდება A ეფექტს“. ჩვენ მივაღწევთ მეტამონაცემების საშუალებით (ვერსიები, Lamport-Time/ვექტორული საათები) გლობალური მიმდევრობის გარეშე.
5. Best-effort order - ბროკერი ცდილობს შეინარჩუნოს წესრიგი, მაგრამ წარუმატებლობის შემთხვევაში შესაძლებელია permutations (ხშირად NATS Core, RabbitMQ რამდენიმე კონსიუმით).

3) სად იშლება წესრიგი

ერთი რიგის პარალელური კონსიუმერები (RabbitMQ: რამდენიმე კონსულტანტი ერთი მხრივ - ინტერლინგი).
Retrai/განმეორებითი მიწოდება (at-least-once), Timauts 'ack', რიგით ხელახალი წარმოება.
Rebalans/Faylover (Kafka: პარტიის/ლიდერის გადაადგილება).
DLQ/განმეორებითი დამუშავება - „შხამიანი“ შეტყობინება მიდის DLQ- ში, შემდეგი მიდის ლოგიკურ უფსკრული.
მულტფილმის რეგიონი და რეპლიკაცია - სხვადასხვა შეფერხება, რასინქრონიზაცია.

4) „შეკვეთის გასაღები“ დიზაინი

• გამოიყენეთ ბუნებრივი გასაღებები: 'order _ id', 'wallet _ id', 'gregate _ id'.
• დააკვირდით „ცხელ კლავიშებს“ - ერთ კლავიშს შეუძლია „დაბლოკოს“ ნაკადი. საჭიროების შემთხვევაში, გაყოფილი კლავიში: 'order _ id # shard (0.. k-1)' შეკვეთის დეტერმინისტული რეკონსტრუქციით.
• კაფკაში - ერთი გასაღები - ერთი წვეულება, შეკვეთა დარჩება გასაღებში.

java producer.send(new ProducerRecord<>("orders", orderId, eventBytes));

(გასაღები = 'orderId' გარანტირებულია ადგილობრივი შეკვეთით.)

5) „ბრძანება გამტარუნარიანობის წინააღმდეგ“

• რიგის ერთი კონსიუმერი ინარჩუნებს წესრიგს, მაგრამ ამცირებს პარალელიზმს.
• At-least-once + პარალელიზმი ზრდის პროდუქტიულობას, მაგრამ მოითხოვს იდეოლოგიურ ან/და წესრიგის აღდგენას.
• გლობალური წესრიგი ჰოპს მიმდევრობას უმატებს ლატენტობას და უარის თქმის რისკს.

კომპრომისი: per-key ბრძანება, პარალელიზმი = ნაწილების/ჯგუფების რაოდენობა, + იდემპოტენტური სისხლჩაქცევები.

6) წესრიგის კონტროლი კონკრეტულ ბროკერებში

Kafka

შეკვეთა პარტიის შიგნით.
დაიცავით „მაქსი“. in. flight. requests. per. connection ≤ 5` с `enable. idempotence = true 'ისე, რომ მწარმოებლის რეტრატორები არ შეცვლიან წესრიგს.
საკონსულტაციო ჯგუფი: ერთი პარტია - ერთი ქურდი დროის განმავლობაში. განმეორებითი მიწოდება შესაძლებელია - შეინარჩუნეთ sequence/ვერსია ბიზნეს ფენაში.
გარიგებები (read-process-write) ინარჩუნებს შესაბამისობას „წაიკითხეთ/ჩაწერილი/ჩაწერილი ოფსეტები“, მაგრამ არ ქმნიან გლობალურ წესრიგს.

properties enable.idempotence=true acks=all retries=2147483647 max.in.flight.requests.per.connection=5

RabbitMQ (AMQP)

ბრძანება გარანტირებულია ერთ რიგში ერთი კონსიუმისთვის. რამდენიმე შეტყობინებით შეიძლება მოვიდეს „შერევა“.
შეკვეთისთვის: ერთი კონსუმერი ან prefetch = 1 + ack ბოლოს. პარალელიზმისთვის, რიგები გაიზიარეთ კლავიშებზე (sharding exchanges/consistent-hash Exchanges).

NATS / JetStream

NATS Core - best-effort, დაბალი ლატენტობა, წესრიგის დარღვევა შესაძლებელია.
JetStream: მოწესრიგება ნაკადის/თანმიმდევრობის შიგნით; იშვიათობის შემთხვევაში, შესაძლებელია კონსიუმზე გადაკეთება - გამოიყენეთ sequence და აღდგენის ბუფერი.

SQS FIFO

Exactly-once processing (ეფექტურად, ბაბუის გამო) და შეკვეთა Corpus GroupId- ის შიგნით. პარალელიზმი ჯგუფების რაოდენობაა, ჯგუფის შიგნით head-of-line.

Google Pub/Sub

Ordering key უზრუნველყოფს საკვანძო წესრიგს; შეცდომებით, პუბლიკაცია იბლოკება გამოჯანმრთელებამდე - დააკვირდით backpressure- ს.

7) წესრიგის შენარჩუნებისა და აღდგენის ნიმუშები

7. 1 Sequence/ვერსია

• იღებს მოვლენას მხოლოდ იმ შემთხვევაში, თუ 'seq = last _ last _ seq + 1';
• წინააღმდეგ შემთხვევაში, ის ელოდება ბუფერში დაკარგული ('last _ seq + 1') მოსვლამდე.

pseudo if seq == last+1: apply(); last++
else if seq > last+1: buffer[seq] = ev else: skip // дубль/повтор

7. 2 ბუფერები და ფანჯრები

Time window + watermark: ჩვენ ვიღებთ out-of-order- ს ფანჯარაში, watermark- ის გასწვრივ „დახურეთ“ ფანჯარა და შეკვეთით.
Allowed lateness: გვიან არხი (recompute/ignore).

7. 3 გასაღები

Hash მარშრუტიზაცია 'hash (key)% shards' აგზავნის ყველა საკვანძო მოვლენას ერთ ვორკერზე.
Kubernetes- ში - მხარი დაუჭირეთ სხდომას/რიგის დონეზე, არა L4 დაბალანსებულ HTTP.

7. 4 Actor მოდელი/„ ერთი ნაკადი გასაღებზე “

კრიტიკული აგრეგატებისთვის (საფულე): მსახიობმა თანმიმდევრულად დაამუშავა, დანარჩენი პარალელიზმი - მსახიობთა რაოდენობა.

7. 5 Idempotence + reordering

წესრიგის აღდგენითაც კი შესაძლებელია გამეორება. აერთიანეთ UPSERT + ვერსიისა და Inbox- ის გასაღები (იხ. „Exactly-once vs At-least-once“).

8) „შხამიანი“ შეტყობინებებით მუშაობა (poison pills)

წესრიგის დაცვა აწყდება დავალებას: „როგორ ვიცხოვროთ, თუ ერთი მესიჯი არ დამუშავდება?“

მკაცრი ბრძანება: საკვანძო ნაკადის დაბლოკვა (SQS FIFO: მთელი ჯგუფი). გამოსავალი - by-key DLQ: ჩვენ მხოლოდ პრობლემურ კლავიშს/ჯგუფს გადავცემთ ცალკეულ რიგში/სახელმძღვანელო ანალიზს.
მოქნილი ბრძანება: ჩვენ ვუშვებთ პასს/ანაზღაურებას; ჩვენ ვაწარმოებთ და ვაგრძელებთ (არა ფინანსურ/კრიტიკულ ერთეულებს).
რეაგირების პოლიტიკა: შეზღუდული 'max-deliver' + backoff + avidempotent ეფექტები.

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

Cluster-linking/რეპლიკაცია (Kafka) არ იძლევა გარანტიას რეგიონალურ გლობალურ წესრიგში. მიეცით პრიორიტეტი ადგილობრივ per-key- ს წესრიგსა და idempotent sings.
მიმდევრობის (ცენტრალური ლოგის) გამოყენება სამგზავრო-გლობალური წესრიგისთვის, მაგრამ ეს გავლენას ახდენს წვდომაზე (CAP: მინუს A ქსელის ხარვეზებში).
ალტერნატივა: causal order + CRDT ზოგიერთი დომენისთვის (მრიცხველები, ნაკრები) - მკაცრი წესრიგი არ არის საჭირო.

10) წესრიგის დაკვირვება

Метрики: `out_of_order_total`, `reordered_in_window_total`, `late_events_total`, `buffer_size_current`, `blocked_keys_total`, `fifo_group_backlog`.

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

ერთი ხაზი + ბევრი კონსიუმერი, გასაღების გარეშე შარდვის გარეშე - ბრძანება მაშინვე იშლება.
ხელთათმანები პერანგის საშუალებით იმავე რიგში, იდუმალი გარეშე - ორმაგი + out-of-order.
გლობალური ბრძანება „მხოლოდ შემთხვევაში“ არის ლატენტობის აფეთქება და ღირებულება რეალური სარგებლის გარეშე.
SQS FIFO არის ერთი ჯგუფი ყველაფრისთვის - სრული head-of-line. გამოიყენეთ South GroupID გასაღები.
„ცხელი გასაღებების“ უგულებელყოფა - ერთი „საფულე“ ანელებს ყველაფერს; გააზიარეთ კლავიშები იქ, სადაც შესაძლებელია.
კრიტიკული და ცარიელი ნაკადების შერევა ერთ რიგში/ჯგუფში არის ურთიერთგამომრიცხავი გავლენა და წესრიგის დაკარგვა.

12) განხორციელების სია

• განსაზღვრულია გარანტიის დონე: per-key/per-partition/causal/global?
• შექმნილია გამარტივების გასაღები და სტრატეგია „ცხელი გასაღებების“ წინააღმდეგ.
• განლაგებულია როუტერი: განაწილება/NAC GroupID/ordering key.
• კონსიუმერები იზოლირებულია კლავიშებით (sticky-routing, shard-workers).
• idempotence და/ან Inbox/UPSERT შედის sings.
• ხორციელდება sequence/version და reordering ბუფერი (საჭიროების შემთხვევაში).
• პოლიტიკა DLQ by key და retrais backoff- ით.
• შეკვეთა და ალერტები: out-of-order, blocked _ keys, late _ events.
• თამაშის დღე: რებალანსი, კვანძის დაკარგვა, „შხამიანი“ შეტყობინება, ქსელის შეფერხება.
• დოკუმენტაცია: შეკვეთის ინვარიანტები, ფანჯრის საზღვრები, გავლენა SLA- ზე.

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

13. 1 Kafka Consumer (წესრიგის დარღვევის შემცირება)

properties max.poll.records=500 enable.auto.commit=false  # коммит после успешной обработки батча isolation.level=read_committed

13. 2 RabbitMQ (ბრძანება პარალელიზმის ფასად)

ერთი კონსიუმერი + 'basic რიგზე. qos(prefetch=1)`

bash rabbitmq-plugins enable rabbitmq_consistent_hash_exchange публикуем с хедером/ключом для консистентного хеша

13. 3 SQS FIFO

დასვით Sock GroupID = key. პარალელიზმი = ჯგუფების რაოდენობა.
DeduplaID duble დასაცავად (პროვაიდერის ფანჯარაში).

13. 4 NATS JetStream (ordered consumer, ესკიზი)

bash nats consumer add ORDERS ORD-KEY-42 --filter "orders.42.>" --deliver pull \
--ack explicit --max-deliver 6

14) FAQ

Q: მჭირდება გლობალური წესრიგი?
ა: თითქმის არასდროს. თითქმის ყოველთვის საკმარისია per-key. გლობალური წესრიგი ძვირია და ხელმისაწვდომია.

Q: რა უნდა გავაკეთოთ მკაცრი ბრძანებით „შხამიანი“ შეტყობინებით?
A: გადაიტანეთ მხოლოდ მისი გასაღები/ჯგუფი DLQ- ში, დანარჩენი გაგრძელდება.

Q: შესაძლებელია ერთდროულად წესრიგის და მასშტაბის მიღება?
A: დიახ, საკვანძო + ბრძანებას აქვს მრავალი გასაღები/წვეულება + idempotent ოპერაციები და reordering ბუფერები, სადაც საჭიროა.

Q: რა არის უფრო მნიშვნელოვანი: ბრძანება ან exactly-once?
A: დომენების უმეტესობისთვის - საკვანძო ბრძანება + ეფექტურად exactly-once ეფექტები (idempotence/UPSERT). ტრანსპორტი შეიძლება იყოს at-least-once.

15) შედეგები

ბრძანება არის ადგილობრივი გარანტია ბიზნეს გასაღების გარშემო და არა ძვირადღირებული გლობალური დისციპლინა. დაპროექტეთ გასაღებები და წვეულებები, შეზღუდეთ „ცხელი“ გასაღებები, გამოიყენეთ idempotence და, სადაც საჭიროა, sequence + buper reordering. თვალყური ადევნეთ მეტრიკებს „out-of-order“ და „blocked keys“, შეამოწმეთ წარუმატებლობები - და მიიღებთ პროგნოზირებულ მკურნალობას მსხვერპლის გარეშე პროდუქტიულობის და ხელმისაწვდომობის პირობებში.