पहचान और कुंजी

पहचान क्या है

पहचान एक ऑपरेशन की एक संपत्ति है जिसमें एक ही पहचानकर्ता के साथ दोहराना अंतिम प्रभाव को नहीं बदलता है। वितरित प्रणालियों में, यह परिणाम को "बिल्कुल एक प्रसंस्करण" के बराबर बनाने का मुख्य तरीका है, रीट्रे, डुप्लिकेट संदेश और टाइमआउट के बावजूद।

मुख्य विचार: प्रत्येक संभावित दोहराए जाने योग्य ऑपरेशन को एक कुंजी के साथ चिह्नित किया जाना चाहिए जिसके द्वारा सिस्टम पहचानता है "यह पहले ही किया जा चुका है" और परिणाम को एक से अधिक बार लागू नहीं करता है।

यह कहाँ मायने रखता है

भुगतान और शेष: 'ऑपरेशन _ आईडी' द्वारा लिखना-बंद/क्रेडिट।

आरक्षण/कोटा/सीमाएं: एक ही स्लॉट/संसाधन।

वेबहूक/सूचनाएं: बार-बार डिलीवरी को प्रभाव की नकल नहीं करनी चाहिए।

आयात/माइग्रेशन - पुनः संचालित फ़ाइलें/पैकेज.

स्ट्रीम प्रोसेसिंग: ब्रोकर/सीडीसी से डुप्लिकेट।

कुंजियों के प्रकार और उनका दायरा

1. ऑपरेशन कुंजी - व्यापार लेनदेन के विशिष्ट प्रयास की आईडी

उदाहरण: 'idempotency _ key' (HTTP), 'ऑपरेशन _ id' (RPC).

स्कोप: सेवा/कुल; एक deduplication तालिका में संग्रहीत है।

2. घटना कुंजी - घटना/संदेश का अद्वितीय पहचानकर्ता

उदाहरण: 'ईवेंट _ आईडी' (यूयूआईडी), '(producer_id, अनुक्रम)'।

क्षेत्र: उपभोक्ता/उपभोक्ता अनुमानों की रक्षा करता है।

3. व्यवसाय कुंजी - प्राकृतिक डोमेन कुंजी

उदाहरण: 'भुगतान _ id', 'invoice _ number', '(user_id, day)'।

क्षेत्र: कुल; विशिष्टता/संस्करण जांच में उपयोग किया जाता है।

टीटीएल और प्रतिधारण नीति

TTL कुंजियाँ - एक संभावित रीडो विंडो: लॉग रिटेंशन + नेटवर्क/प्रक्रिया विलंब।

महत्वपूर्ण डोमेन (भुगतान) के लिए टीटीएल - दिन/सप्ताह; टेलीमेट्री के लिए - घंटे।

पृष्ठभूमि की नौकरियों के साथ डीडअप टेबल साफ करें; ऑडिट - आर्काइव के लिए।

कुंजी भंडार (deduplication)

लेन-देन डेटाबेस (अनुशंसित): विश्वसनीय अपसर्ट/अद्वितीय इंडेक्स, प्रभाव के साथ संयुक्त लेनदेन।

केवी/रेडिस: तेज, छोटे टीटीएल के लिए सुविधाजनक, लेकिन ओएलटीपी के साथ संयुक्त लेनदेन के बिना - सावधान।

स्टेट स्टोर स्ट्रीम प्रोसेसर: ब्रोकर में स्थानीय रूप से + चेंजलॉग; फ्लिंक/केएस्ट्रीम में अच्छा।

• idempotency_keys

'consumer _ id' (или 'service'), 'op _ id' (PK на пару), 'applicated _ at', 'tl _ expires _ at', 'consumer _ hash '/' resection _ station' (опц।) .

सूचकांक: '(consumer_id, op_id)' - अद्वितीय।

बुनियादी कार्यान्वयन तकनीक

1) प्रभाव + प्रगति लेनदेन

अभिलेख परिणाम और एक लेन - देन में पठन/स्थिति प्रगति को प्राप

pseudo begin tx if not exists(select 1 from idempotency_keys where consumer=:c and op_id=:id) then
-- apply effect atomically (upsert/merge/increment)
apply_effect(...)
insert into idempotency_keys(consumer, op_id, applied_at)
values(:c,:id, now)
end if
-- record reading progress (offset/position)
upsert offsets set pos=:pos where consumer=:c commit

2) आशावादी संगति (इकाई संस्करण)

sql update account set balance = balance +:delta,
version = version + 1 where id=:account_id and version=:expected_version;
-- if 0 rows are updated → retry/conflict

3) आइडेम्पोटेंट सिंक (अपसर्ट/मर्ज)

