कैशिंग लेनदेन और गेमिंग परिणाम: दृष्टिकोण और जोखिम
1) कैश क्यों और आपको वास्तव में इसकी आवश्यकता कहां है
कैश विलंबता को कम करने और कोर पर लोड करने का एक उपकरण है। IGaming में, यह के लिए महत्वपूर्ण है:- बैलेंस शीट और लेनदेन स्टेटस (अक्सर GET अनुरोध) पढ़ ना;
- खेल/स्पिन और समुच्चय का इतिहास (लीडरबोर्ड के शीर्ष, अंतिम एन परिणाम);
- खेल/प्रदाताओं, सट्टेबाजी की सीमा, स्थिर निर्देशिकाओं का मेटाडेटा;
- UX (बैनर, प्रचार स्टेटस) के लिए गुणांक और "त्वरित" संदर्भों के फीड।
लेकिन कैश कभी भी पैसे और परिणामों के लिए सच्चाई का स्रोत नहीं है। सत्य - बही/बटुआ तथा प्रदाता से अभिपुष्ट परिणाम।
2) लाल रेखा: कि आप कैश नहीं कर सकते
रिकॉर्डिंग धन: शेष राशि (रिकॉर्डिंग ऑपरेशन) को डेबिट/क्रेडिट करना - केवल लेनदेन और पहचान के साथ/लेजर डेटाबेस के माध्यम से।
प्रदाता पुष्टि से पहले शर्त/जीत निर्णय।- KYC/AML और भुगतान को प्रभावित करने वाले अनुपालन झंडे।
- रहस्य/टोकन (प्रक्रिया स्मृति में कैश मान्य है, लेकिन साझा कैश नहीं)।
3) बेसिक कैशिंग पैटर्न
कैश-एक तरफ (आलसी): एप्लिकेशन पहले कैश में दिखता है, अगर यह याद आता है, तो यह डेटाबेस से पढ़ ता है और इसे कैश में रखता है ('मिस्ड लोड सेट')। बहुमुखी और पढ़ ने के लिए सुरक्षित।
राइट-थ्रू: डेटाबेस पर लिखना कैश के माध्यम से जाता है; यह सुनिश्चित करता है कि कुंजी आज तक है, लेकिन रिकॉर्ड की विलंबता को बढ़ाता है।
लिखने के पीछे (राइट-बैक): पहले कैश पर लिखना, फिर डेटाबेस में अतुल्यकालिक रूप से। धन/परिणाम के लिए वर्जित - गिरते समय हानि का जोखिम।
रीड-थ्रू: कैश खुद जानता है कि डेटाबेस से कैसे बाहर निकलना है (प्रॉक्सी कैश, उदाहरण के लिए, मॉड्यूल/साइडकार के साथ रेडिस)। मेटाडेटा के लिए अच्छा है।
सिफारिश: रीड्स के लिए कैश-अलग, राइट-थ्रू केवल जहां सुरक्षित, राइट-बैक - पैसे/गेम सच्चाई के लिए कभी नहीं।
4) स्थिरता और पहचान
सत्य का स्रोत: खाता (एपेंड-ओनली), 'ऑपरेशन _ आईडी' और पहचान प्रसंस्करण के साथ संचालन।
शेष: हम कैश से पढ़ ते हैं, लेकिन महत्वपूर्ण कार्यों (जमा/निकासी/बड़ीदर) से पहले डेटाबेस से किसी भी विसंगति की पुष्टि की जाती है।
विकलांगता: यदि संबंधित संतुलन/स्थिति कुंजियाँ सफलतापूर्वक → del/expire डेटाबेस पर लिखी जाती हैं।
Deduplication: वेबहूक/भुगतान के लिए आउटबॉक्स/इनबॉक्स + पहचान कुंजियाँ; कैश डीडअप में भाग नहीं लेता है, यह केवल पढ़ ने को गति देता है।
5) टीटीएल, विकलांगता और "अप्रचलन का अधिकार"
संतुलन के लिए शॉर्ट-टीटीएल: 1-5 सेकंड (या बैकग्राउंड रिफ्रेश के साथ सॉफ्ट-टीटीएल)।
लेनदेन की स्थिति: घटनाओं द्वारा सक्रिय विकलांगता के साथ छोटा टीटीएल (5-30 एस) ('जमा _ पूरा', 'सेटेड')।
खेल इतिहास: टीटीएल 1-10 मिनट, 'नया _ राउंड' घटना के कारण विकलांगता।
मेटाडेटा/निर्देशिका: टीटीएल 10-60 मिनट, कम होने पर वार्म-अप।
घटना-चालित विकलांगता: घटना बस (काफ्का/PubSub) 'बटुआ _ अद्यतन', 'शर्त _ बसा', 'बोनस _ परिवर्तित' → ग्राहक हटाते/अद्यतन कुंजी प्रकाशित करता है।
6) एंटी-स्टॉर्म पैटर्न (मिस स्टॉर्म और डोगन)
अनुरोध करें: एक धागा डेटाबेस के लिए अनुरोध "लीड" करता है, बाकी इंतजार कर रहे हैं (प्रति कुंजी म्यूटेक्स)।
बासी-जबकि-पुनर्नवीनीकरण: पृष्ठभूमि में एक साथ "थोड़ापुराना" दें।
टीटीएल के लिए जिटर: यादृच्छिक TTL ( 20%) इसलिए कुंजियाँ एक ही समय में समाप्त नहीं होती हैं।
मिस पर बैक-ऑफ: लगातार यादों/त्रुटियों के साथ - अस्थायी नकारात्मक-कैश (नीचे देखें)।
7) नकारात्मक-कैशिंग और ग्रे कार्डिनल त्रुटियां
"नहीं मिला" के लिए (उदाहरण के लिए, अभी तक कोई लेनदेन की स्थिति नहीं है) - एक छोटा नकारात्मक टीटीएल 1-3 एस।
कुछ सेकंड से अधिक के लिए डाटाबेस/प्रदाता त्रुटियों को कैश न करें - अन्यथा दुर्घटना को ठीक करें।
अवलोकन के लिए कैनरी कुंजी दर्ज करें: नकारात्मक हिट की हिस्सेदारी में वृद्धि अलर्ट का एक कारण है।
8) मुख्य संरचना और विभाजन
Именование: : 'वॉलेट: {userId}', 'txn: {txnId}: स्थिति', 'गेम: {प्रदाता}: {प्रदाता}: {TabeId}: अंतिम _ परिणाम', 'लीडरबोर्ड: {resultId}: top100'।
Env/क्षेत्र/ब्रांड द्वारा खंड/नेमस्पेस: 'प्रोड: यूरोपीय संघ: बटुआ: {UsureId}' - चौराहों और क्रॉस-क्षेत्र कचरा को बाहर करें।
कार्डिनैलिटी को सीमित करें - विशेष रूप से लीडरबोर्ड और इतिहास के लिए।
9) किनारे पर कैश, क्लस्टर में और स्मृति में
एज कैश (CDN/WAF): केवल गैर-व्यक्तिगत डेटा (गेम मेटाडेटा, सार्वजनिक नेताओं, मीडिया) के लिए। क्वेरी पैरामीटर - व्हाइटलिस्ट; कैश-बस्टिंग सुरक्षा।
Redis/Memcatched (क्लस्टर): व्यक्तिगत रीडिंग के लिए आधार; AOF/RDB स्नैपशॉट, प्रतिकृति और कोटा शामिल करें।
इन-प्रोसेस कैश: गर्म निर्देशिकाओं के लिए माइक्रोसेकंड एक्सेस; अक्षम तंत्र (प्रसारण, संस्करण कुंजी) आवश्यक हैं।
10) धन मामले: सुरक्षित त्वरण
खिलाड़ी संतुलन
पढ़ें: TTL 1-5 s के साथ कैश-अलग।
रिकॉर्ड: शेष - डेल कैश डेटाबेस में लेनदेन; एक महत्वपूर्ण कार्रवाई (आउटपुट/बड़ेदांव पर) - "डीबी से फिर से चेक करें।"
एंटीगोन: बैलेंस शीट का आशावादी लॉकिंग संस्करण।
भुगतान की स्थिति
परिदृश्य: उपयोगकर्ता "अपडेट स्थिति" दबाता है।
समाधान: कैश-अलग + नकारात्मक टीटीएल को "लंबित "/" अज्ञात "2-5 एस; PSP वेबहुक अपडेट → विकलांगता।
बोनस/वेगर
एग्रीगेट्स (% में प्रगति): कैश 10-30 एस; 'शर्त _ स्थान/सेटलमेंट' घटना के कारण विकलांगता।
11) खेल के मामले: सच्चाई की विकृतियों के बिना एक उच्च गति वाला मोर्चा
स्पिन/सट्टेबाजी का इतिहास
अंतिम N घटनाएँ: प्रतिबंध के साथ कैश सूची (उदाहरण के लिए, 100), TTL 1-10 मिनट, 'गोल _ समाप्त' घटना द्वारा पुनः पूर्ति।
आप प्रदाता से पुष्टि होने तक "जीत" नहीं दिखा सकते हैं - मध्यवर्ती स्थिति "लंबित" है।
लाइव गेम्स (WebSocket)
तेजी से जुड़े ग्राहकों के लिए 1-3 सेकंड के लिए हालिया संदेश/तालिका स्थिति का अल्पकालिक कैश।
'टेबलआईडी/बाजार' द्वारा खंड राज्य कुंजियां।
लीडरबोर्ड
10-60 एस के लिए प्रीकॉम्प्यूट + कैश; बड़े पैमाने पर अपडेट के लिए - बैच अपडेट और "विंडो" की आंशिक विकलांगता।
12) जोखिम और उन्हें कैसे बंद करें
डबल चार्ज/फैंटम जीतता है: केवल कैश से पढ़ें; सभी शुल्क/क्रेडिट - डीबी और पहचान के माध्यम से।
पुराने डेटा - खिलाड़ी के साथ विवाद: छोटी टीटीएल, भुगतान से पहले "सख्त वास्तविकता", पारदर्शी स्थिति ("पुष्टि की प्रतीक्षा")।
स्प्लिट-ब्रेन कैश क्लस्टर: कोरम/सेंटिनल, टाइमआउट, राइट-बैक से इनकार करें।
गर्म चाबियों पर कैश भगदड़: कोलसिंग, जिटर, बासी-जबकि-पुनर्नवीनीकरण।
कैश इंजेक्शन/विषाक्तता: मजबूत कुंजी, कैश एपीआई प्रतिक्रियाओं के लिए हस्ताक्षर/हस्ताक्षर, कैनरी जांच।
गोपनीयता/पीआईआई: चैनल एन्क्रिप्शन (एमटीएलएस), व्यक्तिगत डेटा के लिए किनारे पर कैश निषेध, छोटा टीटीएल, लॉगआउट सफाई।
13) कैश वेधशाला
प्रति परत मेट्रिक्स:- कुंजी श्रेणी द्वारा हिट/मिस अनुपात; redis_ops/sec, विलंबता p95/p99, निष्कासन, memory_usage।
- कैनरी कुंजियाँ: 'cache _ health: {segue}' - नकारात्मक कैश के हिस्से की जाँच करता है और समय को अद्यतन करता है।
- लॉग: बैचों में "मिस", एक सेगमेंट पर लगातार 'डेल' = "शोर" सेवा का संकेत।
- ट्रेल्स: कुंजी टैग (पीआईआई के बिना) के साथ "कैश गेट/सेट/डेल" फैलाता है।
14) मिनी-आर्किटेक्चर (संदर्भ)
1. एप्लिकेशन (API/WS) → रेडिस क्लस्टर (TLS, auth)।
2. सत्य का स्रोत: बटुआ डीबी (खाता), खेल परिणाम स्टोर।
3. घटना बस: 'बटुआ _ अद्यतन', 'शर्त _ बसा', 'प्रोमो _ परिवर्तित'.
4. अक्षम: → 'del '/' सेट' हॉट कुंजी इवेंट सब्सक्राइबर।
5. एज कैश: सार्वजनिक संसाधन/नेतृत्व बोर्ड केवल।
6. अवलोकन: कैश डैशबोर्ड, भगदड़ अलर्ट, नकारात्मक हिट।
15) टीटीएल नीतियां (नमूना मैट्रिक्स)
16) नमूना छद्म कोड (सुरक्षित संतुलन पढ़ें)
अजगर def get_balance (user_id):
कुंजी = f "बटुआ: {user _ id}"
bal = कैश। मिल (कुंजी)
यदि बाल कोई नहीं है:
वापसी बाल मिस: इसे डेटाबेस से लें और इसे एक छोटे TTL + जिटर bal = db के साथ रखें। get_wallet_balance (user_id)
कैश। सेट (कुंजी, बाल, ttl = randint (1,5))
वापसी बाल
def apply_transaction (op_id, user_id, डेल्टा):
डेटाबेस में परमाणु प्रविष्टि निष्क्रियता के साथ यदि db। exists_op (op_id):
वापसी db। get_result (op_id)
res = db। apply_ledger (op_id, user_id, डेल्टा) # कैश लेनदेन। हटाएं (f "बटुआ: {user _ id}") # विकलांगता रिटर्न रेस17) उत्पादन तत्परता चेकलिस्ट
- स्पष्ट परिसीमन: डेटाबेस में सत्य, कैश - केवल पढ़ ने के लिए।
- पैटर्न: पढ़ ने के लिए कैश-अलग; राइट-पीछे निषिद्ध है।
- ईवेंट विकलांगता: 'वॉलेट _ अपडेटेड', 'बेट _ सेटेड', 'प्रोमो _ चेंज'।
- शॉर्ट टीटीएल + जिटर; नकारात्मक-कैश ≤ 3 с।
- एंटी-स्टॉर्म: कोलसिंग, बासी-जबकि-पुनर्नवीनीकरण।
- env/क्षेत्र/ब्रांड द्वारा कुंजी विभाजन; कार्डिनैलिटी सीमा।
- अवलोकन: हिट/मिस, बेदखली, p95, भगदड ़/नकारात्मक-स्पाइक्स पर अलर्ट।
- केवल सार्वजनिक डेटा के लिए एज कैश; व्यक्तिगत - केवल Redis/TLS में।
- रनबुक: सिंक से बाहर होने पर क्या करना है (जबरन ताज़ा, अस्थायी रूप से खंड कैश को अक्षम करना)।
- नियमित परीक्षण: गर्म कुंजी भार, भगदड़ अभ्यास।
सारांश फिर से शुरू करें
IGaming में कैश एक रीडिंग एक्सेलेरेटर है, न कि पैसे के लिए "दूसरा डेटाबेस। "बही में सच्चाई को रखें, निष्क्रियता और घटना विकलांगता सुनिश्चित करें, छोटे टीटीएल और एंटी-स्टॉर्म यांत्रिकी, अलग किनारे कैश और व्यक्तिगत डेटा, कैश मेट्रिक्स की निगरानी रखें। इसलिए आपको "जीतने का भ्रम", दोहरा शुल्क और नियामक समस्याओं के बिना एक त्वरित यूएक्स मिलता है।
