𝗛𝗼𝘄 𝗜 𝗕𝘂𝗶𝗹𝘁 𝗮 𝗦𝗲𝘁 𝗜𝘁 𝗮𝗻𝗱 𝗙𝗼𝗿𝗴𝗲𝘁 𝗜𝘁 𝗦𝘆𝗻𝗰 𝗦𝘆𝘀𝘁𝗲𝗺
પ્રોડક્ટના ભાવ ઘણી જગ્યાએ બદલાય છે. તેઓ એડમિન પેનલમાં, બલ્ક ઈમ્પોર્ટ દ્વારા, અથવા API webhooks દ્વારા બદલાય છે.
જો તમે આ ફેરફારોને બાહ્ય માર્કેટપ્લેસ સાથે સિંક કરવા માંગતા હોવ, તો તમને એક સમસ્યાનો સામનો કરવો પડશે. દરેક કોડ પાથમાં સિંક કોલ ઉમેરવો એ એક ભૂલ છે. તમે એક ભૂલી જશો. તમે એક તોડી નાખશો. મેન્ટેનન્સ (જાળવણી) એક દુઃસ્વપ્ન બની જશે.
Django signals આ સમસ્યાનું સમાધાન કરે છે. તમે મોડેલ સેવ (model save) ઇવેન્ટ સાથે જોડાઈ શકો છો. આ એક જ જગ્યાએ દરેક ફેરફારને પકડી લે છે.
પરંતુ signals માં એક ખામી છે. જો તમે એકસાથે 100 ભાવ અપડેટ કરો છો, તો signal 100 વખત ફાયર થાય છે. આનાથી 100 API calls ટ્રિગર થાય છે. તમે રેટ લિમિટ (rate limits) પર પહોંચી જશો અથવા સંસાધનોનો બગાડ કરશો.
આને ઠીક કરવા માટે હું ત્રણ ભાગોની પેટર્નનો ઉપયોગ કરું છું:
• એક signal handler જે તરત જ કામ કરવાને બદલે IDs એકત્રિત કરે છે.
• ડુપ્લીકેટ્સ દૂર કરવા માટે એક per-thread set.
• બધું એકસાથે પ્રોસેસ કરવા માટે transaction.on_commit નો ઉપયોગ કરીને એક flush callback.
તે કેવી રીતે કામ કરે છે તે અહીં છે.
threading.local()નો ઉપયોગ કરો ગ્લોબલ વેરિએબલનો ઉપયોગ કરશો નહીં. ગ્લોબલ વેરિએબલ્સ વિનંતીઓ (requests) વચ્ચે સ્ટેટ શેર કરે છે. આનાથી ડેટા લીકેજ થઈ શકે છે.threading.local()ડેટાને સિંગલ થ્રેડ સુધી અલગ રાખે છે.રેકોર્ડ કરો, કામ ન કરો Signal handler ફક્ત પ્રોડક્ટ ID ને એક set માં ઉમેરે છે. ત્યારબાદ તે Django ને જણાવે છે કે ડેટાબેઝ ટ્રાન્ઝેક્શન સફળ થયા પછી જ flush ફંક્શન ચલાવવું. આનાથી સેવ કરવામાં નિષ્ફળ જતાં ડેટાને સિંક થતો અટકાવવામાં આવે છે.
કામને બેચમાં કરો જ્યારે ટ્રાન્ઝેક્શન કમિટ (commit) થાય છે, ત્યારે flush ફંક્શન ચાલે છે. તે set ની નકલ કરે છે અને તેને ક્લિયર કરે છે. ત્યારબાદ તે ID ની આખી યાદી service layer ને મોકલે છે.
Service layer બધી પ્રોડક્ટ્સ મેળવવા માટે એક જ બલ્ક ક્વેરી (bulk query) કરે છે. તે તેમને સ્ટોર મુજબ ગ્રુપ કરે છે. અંતે, તે દરેક સ્ટોર માટે Celery ને એક સિંગલ ટાસ્ક મોકલે છે.
તેના ફાયદા સ્પષ્ટ છે:
- Deduplication આપમેળે થાય છે. એક set તમારા માટે આ સંભાળી લે છે.
- Transaction safety ઇન-બિલ્ટ છે. તમે ક્યારેય રોલ-બેક (rolled-back) થયેલ ડેટા સિંક કરતા નથી.
- કાર્યક્ષમતા (Efficiency) ઊંચી છે. તમે N+1 ક્વેરી સમસ્યાઓથી બચી શકો છો.
- વિશ્વસનીયતા (Reliability) ઊંચી છે. જો API નિષ્ફળ જાય તો Celery રીટ્રાય (retries) સંભાળે છે.
તમે સિસ્ટમ એકવાર બનાવો છો. તમે પછીથી ઉમેરતા દરેક નવા ફીચર સિંક સિસ્ટમ સાથે આપમેળે કામ કરે છે.
તમે Django માં એક્સટર્નલ API સિંક કેવી રીતે હેન્ડલ કરો છો? શું તમે signals નો ઉપયોગ કરો છો કે કોઈ અલગ પેટર્નનો?
Source: https://dev.to/acel/how-i-built-a-set-it-and-forget-it-sync-system-with-django-signals-2ld7