प्रौद्योगिकी और अवसंरचना - कैश स्तर और डेटा भंडारण

कैश स्तरीय और डेटा भंडारण

1) आपको मल्टी-लेयर कैश की आवश्यकता क्यों है

कैश "महंगे" सबसिस्टम (डेटाबेस, बाहरी एपीआई, नेटवर्क) पर जाने के बिना एक उत्तर का एक छोटा रास्ता है। लेयरिंग लोड वितरित करता है: ब्राउज़र → सीडीएन/एज → एप्लिकेशन लेयर → वितरित कैश → डेटाबेस/स्टोरेज। लक्ष्य: P95/P99 कम करें, अनलोड मूल, अधिक मजबूती से चोटियों का सामना करें और बाइट्स की लागत को कम करें।

2) कैश लेवल मैप

1. Браузер: 'कैश-कंट्रोल', 'ईटीएजी', 'लास्ट-मॉडिफाइड', 'स्टेल-जबकि-रिवाइवल'।

2. सीडीएन/एज: TTL/ключ, वैरी, साइन यूआरएल, इमेज-रीसाइज़; tiered/ढाल।

3. एपीआई गेटवे/सर्विस मेश: सुरक्षित GET के लिए अल्पकालिक प्रतिक्रिया कैश।

4. अनुप्रयोग (इन-प्रक्रिया): LRU/LFU, गर्म कुंजी, मिलीसेकंड के लिए पास-कैश।

5. वितरित कैश (Redis/Memcatched): गतिशीलता के लिए मुख्य परत।

6. डीबी कैश: Pg/Innodb बफर्स, Pgbouncer मल्टीप्लेक्सिंग, भौतिक दृश्य।

7. डिस्क/ऑब्जेक्ट स्टोर: पूर्वनिर्मित स्नैपशॉट, ब्लब कैश (उदाहरण के लिए, S3 + CDN)।

सिद्धांत: "उपयोगकर्ता के करीब, टीटीएल और कम निजीकरण; डेटा के करीब, स्थिरता नीति को समृद्ध करता है।"

3) कैश पैटर्न

कैश-अलग (आलसी): हम पढ़ ते हैं - MISS के साथ हम स्रोत से लोड करते हैं - इसे कैश में रखें। सरल, टीटीएल नियंत्रण देता है।

रीड-थ्रू: एप्लिकेशन एक कैश के माध्यम से पढ़ ता है जो स्रोत से ही खींचता है। नीति को केंद्रीकृत करना सुविधाजनक है।

राइट-थ्रू: रिकॉर्डिंग कैश और स्रोत पर तुरंत जाती है। अधिक सुसंगत, लेकिन रिकॉर्ड पर अधिक महंगा।

राइट-बैक (राइट-बिहाइंड): हम कैश को लिखते हैं, स्रोत को अतुल्यकालिक रूप से अपडेट किया जाता है (कतार)। उच्च गति, शिपिंग गारंटी और पहचान की आवश्यकता।

ताज़ा-आगे: "शीर्ष" कुंजियों के लिए, टीटीएल समाप्त होने से पहले मूल्य को अद्यतन करें।

कहां: गेम कार्ड/निर्देशिका - कैश-एक तरफ/रीड-थ्रू; काउंटर/लीडरबोर्ड - राइट-बैक + सीआरडीटी/एकत्रीकरण; मुद्रा/सीमा निर्देशिका - नियंत्रित टीटीएल के साथ पढ़ ने के माध्यम से।

4) कुंजियाँ, विभाजन और नामकरण

Шаблон: : 'डोमेन: इकाई: {id}: v{schema}|region={R}|currency={C}|lang={L}'।

केवल कुंजी में शामिल करें जो वास्तव में उत्तर (क्षेत्र, मुद्रा, भाषा, स्कीमा संस्करण) बदलता है।

स्कीमा वर्शनिंग: असंगत परिवर्तनों के लिए - द्रव्यमान पर्स से बचते हुए, कुंजी में 'वीएन' उठाएं।

उत्पाद/किरायेदार द्वारा नामस्थान: 'किरायेदार: {t}:...' - बहु-किरायेदार के लिए महत्वपूर्

"प्रमुख अस्तित्व" के लिए ब्लूम फिल्टर स्रोत की यात्राओं को कम कर सकता है।

5) टीटीएल, ताजगी और विकलांगता

• स्थैतिक (हैशेड फ़ाइलें): 30-365 दिन + 'अपरिवर्तनीय';
• कैटलॉग/बैनर: 5-60 मिनट + 'बासी-जबकि-पुनर्नवीनीकरण';
• लीडबोर्ड/उद्धरण: 2-15 सेकंड;
• निर्देशिका (मुद्राएं/सीमाएँ): 1-10 मिनट।
• विकलांगता घटनाएँ: 'उत्पाद प्रकाशित करें। अद्यतन '→ dot कुंजी/उपसर्ग विकलांगता।
• टैग-आधारित पर्स: टैग द्वारा समूह पर्स (प्रोमो/कैटलॉग रिलीज)।
• सॉफ्ट-एक्सपायरी: टीटीएल की समाप्ति के बाद, हम पुराने को 'बासी' के रूप में देते हैं, इसे समानांतर (एसडब्ल्यूआर/एसआईई) में अपडेट करते हैं।
• Versioned Keys> द्रव्यमान पर्स: सस्ता और सुरक्षित।

