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

1) რატომ არის ეს აუცილებელი?

1. რეპლიკა უსაფრთხოა (idempotenten),

2. გამეორებებს შორის ნაწყვეტები,

3. პატივს სცემენ შეზღუდვები/კვოტები და დამოკიდებულების „ჯანმრთელობა“.

მიზანია საქმიანი ოპერაციების დონეზე ეფექტური - ერთი ქცევა ყალბი დუბლების და რბოლების გარეშე.

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

At-most-once: გამეორების გარეშე, ზარალის რისკი (ლოგიკაცია, fire-and-forget).
At-least-once: დუბლიკატები შესაძლებელია - საჭიროა მომხმარებლის იდემპოტენტურობა (რიგების უმეტესობა, ვებჰუკი).
Effectively-once: დუბლიკატები შესაძლებელია, მაგრამ სწორად ხდება დედუპლიცირება (გასაღებები, გარიგებები, გარიგებები).

3) როდის და როდის

აზრი აქვს გადაკეთებას: '408', '429' (დააკვირდით 'Retry-After'), '425' (Too Early), '499' (პერიმეტრზე წებოვანი), '5xx', '504', ქსელის ტაიმაუტები/შესვენებები, '502' კარიბჭე, „reset.“

მოთხოვნის შეცვლის გარეშე: '400/401/403/404/422'.
საკამათო შემთხვევები: '409 Conflict' (ჩვეულებრივ, არა; ჯერ წაიკითხეთ ოპერაციის სტატუსი/დაადასტურა განზრახვა).

4) ტაიმაუტები, ბუკოფი და ჯიტერი

4. 1 წესები

ჯერ ტაიმუთი, შემდეგ რეტრიუმი: თითოეულ თხოვნას უნდა ჰქონდეს „deadline“.
Exponential backoff: 'delay _ n = base 2 ^ n', შემოიფარგლება 'max _ delay'.
Jitter სავალდებულოა: დაამატეთ უბედური შემთხვევა „ბლაგვი სინქრონული ტალღების“ დენოტირებისთვის.

4. 2 ჯიტერის შაბლონები

Full jitter: 'sileep = rand (0, base2 ^ n)' საუკეთესო საერთო არჩევანია.
Decorrelated jitter: 'sleep = min (max _ delay, rand (ბაზა, ძილი _ prev3))' - გრძელი დიალოგებისთვის.
Equal jitter: 'sileep = base2 ^ n/2 + rand (0, base2 ^ n/2)' - რბილი ცვალებადობა.

4. 3 Retry-budget

