Exactly-once vs At-least-once

1) რატომ უნდა განვიხილოთ სემანტიკა

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

მთავარი ჭეშმარიტება: განაწილებულ სამყაროში გლობალური გარიგებების გარეშე და სინქრონული კოორდინაციის გარეშე, „სუფთა“ end-end exactly-once მიუწვდომელია. ჩვენ ვაშენებთ ეფექტურად exactly-once- ს: ჩვენ ვუშვებთ გამეორებას ტრანსპორტში, მაგრამ ვიმუშავებთ idempotent- ს ისე, რომ დაკვირვებული ეფექტი „თითქოს ერთხელ“ იყოს.

2) უარის თქმის მოდელი და სად წარმოიქმნება დუბლიკატები

• Ack/commit- ის დანაკარგები (პროდიუსერმა/ბროკერმა/კონსიუმერმა „არ მოისმინა“ დადასტურება).
• ლიდერების/რეპლიკების ხელახალი არჩევა, ქსელის შესვენებების აღდგენა.
• Taimautov/retraiv ნებისმიერ საიტზე (კლიენტი - ბროკერი - კონსიუმერი).

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

3) Exactly-once მიმწოდებლებში და რა არის სინამდვილეში

3. 1 Kafka

• Idempotent Producer (`enable. idempotence = true ') - ხელს უშლის მწარმოებლის მხარეს დუბლებს.
• გარიგებები - ატომურად აქვეყნებს შეტყობინებებს რამდენიმე ჯგუფში და აკონტროლებს სამომხმარებლო ოფსეტებს (ნიმუშის გადამუშავება „გადასასვლელების“ გარეშე).
• Compaction - ინახავს ბოლო მნიშვნელობას გასაღებით.

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

3. 2 NATS / Rabbit / SQS

სტანდარტულად - at-least-once ack/redelivery. Exactly-once მიიღწევა განაცხადის დონეზე: გასაღებები, დედაპლატა, upsert.

დასკვნა: Exactly-once ტრანსპორტი - exactly-once ეფექტი. ეს უკანასკნელი კეთდება დამუშავებაში.

4) როგორ ავაშენოთ ეფექტურად exactly-once ast-least-once

4. 1 Idempotent გასაღები (idempotency key)

• ამოწმებს „უკვე?“ - dedup store (Redis/BD) ერთად TTL/retenshon.
• თუ დავინახე, ის იმეორებს ადრე გამოთვლილ შედეგს ან აკეთებს no-op.

lua
-- SET key if not exists; expires in 24h local ok = redis.call("SET", KEYS[1], ARGV[1], "NX", "EX", 86400)
if ok then return "PROCESS" else return "SKIP" end

4. 2 Upsert ბაზაში (idempotent silk)

ჩანაწერები გაკეთებულია UPSERT/ON CONFLICT- ის საშუალებით, ვერსიის/თანხის გადამოწმებით.

sql
INSERT INTO payments(id, status, amount, updated_at)
VALUES ($1, $2, $3, now())
ON CONFLICT (id) DO UPDATE
SET status = EXCLUDED.status,
updated_at = now()
WHERE payments.status <> EXCLUDED.status;

4. 3 გარიგების Outbox/Inbox

Outbox: ბიზნეს გარიგება და ჩაწერა „გამოქვეყნების მოვლენები“ ხდება ერთ მონაცემთა ბაზაში. ფონის გამომცემელი კითხულობს outbox- ს და აგზავნის ბროკერს - არ არსებობს განსხვავებები მდგომარეობასა და მოვლენას შორის.
Inbox: შემომავალი გუნდებისთვის, ჩვენ შევინარჩუნებთ „მესიჯს _ id“ და შედეგს შესრულებამდე; განმეორებითი დამუშავება ხედავს ჩანაწერს და არ იმეორებს გვერდითი მოვლენებს.

4. 4 ჯაჭვის თანმიმდევრული დამუშავება

კაფკა: გარიგებამ "წაიკითხა ოფსეტი და ჩაწერა" კომუნის "შედეგები ერთ ბირთვულ ბლოკში.
გარიგების გარეშე: „ჯერ ჩაწერე შედეგი/Inbox, შემდეგ ack“; როდესაც კრეში, დუბლიკატი დაინახავს Inbox- ს და დასრულდება no-op.

4. 5 SAGA/კომპენსაცია

როდესაც idempotention შეუძლებელია (გარე პროვაიდერმა ჩამოწერა ფული), ჩვენ ვიყენებთ კომპენსაციურ ოპერაციებს (refund/void) და idempotent გარე API (იგივე 'POST' - ით იგივე შედეგს იძლევა).

5) როდესაც საკმარისია

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

წესი: თუ დუბლი არ ცვლის ბიზნეს მნიშვნელობას ან ადვილად ვიპოვით მას, როგორც at-last-once + ნაწილობრივი დაცვა.

6) პროდუქტიულობა და ღირებულება

Exactly-once (თუნდაც „ეფექტური“) უფრო ძვირია: დამატება (Inbox/Outbox), გასაღებების შენახვა, გარიგება, უფრო რთული დიაგნოზი.
At-least-once იაფია/მარტივი, უკეთესია throughput/p99.
შეაფასეთ: დუბლის ფასი × დუბლის ალბათობა დაცვის ღირებულება.

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

7. 1 კაფკას პროდიუსერი (იდემპოტენტობა + გარიგება)

properties enable.idempotence=true acks=all retries=INT_MAX max.in.flight.requests.per.connection=5 transactional.id=orders-writer-1

java producer.initTransactions();
producer.beginTransaction();
producer.send(recordA);
producer.send(recordB);
// также можно atomically commit consumer offsets producer.commitTransaction();

7. 2 კონსიუმერი Inbox- ით (ფსევდო კოდი)

pseudo if (inbox.exists(msg.id)) return inbox.result(msg.id)
begin tx if!inbox.insert(msg.id) then return inbox.result(msg.id)
result = handle(msg)
sink.upsert(result)     # идемпотентный синк inbox.set_result(msg.id, result)
commit ack(msg)

7. 3 HTTP idempotency-Key (გარე API)

POST /payments
Idempotency-Key: 7f1c-42-...
Body: { "payment_id": "p-123", "amount": 10.00 }

განმეორებითი POST იგივე გასაღებით არის იგივე შედეგი/სტატუსი.

8) დაკვირვება და მეტრიკა

'duplicate _ attempts _ total' - რამდენჯერ დაიჭირეს დუბლი (Inbox/Redis- ის მიხედვით).
„idempotence _ hit _ rate“ არის გამეორებების წილი, რომელიც „გადარჩა“ იდემპოტენტურობით.
'txn _ abort _ rate' (Kafka/BD) - გამოტოვების წილი.
'outbox _ backlog' - პუბლიკაციის ჩამორჩენა.
'exactly _ once _ once _ path _ latency {p95, p99}' vs 'at _ least _ once _ path _ latency' - ზედმეტი ხარჯები.
ლოგოების აუდიტი: კავშირი 'მესიჯი _ id', 'idempotency _ key', 'saga _ id', 'attempt'.

9) Playbooks (Game Days)

გაგზავნის განმეორება: პროდიუსერის რეკრეაცია ხელოვნურ ტაიმაუტებში.
Crash Shink and Ack- ს შორის: დარწმუნდით, რომ Inbox/Upsert ხელს უშლის დუბლს.
პერეს მიწოდება: ბროკერში გაუმჯობესება; შეამოწმეთ დედაპლატი.
გარე API idempotence: განმეორებითი POST იგივე გასაღებით - იგივე პასუხი.
ლიდერის შეცვლა/ქსელის რღვევა: შეამოწმეთ Kafka გარიგებები/კონსიუმერების ქცევა.

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

დაეყრდნობით ტრანსპორტს: „ჩვენ გვაქვს კაფკა ექსაქტიური-once, ასე რომ შეგიძლიათ კლავიშების გარეშე“ - არა.
ჩანაწერამდე არა-op ack: acknuli, მაგრამ silk დაეცა ზარალი.
DLQ/rettray- ის არარსებობა ჯიტერთან: გაუთავებელი გამეორება და ქარიშხალი.
შემთხვევითი UUID ბუნებრივი კლავიშების ნაცვლად: დუპლიცირების არაფერი აქვს.
Inbox/Outbox- ის შერევა პროდ ცხრილების გარეშე ინდექსების გარეშე: ცხელი ბლოკირება და p99 კუდი.
ბიზნეს ოპერაციები იდემპოტენტური API- ს გარეშე გარე პროვაიდერებში.

11) შერჩევის სია

1. დუბლის ფასი (ფული/იურიდი/UX) vs დაცვის ფასი (ლატენტობა/სირთულე/ღირებულება).
2. არსებობს თუ არა მოვლენის/ოპერაციის ბუნებრივი გასაღები? თუ არა, მოდით სტაბილური.
3. სინკი მხარს უჭერს Upsert/ვერსიას? წინააღმდეგ შემთხვევაში - Inbox + ანაზღაურება.
4. საჭიროა გლობალური გარიგებები? თუ არა, სეგმენტი SAGA- ზე.
5. საჭიროა raplay/გრძელი retenshne? Kafka + Outbox. გჭირდებათ სწრაფი RPC/დაბალი შეფერხება? NATS + Idempotency-Key.
6. მრავალ ტენანტობა და კვოტები: გასაღების/სივრცის იზოლაცია.
7. დაკვირვება: ჩართულია მეტრიკა idempotency და backlog.

12) FAQ

Q: შესაძლებელია თუ არა „მათემატიკური“ exactly-once-end-end მიღწევა?
A: მხოლოდ ვიწრო სცენარებში ერთი თანმიმდევრული საცავით და გარიგებებით მთელ გზაზე. ზოგადად, არა; გამოიყენეთ ეფექტურად exactly-once idempotence.

Q: რა არის უფრო სწრაფი?
A: At-least-once. Exactly-once ემატება კლავიშების გარიგებებს/შენახვას p99-ზე მეტი და ღირებულება.

Q: სად უნდა შეინახოთ იდემპოტენტურობის გასაღებები?
A: სწრაფი ნაკადი (Redis) TTL- ით, ან Inbox ცხრილი (PK = მესიჯი _ id). გადახდებისთვის - უფრო გრძელი (დღეები/კვირა).

Q: როგორ ავირჩიოთ TTL დედაპლატის გასაღებები?
A: მინიმალური = მაქსიმალური მიწოდების დრო + ოპერაციული რეზერვი (ჩვეულებრივ 24-72 საათი). ფინანსებისთვის - მეტი.

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

13) შედეგები

At-least-once არის ძირითადი, საიმედო ტრანსპორტის სემანტიკა.
Exactly-once, როგორც ბიზნეს ეფექტი მიიღწევა დამუშავების დონეზე: Idempotency-Key, Inbox/Outbox, Upsert/ვერსიები, SAGA/კომპენსაცია.
არჩევანი არის კომპრომისი დუბლის ღირებულება - რისკი და ექსპლუატაციის სიმარტივე. დაპროგრამეთ ბუნებრივი გასაღებები, გააკეთეთ collection idempotent, დაამატეთ დაკვირვება და რეგულარულად ჩაატარეთ თამაშის დღეები - შემდეგ თქვენი payplines პროგნოზირებადი და უსაფრთხო იქნება თუნდაც ქარიშხლისა და წარუმატებლობის დროს.