6) भगदड़, गर्म चाबियाँ और प्रतियोगिता

• सिंगल-फ्लाइट (कोलसिंग का अनुरोध करें): एक नेता कुंजी को अपडेट करता है, बाकी इंतजार करते हैं।
• टीटीएल जिटर: एक बार के पतन से बचते हुए, बहिर्वाह को धुंधला कर दें।
• SWR स्थानीय रूप से: हम उपयोगकर्ता को समाप्त मूल्य देते हैं, इसे पृष्ठभूमि में अद्यतन करते हैं।

• कई 'कुंजी # 1' के लिए गर्म कुंजी प्रतिकृति। एन 'स्लॉट पढ़ कर वितरित
• प्रक्रिया स्मृति में निकट-कैश;
• पिक्स (टूर्नामेंट/मैच) से पहले प्रीवर्म/रिफ्रेश-फॉरवर्ड।
• भारी कुंजी के लिए संगति अद्यतन पर सीमा।

7) स्थिरता और क्रॉस-परतें

लिखें-अमान्य: जब स्रोत पर लिखा जाता है - तुल्यकालिक रूप से संबंधित कुंजी (पब/सब) अक्षम करें।

पढ़ें-मरम्मत: विसंगतियों के मामले में, सही मूल्य के साथ कैश को अपडेट करें।

अंतिम बनाम मजबूत: महत्वपूर्ण नकदी लेनदेन सीधे/छोटे टीटीएल के साथ पढ़े जाते हैं; यूआई शोकेस और आंकड़े - अंतिम।

सीआरडीटी/एग्रीगेटर्स: वितरित काउंटरों/रेटिंग के लिए - "मर्ज-सेफ" संरचनाओं (जी-काउंटर, स्ट्रीम पर टॉप-के)।

कैस्केडिंग विकलांगता: "गेम" अपडेट करना कार्ड + सूची + कस्टम सिफारिश कैश अक्षम करता है।

8) क्रमबद्धता, संपीड़न और प्रारूप

प्रारूप: JSON की तुलना में प्रोटोबफ/मैसेजपैक तेजी से; CDN/ब्राउज़र के लिए - ब्रोटली के साथ JSON।

रेडिस में संपीड़न: वस्तुओं के लिए फायदेमंद> 1-2 केबी, लेकिन सीपीयू पर नजर रखें।

आंशिक प्रतिक्रियाएं/ऑन-डिमांड फ़ील्ड: कम बाइट्स - कम टीटीएफबी और रैम।

9) पूर्वनिर्धारण नीतियां और आकार

LRU (डिफ़ॉल्ट) - सुरक्षित; LFU "लोकप्रिय" सामग्री के लिए बेहतर है।

कुंजी/मान आकार: नियंत्रण में रखें (मेट्रिक्स 'एवीजी मान आकार', 'अधिकतम').

Namespace/किरायेदार कोटा ताकि एक उत्पाद पूरे कैश को "खाएं" न।

10) सुरक्षा और पीआईआई/पीसीआई

व्यक्तिगत/वित्तीय डेटा - सीडीएन/एज पर और सामान्य परतों में कैश न करें; टोकन/अनुमानों का उपयोग करें।

क्लाइंट-साइड क्रिप्टो (टीटीएल नियंत्रण हानि के बारे में सावधानी के साथ) के माध्यम से रेडिस में संवेदनशील मूल्यों का एन्क्रिप्शन।

सख्त एसीएल और नेटवर्क अलगाव; प्रदाताओं को प्रदान करने के लिए निश्चित NAT/IP।

11) अवलोकन और कैश एसएलओ

• हिट अनुपात (परत और उपसर्ग द्वारा), मूल ऑफलोड।
• TTFB/P95/P99 कैश से पहले/बाद में, लेटेंसी रेडिस।
• निष्कासन, OOM, कीस्पेस हिट/मिस।
• भगदड़ दर, ताज़ा समय।
• बासी ने% и ताजगी अंतराल की सेवा की।

• गेम कैटलॉग: हिट अनुपात 85%, TTFB 150 ms (किनारे)।
• एपीआई निर्देशिका: पुनर्मूल्यांकन-हिट ≥ 60%, P95 ≤ 200 एमएस।
• रेडिस: P99 ऑपरेशन ≤ 5 ms, निष्कासन प्रति घंटे 1% से अधिक नहीं।

12) FinOps: कैश वैल्यू

$/जीबी महीना रैम बनाम $/आरपीएस मूल: पेबैक बिंदु की गणना करें।