sql insert into bonuses(user_id, op_id, amount)
values(:u,:op,:amt)
on conflict (user_id, op_id) do nothing;

प्रोटोकॉल में पहचान

HTTP/REST

'Idempotency-Key: 'शीर्षक।

सर्वर कुंजी रिकॉर्ड को संग्रहीत करता है और फिर से उसी प्रतिक्रिया को लौटाता है (या अपरिवर्तनीय विरोध के मामले में कोड '409 '/' 422')।

"असुरक्षित" POST के लिए, 'Idempotency-Key' + स्थिर टाइमआउट/रिट्रे पॉलिसी की आवश्यकता है।

gRPC/RPC

मेटाडेटा 'idempotency _ key', 'requess _ id' + डेडलाइन।

सर्वर कार्यान्वयन - जैसा कि REST में: लेनदेन में कमी की एक तालिका।

ब्रोकर्स/स्ट्रीमिंग (काफ्का/एनएटीएस/पल्सर)

निर्माता: स्थिर 'इवेंट _ आईडी '/आइडेम्पोटेंट प्रोड्यूसर (जहां समर्थित)।

उपभोक्ता: '(consumer_id, event_id)' और/या कुल के व्यावसायिक संस्करण द्वारा डीडअप करें।

गैर-अज्ञात/भ्रष्ट संदेशों के लिए डीएलक्यू अलग करें।

वेबहूक और बाहरी साझेदार

संविदा में 'Idempotency-Key '/' event _ id' की मांग; री-डिलीवरी सुरक्षित होनी चाहिए।

'सूचना _ id' संग्रहीत करें और स्थिति भेजें; रिट्रे में - डुप्लिकेट मत करो।

कुंजी डिजाइन