• `retry_budget_per_min = max(α success_rps, floor β)`; ჩვეულებრივ, n = 0. 1–0. 2`.
• ბიუჯეტის ამოწურვისას - ჩვენ გადავდივართ fail-fast/circuit Open breaker- ზე.

5) ურთიერთქმედება rate limiting და Circuit Breaker

პატივს სცემთ 'Retry-After', 'RateLimit-Reset' და განიხილეთ იგი სარეზერვო ოფისში.
მაღალი „5xh “/Taimauts - შეამცირეთ რელიეფის სიხშირე და ზოგადი პარალელიზმი.

• Half-Open: საშუალებას აძლევს შეზღუდულ ნიმუშს.
• ღია: მყისიერად უარყოფს (დაზოგავს რესურსს).
• Closed: ჩვეულებრივი სამუშაო.
• Write ოპერაციებზე სასურველია 409/503 დაბრუნება მკაფიო თხოვნით, ვიდრე აგრესიული რეაგირების გადახრა.

6) write ოპერაციების idempotence

6. 1 ზოგადი იდეა

იგივე განზრახვები - ერთი შედეგი. საფუძველი არის იდემპოტენტურობის გასაღები და შესრულების ჩანაწერების შენახვა.

6. 2 HTTP კონტრაქტი

Idempotency-Key: 7a6b7f9e-2a46-4d0b-9c3a-2b30e1c3c9e3
Idempotency-Key-Expiry: 24h # optional

• პირველი წარმატებული შესრულებით ის ინარჩუნებს (გასაღები არის შედეგი, სტატუსი, სხეულის ჰაში);
• გამეორებისას, იგი უბრუნდება წინა პასუხს და სათაურს 'idempotency-Replay: true';
• სხეულის კონფლიქტის დროს (იგივე გასაღები, მაგრამ სხვა payload) - '409 Conflict'.

6. 3 საცავი და TTL

ცხრილი/გასაღები მნიშვნელობა: 'idempotency _ key', 'request _ hash', 'result', 'status', 'expiry _ at'.
TTL = შესაძლო გამეორებისა და გვიან მიწოდების ფანჯარა (ჩვეულებრივ, 24-72 საათი გადახდისთვის).
Idempotence _ key ინდექსები; მაღალი დატვირთვისთვის - ჰაშის შარდვა.

6. 4 სქემის მაგალითი (SQL)

sql
CREATE TABLE idempo_store (
key UUID PRIMARY KEY,
req_hash BYTEA NOT NULL,
status INT NOT NULL,
response JSONB NOT NULL,
created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
expiry_at TIMESTAMPTZ NOT NULL
);

6. 5 დამუშავების ფსევდო კოდი

pseudo handle_write(req):
k = req. headers["Idempotency-Key"]
h = hash(req. body)
rec = idempo_store. get(k)

if rec and rec. req_hash == h:
return rec. status, rec. response, {"Idempotency-Replay": "true"}

if rec and rec. req_hash!= h:
return 409, problem("IDEMPOTENT_CONFLICT")

begin tx result = apply_business_mutation (req) # change status upsert once (idempo_store, key = k, req_hash=h, status = 201, response = result, expiry = now () + 2d)
commit

return 201, result

7) effectively-once ნიმუშები

Transactional Outbox: ბიზნეს ღონისძიების ჩაწერა და შეტყობინებების გაგზავნა იმავე BD გარიგებიდან ფონის რელიეფის საშუალებით; მომხმარებელი იდემპოტენტურია.
Inbox/Processed-table მომხმარებელი: შეინარჩუნეთ 'event _ id' დუბლების უგულებელყოფის მიზნით.
Exactly-once Kafka - exactly-once ბიზნესში: თუნდაც მწარმოებლის/კონსუტერის EOS- ით, გამოყენებითი ლოგიკა მაინც უნდა იყოს idempotent.
კომპენსაციის გარიგებები (საგა): თუ ნაბიჯები იშლება და იწვევს გვერდითი მოვლენებს, ჩვენ სისტემას ვუბრუნებთ ინვარიანტს.

8) პირადი შემთხვევები: გადახდები და ფინანსური ოპერაციები

Strong idempotence: გასაღები უკავშირდება ოპერაციის ლოგიკას (მაგალითად, „external _ payment _ id“).
პედოპლიკაცია PSP- ზე: შეინახეთ 'merchant _ reference' - ის განმეორებისას PSP დაუბრუნებს თავის წინა შედეგს.
Retrai „კლიენტისგან“: დაუშვას მხოლოდ „Idempotency-Key“ - ით, წინააღმდეგ შემთხვევაში ორმაგი ჩამოწერის რისკი.
კონკურენცია: დაბლოკვა „ანგარიშზე/ინსტრუმენტზე/ხელშეკრულებაზე“ შესრულების ხანგრძლივობისთვის; გამეორებისას დაბრუნდით 409/423.
დაკვირვება: მეტრიკა 'idempo _ replay _ total', 'idempo _ conflict _ total'.

9) ვებჰუკი და გარე ზარები

HMAC ხელმოწერები და დროის ფანჯარა; ჯერ შემოწმება, შემდეგ დამუშავება.
გამგზავნის რეტრაები: ექსპონენციალური backoff + jitter, 'max _ attempts' და DLQ.
მომხმარებელი - idempotent: 'event _ id' ცხრილი/in-memory cache; „სისუფთავე“ ბრძანება გარანტირებული არ არის.
კოდები: 2xx = წარმატებით, 4xx = არ გაიმეოროთ, 5xx/tymaut = განმეორება.

10) რიგები და ფონის დავალებები

At-least-once ნაგულისხმევი დუბლიკატები გარდაუვალია.
შეინახეთ 'task _ id '/' event _ id' და შესრულების სტატუსი; დუბლით - მოკლე გზა „replay“.
DLQ და poison-messages: მცდელობის მრიცხველი, კარანტინი, სახელმძღვანელო ანალიზი.
კონკურენტული ლიმიტები (სემფორები) და იდემპოტენტური ვორკერები.

11) ვერსია და „ბუნებრივი“ გასაღებები

ბუნებრივი გასაღებები (ანგარიშის ნომერი + დოკუმენტის თარიღი + ნომერი) ზრდის გამეორების წინააღმდეგობას.
სქემის/ვერსიის შეცვლისას ჩართეთ ვერსიის გასაღები 'Idempotency-Key "- ში ან მოთხოვნის ჰეშში.

12) HTTP სათაურები და მომხმარებლისთვის მინიშნებები

'Idempotence-Key', 'Idempotency-Replay', 'Retry-After', 'Prefer: wait = <sec> "(გრძელი ოპერაციებით),' If-Match '/' ETag '(ოპტიმისტური ბლოკი).
409 საკვანძო კონფლიქტში, 425/429/503 მოქმედი 'Retry-After- ით ".
„გრძელი“ ოპერაციებისთვის - ასინქრონული სტატუსის მიღება ('202 Accepted' + 'Location' სტატუსი).

13) ტესტირება და ქაოსის სცენარები

ნეგატიური ტესტები: ორმაგი გაგზავნა, გამეორება სხვა სხეულით, საათის რასინქრონი.
შეკვეთის დარღვევა: 't2' მოდის ადრე 't1'.
ტაიმაუტის ინექცია/' RST '/' EOF ", ნახევრად მოთხოვნილებები (slow-POST).
დაცემული idempotence საცავი არის fail-closed ქცევა (უკეთესია უარი თქვას ორმაგ ჩამოწერაზე).

14) მეტრიკი და ალერტა

`retries_total{reason}`, `retry_budget_used{route}`, `backoff_seconds_bucket`.
`idempo_replay_total`, `idempo_conflict_total`, `duplicate_detected_total`.
წილი 409/425/429/5xx მარშრუტებზე; p95/p99 „წარმატების დრო“ თხრილებით.
ალერტები: ჭიდაობის ბიუჯეტის საბურღი, იდემპოტენტობის კონფლიქტების ზრდა, DLQ- ის ზრდა.

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

ზედიზედ ყველა შეცდომის გადახედვა.
ჯიტერის არარსებობა - რეტრაელთა სინქრონული ტალღები.
გრძელი გასაღებები TTL და გაწმენდის გარეშე.
შედეგის შენარჩუნება კომიტის შემდეგ გვერდითი ეფექტი (გარედან დარღვევა).
Logs 'trace _ id '/' idempotency _ key' შეუძლებელია წინსვლა.
აგრესიული პარალელური გამოსვლები write ოპერაციებზე.

16) მზადყოფნის სიის სია

• ერთიანი პოლიტიკა: რა ვჭამოთ, რა არა; კოდები და მინიშნებები კლიენტისთვის.
• ექსპონენციალური backoff + full jitter; მითითებულია 'retry _ budget'.
• Idempotency-Key '+ კონტრაქტი TTL- სთან ერთად.
• Outbox/Inbox მოვლენებისთვის; DLQ; კონკურენციის ლიმიტები.
• ინტეგრაცია circuit breaker- თან, respect 'Retry-After- თან ".
• მეტრიკა/ალერტები რეტრატებზე/დუბლიკატებზე/კონფლიქტებზე.
• ქაოსის ტესტების ნაკრები და ქსელის წარუმატებლობის ემულაცია.
• დოკუმენტაცია მომხმარებლებისთვის: სარეზერვო ოფისების და სტატუსის მაგალითები.

17) TL; DR

Retrai სასარგებლოა მხოლოდ idempotence- ით. შეიყვანეთ 'Idempotency-Key' და შედეგების საცავი, გამოიყენეთ ექსპონენტური backoff ერთად ჯიტერი და retry-budget, პატივი მიაგეთ 'Retry-After ", ინტეგრირება მოახდინეთ circuit breaker- თან. მოვლენებისთვის - outbox/inbox; გადახდებისთვის - მკაცრი დედაპლატაცია და დაბლოკვა. გაზომეთ რეტრაები და კონფლიქტები, შეამოწმეთ დუბლიკატები და ტაიმაუტები.