ऑफलोड और एग्रेस: सीडीएन + रेडिस क्षेत्र-मूल से आउटबाउंड ट्रैफिक को कम करता है।

Image/WebP/AVIF और denormalization सबसे बड़ी बाइट बचत प्रदान करते हैं।

"महंगी मिस" सीमित करें: एनालिटिक्स "बाइट्स × मिस × क्षेत्र"।

13) उदाहरण (टुकड़े)

13. सिंगल-फ्लाइट (स्यूडोकोड) के साथ 1 कैश-अलावा

python def get(key, ttl, loader):
val = redis. get(key)
if val: return val with single_flight (key): # only one updates val = redis. get (key) # double check if val: return val data = loader () # request to source redis. setex(key, ttl_with_jitter(ttl), serialize(data))
return data

13. 2 घटना द्वारा विकलांगता का प्रकाशन

json
{
"event": "game. updated",
"game_id": "g123",
"affected": ["catalog:list:region=TR", "game:card:g123:"]
}

उपभोक्ता चैनल की सदस्यता लेता है और 'DEL '/' PUBISH' match कुंजी/टैग बनाता है।

13. स्कीमा संस्करण और लोकेल के साथ 3 कुंजी

game:card:v2:id=g123    region=BR    currency=BRL    lang=pt-BR

14) कार्यान्वयन चेकलिस्ट

1. कैश लेवल मैप और टीटीएल मैट्रिक्स (स्थिर/अर्ध-स्थिर/एपीआई)।

2. मुख्य नामकरण: डोमेन, स्कीमा संस्करण, स्थानीय/क्षेत्र/मुद्रा, किरायेदार।

3. प्रति अंतबिंदु पैटर्न चुनें (पूछें/read-the/write-the/back).

4. SWR/SIE, सिंगल-फ्लाइट और TTL जिटर बनाम भगदड़।

5. घटनाओं (पब/सब) द्वारा अक्षम, समूहों के लिए टैग-पर्ज.

6. चोटियों से पहले गर्म चाबियों और प्रीवार्म के लिए निकट-कैश।

7. प्रारूप और संपीड़न (प्रोटोबुफ/MsgPack, Brotli), आकार नियंत्रण।

8. LRU/LFU नीतियां, नेमस्पेस/किरायेदार कोटा।

9. SLO/метрики: हिट अनुपात, विलंबता, निष्कासन, बासी%, ताजगी अंतराल।

10. सुरक्षा: व्यक्तिगत, टोकन, नेटवर्क/एसीएल के लिए नो-स्टोर।

15) एंटी-पैटर्न

'नो-कैश' "सिर्फ मामले में" और टीटीएल विफलताएं शून्य ऑफलोड हैं।

कुंजी में सभी प्रश्न/हेडर → कार्डिनैलिटी विस्फोट शामिल हैं।

प्रत्येक रिलीज के साथ थोक "कुल सीडीएन/रेडिस"।

भगदड़ के खिलाफ सुरक्षा की कमी और "शीर्ष कुंजी" की एक बार समाप्ति।

कोटा/अलगाव के बिना एकल सामान्य रेडिस; "हॉट" किरायेदार पूरे कैश को खाता है।

किनारे/सीडीएन के लिए व्यक्तिगत प्रतिक्रियाओं को कैचिंग।

कोई ताजगी/निष्कासन टेलीमेट्री नहीं - अंधा नियंत्रण।

16) iGaming संदर्भ/फिनटेक: व्यावहारिक नोट्स

लीडरबोर्ड/रेटिंग: टीटीएल 2-10 एस, कुल धाराएँ + सीआरडीटी, दुर्घटनाओं में एसडब्ल्यूआर।

गेम्स कैटलॉग/बैनर: सीडीएन + रेडिस; कुंजी: क्षेत्र/मुद्रा/भाषा; "प्रोमो: अपडेट" टैग द्वारा विकलांगता।

भुगतान की स्थिति: लेखन पथ में कोई कैश नहीं; पढ़ें - छोटा TTL (≤3 -5 सेकंड) या प्रत्यक्ष अनुरोध।

KYC/AML उत्तर: कैश गैर-PII डेरिवेटिव (स्टेटस), Redis में छवियों/दस्तावेजों को संग्रहीत न करें।

वीआईपी पथ: अलग नेमस्पेस/रेडिस पूल, प्राथमिकता सेवा।

कुल

एक मजबूत कैश रणनीति स्तर की वास्तुकला, सही अद्यतन पैटर्न, विचारशील टीटीएल/विकलांगता, भगदड़ प्रतिरोध, साफ कुंजी और संस्करण और अवलोकन और फिनोप्स है। इन सिद्धांतों का पालन करके, आप P95/P99 की पूंछ को स्थिर करेंगे, स्रोतों पर भार को कम करेंगे और प्रति मिलीसेकंड एक अनुमानित लागत प्राप्त करेंगे - वास्तव में जहां यह उत्पाद और व्यवसाय के लिए सबसे महत्वपूर्ण है।