निर्धारणवाद: रिट्रेज़को एक ही कुंजी भेजनी चाहिए (क्लाइंट/ऑर्केस्ट्रेटर पर अग्रिम में उत्पन्न होना चाहिए

स्कोप: 'ऑप _ आईडी' को 'सेवा: कुल: आईडी: उद्देश्य' के रूप में बनाएं।

टकराव: व्यावसायिक मापदंडों से - या हैश का उपयोग करें (यदि आवश्यक हो तो नमक के साथ)।

पदानुक्रम: मोर्चे पर सामान्य 'ऑपरेशन _ आईडी' का सभी सबऑपरेशन (पहचान श्रृंखला) में अनुवाद किया जाता है।

UX और उत्पाद पहलू

एक बार-बार कुंजी अनुरोध को एक ही परिणाम (शरीर/स्थिति सहित) या एक स्पष्ट "पहले से ही निष्पादित" वापस करना चाहिए।

उपयोगकर्ता को स्टेटस दिखाएं "ऑपरेशन को संसाधित/पूरा किया जा रहा है" बजाय "गुड लक के लिए फिर से कोशिश करने के।"

लंबे संचालन के लिए - कुंजी द्वारा मतदान ('GET/offices/{ op _ id}')।

अवलोकन क्षमता

Log 'op _ id', 'event _ id', 'trace _ id', परिणाम: 'APPLED '/' ALSLAST _ APPLED'.

मेट्रिक्स: पुनरावृत्ति दर, डीडअप टेबल आकार, लेनदेन समय, संस्करण संघर्ष, डीएलक्यू दर।

ट्रेस: कुंजी को कमांड → इवेंट → प्रोजेक्शन → बाहरी कॉल से गुजरना होगा।

सुरक्षा और अनुपालन

पीआईआई को कुंजियों में संग्रहीत न करें; कुंजी पहचानकर्ता, पेलोड नहीं।

लंबे टीटीएल के साथ डीडुप्लिकेशन रिकॉर्ड में संवेदनशील क्षेत्र गोपित करें।

प्रतिधारण नीति: टीटीएल और अभिलेखागार; भूल जाने का अधिकार - प्रतिक्रियाओं/मेटाडेटा के क्रिप्टो-क्षरण के माध्यम से (यदि उनमें पीआईआई है)।

परीक्षण

1. डुप्लिकेट: एक संदेश चलाएं/2-5 बार अनुरोध करें - प्रभाव बिल्कुल एक।

2. ऑफसेट को ठीक करने से पहले/बाद में प्रभाव रिकॉर्ड करने से पहले/बाद के चरणों के बीच छोड़ें।

3. उपभोक्ता पुनः आरंभ/पुनर्संतुलन: कोई दोहरी उपयोग नहीं।

4. प्रतियोगिता: एक 'op _ id' → एक प्रभाव के साथ समानांतर प्रश्न, दूसरा - 'ALGRENT _ APPLIED/409'।

5. लंबे समय तक रहने वाली कुंजियाँ: वसूली के बाद टीटीएल समाप्ति और पुनर्प्राप्ति के लिए जाँच।

एंटी-पैटर्न

प्रत्येक पुनरावृत्ति के लिए यादृच्छिक नई कुंजी: तंत्र रीप्ले को पहचानता नहीं है।

दो अलग-अलग प्रतिबद्धता: पहले प्रभाव, फिर ऑफसेट - उनके बीच की गिरावट प्रभाव की नकल करती है।

केवल दलाल पर भरोसा करना: चोट/कुल में कोई कमी नहीं।

गुम कुल संस्करण: बार-बार घटना बदलती है दूसरी बार।

वसा कुंजी: कुंजी में व्यावसायिक क्षेत्र/पीआईआई → लीक और जटिल सूचकांक शामिल हैं।

कोई दोहराने योग्य प्रतिक्रिया नहीं: क्लाइंट सुरक्षित रूप से पीछे नहीं हट सकता

उदाहरण

भुगतान पोस्ट

ग्राहक: 'POST/भुगतान' + 'Idempotency-Key: k-789'।

सर्वर: ट्रांजेक्शन - 'पेमेंट' बनाता है और 'idempotency _ keys' में एक प्रविष्टि बनाता है।

Redo: एक ही '201 '/बॉडी लौटाता है; अपरिवर्तनीय संघर्ष के मामले में - '409'।

बोनस अर्क (सिंक)

sql insert into credits(user_id, op_id, amount, created_at)
values(:u,:op,:amt, now)
on conflict (user_id, op_id) do nothing;

घटनाओं से प्रक्षेपण

उपभोक्ता स्टोर 'देखा (event_id)' और 'संस्करण' इकाई; दोहराएँ - अनदेखा/idempotent अपसर्ट।

पढ़ ने की प्रगति को प्रक्षेपण अद्यतन के समान लेनदेन में कैप्चर किया जाता है।

उत्पादन जाँच सूची

• सभी असुरक्षित संचालन में एक अज्ञात कुंजी और इसके दायरे को परिभाषित किया गया है।
• टीटीएल और अद्वितीय सूचकांक के साथ डीडुप्लिकेशन टेबल हैं।
• पढ़ ने का प्रभाव और प्रगति परमाणु रूप से प्रतिबद्ध है।
• आशावादी प्रतियोगिता (संस्करण/अनुक्रम) लेखन मॉडल में शामिल है।
• एपीआई अनुबंध 'आइडेम्पोटेंसी-की '/' ऑपरेशन _ आईडी' और पुनरावृत्ति व्यवहार पर कब्जा करते हैं।
• मेट्रिक्स और लॉग में 'op _ id '/' event _ id '/' trace _ id' शामिल हैं।
• CI में डुप्लिकेट, फॉल और रेस के लिए टेस्ट।
• टीटीएल/पुरालेख नीति और पीआईआई सुरक्षा का पालन किया जाता है।

FAQ

'अनुरोध-आईडी' से 'Idempotency-Key' different कैसे है?

'अनुरोध-आईडी' - ट्रेस; इसे रिट्रेज़पर बदला जा सकता है। 'आइडेम्पोटेंसी-की' ऑपरेशन का शब्दार्थ पहचानकर्ता है, जिसे दोहराव के दौरान समान होना आवश्यक है।

क्या डेटाबेस के बिना पहचान करना संभव है?

एक छोटी खिड़की के लिए - हाँ (रेडिस/इन-प्रोसेस कैश), लेकिन संयुक्त लेनदेन के बिना, डुप्लिकेट का जोखिम बढ़ जाता है। महत्वपूर्ण डोमेन में, यह एक डेटाबेस लेनदेन में बेहतर है।

बाहरी भागीदारों के साथ क्या करें?

कुंजी और दोहराने योग्य प्रतिक्रियाओं पर बातचीत करें। यदि साथी समर्थन नहीं करता है - कॉल को अपनी पहचान परत में लपेटें और "पहले से ही लागू" स्टोर करें।

टीटीएल कैसे चुनें?

अधिकतम देरी का योग: लॉग रिटेंशन + नेट/रिबेलेंस सबसे खराब केस + बफर। स्टॉक (× 2) जोड़ें।

कुल

पहचान कुंजी, लेनदेन और संस्करणों का एक अनुशासन है। स्थिर संचालन पहचानकर्ता + प्रभाव का परमाणु निर्धारण और पढ़ ने की प्रगति + अज्ञात सिंक/अनुमान परिवहन-स्तर के जादू के बिना "बिल्कुल एक प्रभाव" देते हैं। कुंजी नियतात्मक, टीटीएल यथार्थवादी बनाएं और दुर्भावनापूर्ण परीक्षण करें। फिर रिट्रेज़और डुप्लिकेट नियमित हो जाएंगे, घटनाएं नहीं।