मैंने एक 'Set It and Forget It' सिंक सिस्टम कैसे बनाया
प्रोडक्ट की कीमतें कई जगहों पर बदलती हैं। वे एडमिन पैनल में, बल्क इम्पोर्ट के माध्यम से, या API वेबहुक के जरिए बदलती हैं।
यदि आप इन बदलावों को किसी बाहरी मार्केटप्लेस के साथ सिंक करना चाहते हैं, तो आपको एक समस्या का सामना करना पड़ता है। हर एक कोड पाथ (code path) में सिंक कॉल जोड़ना एक गलती है। आप एक को भूल जाएंगे। आप एक को तोड़ देंगे। मेंटेनेंस एक दुस्वप्न बन जाता है।
Django signals इसे हल करते हैं। आप मॉडल सेव इवेंट (model save event) से जुड़ जाते हैं। यह एक ही जगह पर हर बदलाव को पकड़ लेता है।
लेकिन signals में एक खामी है। यदि आप एक साथ 100 कीमतें अपडेट करते हैं, तो signal 100 बार फायर होता है। इससे 100 API कॉल ट्रिगर होते हैं। आप रेट लिमिट (rate limits) का सामना करेंगे या संसाधनों की बर्बादी करेंगे।
मैं इसे ठीक करने के लिए तीन-भागों वाले पैटर्न का उपयोग करता हूँ:
• एक signal handler जो तुरंत कार्रवाई करने के बजाय IDs को इकट्ठा करता है। • डुप्लिकेट्स हटाने के लिए एक per-thread set। • सब कुछ एक साथ प्रोसेस करने के लिए transaction.on_commit का उपयोग करने वाला एक flush callback।
यह कैसे काम करता है, यहाँ देखें।
threading.local() का उपयोग करें ग्लोबल वेरिएबल (global variable) का उपयोग न करें। ग्लोबल वेरिएबल्स रिक्वेस्ट के बीच स्टेट (state) साझा करते हैं। इससे डेटा लीकेज हो सकता है। threading.local() डेटा को एक सिंगल थ्रेड तक सीमित रखता है।
रिकॉर्ड करें, कार्रवाई न करें Signal handler बस प्रोडक्ट ID को एक set में जोड़ देता है। फिर यह Django को बताता है कि डेटाबेस ट्रांजेक्शन (database transaction) सफल होने के बाद ही flush फंक्शन चलाए। यह उस डेटा को सिंक करने से रोकता है जो सेव होने में विफल रहा हो।
काम को बैच (batch) में करें जब ट्रांजेक्शन कमिट (commit) होता है, तो flush फंक्शन चलता है। यह set की कॉपी बनाता है और उसे क्लियर कर देता है। फिर यह IDs की पूरी लिस्ट को एक service layer को भेज देता है।
Service layer सभी प्रोडक्ट्स को प्राप्त करने के लिए एक बल्क क्वेरी (bulk query) करती है। यह उन्हें स्टोर के आधार पर ग्रुप करती है। अंत में, यह प्रति स्टोर Celery को एक सिंगल टास्क भेजती है।
इसके फायदे स्पष्ट हैं:
- Deduplication स्वचालित है। एक set इसे आपके लिए संभाल लेता है।
- Transaction safety इन-बिल्ट है। आप कभी भी रोलबैक (rolled-back) किया गया डेटा सिंक नहीं करते।
- Efficiency अधिक है। आप N+1 query समस्याओं से बचते हैं।
- Reliability अधिक है। यदि API विफल हो जाता है, तो Celery रिट्राइज़ (retries) को संभालता है।
आप सिस्टम को एक बार बनाते हैं। बाद में आपके द्वारा जोड़ा गया हर नया फीचर स्वचालित रूप से सिंक सिस्टम के साथ काम करता है।
आप Django में बाहरी API सिंक को कैसे संभालते हैं? क्या आप signals का उपयोग करते हैं या किसी अलग पैटर्न का?
स्रोत: https://dev.to/acel/how-i-built-a-set-it-and-forget-it-sync-system-with-django-signals-2ld7