Cron Jobs-ൽ ഡ്യൂപ്ലിക്കേറ്റ് റെക്കോർഡുകൾ എങ്ങനെ തടയാം

സോഫ്റ്റ്‌വെയറുകൾ കൈകാര്യം ചെയ്യുമ്പോൾ, ടാസ്കുകൾ തടസ്സങ്ങളില്ലാതെയും ആവർത്തനങ്ങളില്ലാതെയും നടക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കേണ്ടത് അത്യാവശ്യമാണ്. ഡിസ്ട്രിബ്യൂട്ടഡ് സിസ്റ്റങ്ങളിൽ സാധാരണയായി കാണപ്പെടുന്ന ഒരു പോരായ്മയെക്കുറിച്ചാണ് നമ്മൾ ഇവിടെ പരിശോധിക്കുന്നത്: ഒരു in-process scheduler കാരണം ഒരു nightly job പലതവണ പ്രവർത്തിക്കാനും, അത് നിങ്ങളുടെ ഡാറ്റാബേസിൽ ഡ്യൂപ്ലിക്കേറ്റ് റെക്കോർഡുകൾക്ക് കാരണമാകാനും ഇടയാകുന്നത് എങ്ങനെയാണെന്ന് നോക്കാം. സർവീസുകൾ തിരശ്ചീനമായി സ്കെയിൽ ചെയ്യുന്ന microservices architecture കൂടുതൽ കമ്പനികൾ സ്വീകരിക്കുന്ന സാഹചര്യത്തിൽ ഈ വിഷയം പ്രത്യേകിച്ചും പ്രസക്തമാണ്.

സജ്ജീകരണം

നിങ്ങളുടെ ആപ്ലിക്കേഷനിലെ സജീവമായ എന്റിറ്റികൾക്കായി റെക്കോർഡുകൾ നിർമ്മിക്കുന്ന ഒരു nightly job ഉണ്ടെന്ന് കരുതുക. ഓരോ എന്റിറ്റിക്കും ഓരോ പുതിയ റെക്കോർഡ് വീതം സൃഷ്ടിച്ചുകൊണ്ട് ദിവസത്തിൽ ഒരിക്കൽ പ്രവർത്തിക്കാനാണ് ഈ ജോബ് ഉദ്ദേശിക്കുന്നത്. സെർവർ-സൈഡ് ആപ്ലിക്കേഷനുകൾ നിർമ്മിക്കുന്നതിനുള്ള ജനപ്രിയ ഫ്രെയിംവർക്കായ NestJS ഉപയോഗിച്ചുള്ള ഒരു സാധാരണ സജ്ജീകരണത്തിൽ, നിങ്ങൾ @Cron decorator ഉപയോഗിച്ചായിരിക്കും ഈ ജോബ് ഷെഡ്യൂൾ ചെയ്യുന്നത്. അത് എങ്ങനെയായിരിക്കുമെന്നതിന്റെ ലളിതമായ ഒരു രൂപം ഇതാ:

@Injectable()
export class WindowGenerationService {
    @Cron('0 8 * * *') // every day at 08:00
    async generateNextWindows() {
        const entities = await this.repo.findActiveEndingSoon();
        for (const entity of entities) {
            await this.repo.createNextWindow(entity);
        }
    }
}

നിങ്ങളുടെ സർവീസിന്റെ ഒരു സിംഗിൾ ഇൻസ്റ്റൻസ് മാത്രം പ്രവർത്തിക്കുമ്പോൾ ഈ കോഡ് കൃത്യമായി പ്രവർത്തിക്കുന്നു. എന്നാൽ, ഒന്നിലധികം ഇൻസ്റ്റൻസുകൾ പ്രവർത്തിപ്പിച്ചുകൊണ്ട് നിങ്ങൾ ആപ്ലിക്കേഷൻ തിരശ്ചീനമായി സ്കെയിൽ ചെയ്യുമ്പോൾ കാര്യങ്ങൾ തകിടം മറിഞ്ഞേക്കാം.

പ്രശ്നം

സ്കെയിൽ ചെയ്ത ഒരു സജ്ജീകരണത്തിൽ, നിങ്ങളുടെ സർവീസിന് മൂന്ന് ഇൻസ്റ്റൻസുകൾ ഉണ്ടെങ്കിൽ, ഓരോ ഇൻസ്റ്റൻസും ഒരേ സമയം തന്നെ ഷെഡ്യൂൾ ചെയ്ത ജോബിന്റെ സ്വന്തം പതിപ്പ് പ്രവർത്തിപ്പിക്കും. അതിനാൽ, 08:00-ന് ഒരു ജോബ് പ്രവർത്തിക്കുന്നതിന് പകരം, ഒരേ സമയം മൂന്ന് ജോബുകൾ ഒരുമിച്ച് പ്രവർത്തിക്കുന്നു. റെക്കോർഡുകൾ ഇതിനകം നിലവിലുണ്ടോ എന്ന് പരിശോധിക്കാതെ തന്നെ ഓരോ ഇൻസ്റ്റൻസും സ്വന്തമായി റെക്കോർഡുകൾ നിർമ്മിക്കുന്നു. ഇത് നിങ്ങളുടെ ഡാറ്റാബേസിൽ ഡ്യൂപ്ലിക്കേറ്റ് എൻട്രികൾ ഉണ്ടാകുന്നതിലേക്ക് നയിക്കുന്നു, അവിടെ ഒരേ എന്റിറ്റിക്കായി നിമിഷങ്ങളുടെ വ്യത്യാസത്തിൽ ഒരേപോലെയുള്ള രണ്ട് റെക്കോർഡുകൾ സൃഷ്ടിക്കപ്പെടുന്നു.

ഇത് എന്തുകൊണ്ട് പ്രധാനമാണ്

ഡ്യൂപ്ലിക്കേറ്റ് ഡാറ്റ, ഡാറ്റാ ഇന്റഗ്രിറ്റി പ്രശ്നങ്ങളും വിഭവങ്ങൾ പാഴാകലും ഉൾപ്പെടെയുള്ള വിവിധ പ്രശ്നങ്ങളിലേക്ക് നയിച്ചേക്കാം. അനാവശ്യമായ റെക്കോർഡുകൾ സൃഷ്ടിക്കുന്നത് മാത്രമല്ല, ഒരേ ജോലി ചെയ്യുന്ന മൂന്ന് കണ്ടെയ്നറുകളുടെ കമ്പ്യൂട്ട് റിസോഴ്സുകൾക്കായി നിങ്ങൾ പണം നൽകേണ്ടിയും വരുന്നു.

സാധ്യമായ പരിഹാരങ്ങൾ

പ്രശ്നം തിരിച്ചറിഞ്ഞ ശേഷം, അത് പരിഹരിക്കാൻ നിരവധി മാർഗ്ഗങ്ങളുണ്ട്:

ഓപ്ഷൻ 1: Distributed Lock ഉപയോഗിക്കുക

ഒരു distributed lock നടപ്പിലാക്കുക എന്നതാണ് ഒരു പരിഹാരം. ഇത് ഇൻസ്റ്റൻസുകളെ ലോക്കിനായി മത്സരിക്കാൻ അനുവദിക്കുകയും, ഒരു ഇൻസ്റ്റൻസിന് മാത്രം ജോബ് പ്രവർത്തിപ്പിക്കാൻ അനുവാദം നൽകുകയും ചെയ്യുന്നു. എന്നിരുന്നാലും, ഈ സമീപനത്തിന് അതിന്റേതായ പോരായ്മകളുണ്ട്. ലോക്ക് ബാക്കെൻഡ് പരാജയപ്പെടുകയോ ലോക്ക് കൈവശം വെച്ചിരിക്കുന്ന സമയത്ത് ഒരു ഇൻസ്റ്റൻസ് പ്രവർത്തനരഹിതമാവുകയോ ചെയ്താൽ, ജോബ് ഒട്ടും പ്രവർത്തിക്കാതിരിക്കാനും എക്സിക്യൂഷനുകൾ നഷ്ടപ്പെടാനും സാധ്യതയുണ്ട്.

ഓപ്ഷൻ 2: Idempotency നടപ്പിലാക്കുക

മറ്റൊരു ഓപ്ഷൻ ഒരു idempotency ചെക്ക് ചേർക്കുക എന്നതാണ്. അതായത്, ജോബ് വീണ്ടും പ്രവർത്തിക്കുകയാണെങ്കിൽ, റെക്കോർഡുകൾ നിലവിലുണ്ടെങ്കിൽ അത് പുതിയവ സൃഷ്ടിക്കുന്നത് ഒഴിവാക്കും. ഇത് ചെലവ് കുറഞ്ഞ ഒരു പരിഹാരമാണെങ്കിലും, ഇപ്പോഴും എല്ലാ ഇൻസ്റ്റൻസുകളും ഉണർന്നു പ്രവർത്തിക്കുകയും അനാവശ്യമായ ജോലികളിലേക്ക് നയിക്കുകയും ചെയ്യുന്നു.

ഓപ്ഷൻ 3: ഷെഡ്യൂളിംഗ് ആപ്പിന് പുറത്തേക്ക് മാറ്റുക

കണ്ടെത്തിയതിൽ വെച്ച് ഏറ്റവും മികച്ച പരിഹാരം, ഷെഡ്യൂളിംഗ് ആപ്ലിക്കേഷന് പുറത്തേക്ക് മാറ്റുക എന്നതാണ്. ജോലികൾ എപ്പോൾ പ്രവർത്തിക്കണമെന്ന് ആപ്പ് കൈകാര്യം ചെയ്യുന്നതിന് പകരം, അതൊരു എക്സ്റ്റേണൽ ഷെഡ്യൂളറെക്കൊണ്ട് കൈകാര്യം ചെയ്യിക്കുക. ഇതുവഴി, ഷെഡ്യൂൾ ചെയ്ത സമയത്ത് എക്സ്റ്റേണൽ ഷെഡ്യൂളർ ഒരു തവണ മാത്രം ട്രിഗർ ചെയ്യുന്ന ഒരു HTTP എൻഡ്‌പോയിന്റ് നിങ്ങൾക്ക് സൃഷ്ടിക്കാൻ കഴിയും. അത് എങ്ങനെയായിരിക്കുമെന്ന് താഴെ കാണാം:

@Post('jobs/run')
async runJob(@Body() body: RunJobDto) {
    this.assertValidSecret(body.secret);
    return this.jobs.run(body.jobKey);
}

ഈ സജ്ജീകരണം വഴി, ജോബ് ട്രിഗറിനോട് ഒരു ഇൻസ്റ്റൻസ് മാത്രമേ പ്രതികരിക്കുകയുള്ളൂ, ഇത് ഡ്യൂപ്ലിക്കേറ്റ് റെക്കോർഡുകൾ സൃഷ്ടിക്കപ്പെടുന്നത് തടയുന്നു. ജോബ് ഒന്നിലധികം തവണ ട്രിഗർ ചെയ്യപ്പെട്ടാൽ പോലും ഡ്യൂപ്ലിക്കേറ്റുകൾ സൃഷ്ടിക്കപ്പെടുന്നില്ലെന്ന് ഉറപ്പാക്കാൻ idempotency ചെക്ക് നിലനിൽക്കുകയും ചെയ്യുന്നു.

ഇതിനു വരുന്ന ചിലവുകൾ

നിങ്ങൾ ഒരു ജോബിനെ ഒരു HTTP എൻഡ്‌പോയിന്റായി നൽകുമ്പോൾ, സുരക്ഷയെക്കുറിച്ച് നിങ്ങൾ ചിന്തിക്കേണ്ടതുണ്ട്. ഈ എൻഡ്‌പോയിന്റ് കണ്ടെത്തുന്ന ആർക്കും ഇത് ട്രിഗർ ചെയ്യാൻ കഴിഞ്ഞേക്കും. അനധികൃത ആക്സസ് തടയുന്നതിന്, റിക്വസ്റ്റുകൾ സാധൂകരിക്കാൻ ഒരു shared secret ഉപയോഗിക്കുന്നു. കൃത്യമായ ട്രിഗറുകൾക്ക് മാത്രമേ ജോബ് എക്സിക്യൂട്ട് ചെയ്യാൻ കഴിയൂ എന്ന് ഇത് ഉറപ്പാക്കുന്നു.

മറ്റൊരു കാര്യം ഷെഡ്യൂളിംഗ് സമയമാണ്. എല്ലാ ഉപയോക്താക്കൾക്കും ദിവസം ആരംഭിച്ചതിന് ശേഷം വേണം ജോബ് പ്രവർത്തിക്കാൻ, എന്നാൽ ഒന്നിലധികം ടൈം സോണുകൾ കൈകാര്യം ചെയ്യുമ്പോൾ ഇത് സങ്കീർണ്ണമായേക്കാം. ഒരു നിശ്ചിത UTC സമയം തിരഞ്ഞെടുക്കുന്നത് വിവിധ മേഖലകളിൽ ഇത് ഏകീകരിക്കാൻ സഹായിക്കും.

പാഠം

ഈ അനുഭവം ഒരു പ്രധാന പാഠം എടുത്തു കാണിക്കുന്നു: ഒരു distributed system-ൽ in-process scheduler അപ്രതീക്ഷിതമായ പെരുമാറ്റത്തിലേക്ക് നയിച്ചേക്കാം. നിങ്ങളുടെ ആപ്ലിക്കേഷൻ സ്കെയിൽ ചെയ്യുമ്പോൾ, ആപ്ലിക്കേഷൻ ലോജിക്കിൽ നിന്ന് ഷെഡ്യൂളിംഗിനെ വേർതിരിക്കേണ്ടത് അത്യാവശ്യമാണ്. അങ്ങനെ ചെയ്യുന്നതിലൂടെ, ഡ്യൂപ്ലിക്കേറ്റ് റൈറ്റുകളുടെ അപകടങ്ങൾ ഒഴിവാക്കാനും നിങ്ങളുടെ ജോലികൾ ഉദ്ദേശിച്ച രീതിയിൽ തന്നെ പ്രവർത്തിക്കുന്നുവെന്ന് ഉറപ്പാക്കാനും സാധിക്കും.

ഉപസംഹാരം

ചുരുക്കത്തിൽ, ഒരു microservices architecture-ൽ cron jobs കൈകാര്യം ചെയ്യുന്നതിന് കൃത്യമായ ആസൂത്രണം ആവശ്യമാണ്. ഷെഡ്യൂളിംഗ് നിങ്ങളുടെ ആപ്ലിക്കേഷന് പുറത്തേക്ക് മാറ്റുന്നതിലൂടെയും കൃത്യമായ പരിശോധനകൾ നടപ്പിലാക്കുന്നതിലൂടെയും, ഡ്യൂപ്ലിക്കേറ്റ് റെക്കോർഡുകൾ പോലെയുള്ള പ്രശ്നങ്ങൾ തടയാനും നിങ്ങളുടെ സർവീസുകളുടെ കാര്യക്ഷമത മെച്ചപ്പെടുത്താനും സാധിക്കും.

മേന്മകൾ

• ഡാറ്റാബേസിൽ ഡ്യൂപ്ലിക്കേറ്റ് റെക്കോർഡുകൾ ഉണ്ടാകുന്നത് തടയുന്നു.
• അനാവശ്യമായ കമ്പ്യൂട്ട് ചെലവുകൾ കുറയ്ക്കുന്നു.
• ഷെഡ്യൂളിംഗ് പുറത്തേക്ക് മാറ്റുന്നതിലൂടെ ജോബ് മാനേജ്‌മെന്റ് ലളിതമാക്കുന്നു.

പോരായ്മകൾ

• ഒരു എക്സ്റ്റേണൽ ഷെഡ്യൂളറിനായി അധിക സജ്ജീകരണം ആവശ്യമാണ്.
• HTTP റിക്വസ്റ്റുകളും സുരക്ഷയും കൈകാര്യം ചെയ്യുന്നതിൽ സങ്കീർണ്ണത കൊണ്ടുവരുന്നു.

മുന്നറിയിപ്പ്

ഈ ലേഖനം ഒരു വിദ്യാഭ്യാസപരമായ അവലോകനമായി നൽകിയിട്ടുള്ളതാണ്. ഇതിനെ ആശ്രയിക്കുന്നതിന് മുമ്പ് പ്ലേസ്‌ഹോൾഡർ മൂല്യങ്ങൾക്ക് പകരം നിങ്ങളുടെ യഥാർത്ഥ കോൺഫിഗറേഷനുകൾ നൽകാനും യഥാർത്ഥ ഉറവിടവുമായി ഒത്തുനോക്കി കാര്യങ്ങൾ ഉറപ്പുവരുത്താനും ശ്രദ്ധിക്കുക.

പതിവായി ചോദിക്കുന്ന ചോദ്യങ്ങൾ

• എന്താണ് cron job? — നിർദ്ദിഷ്ട സമയ ഇടവേളകളിൽ യാന്ത്രികമായി പ്രവർത്തിക്കുന്ന ഒരു ഷെഡ്യൂൾഡ് ടാസ്കാണ് cron job.
• എന്റെ cron job പലതവണ പ്രവർത്തിച്ചത് എന്തുകൊണ്ടാണ്? — നിങ്ങളുടെ ആപ്ലിക്കേഷന്റെ ഒന്നിലധികം ഇൻസ്റ്റൻസുകളിൽ ജോബ് ഷെഡ്യൂൾ ചെയ്തിട്ടുണ്ടെങ്കിൽ ഇത് സംഭവിക്കാം.
• ഒരു ഡാറ്റാബേസിൽ ഡ്യൂപ്ലിക്കേറ്റ് റെക്കോർഡുകൾ വരുന്നത് എങ്ങനെ തടയാം? — idempotency checks നടപ്പിലാക്കുക അല്ലെങ്കിൽ ഷെഡ്യൂളിംഗ് ആപ്ലിക്കേഷന് പുറത്തേക്ക് മാറ്റുക.
• പ്രോഗ്രാമിംഗിൽ idempotency എന്നാൽ എന്താണ്? — ആദ്യത്തെ പ്രയോഗത്തിന് ശേഷം ഫലത്തിൽ മാറ്റമൊന്നും വരുത്താതെ ഒരു ഫംഗ്ഷൻ ഒന്നിലധികം തവണ കോൾ ചെയ്യാൻ സാധിക്കും എന്നതാണ് Idempotency എന്നത് കൊണ്ട് അർത്ഥമാക്കുന്നത്.
• എന്താണ് NestJS? — കാര്യക്ഷമവും സ്കേലബിളും ആയ Node.js സെർവർ-സൈഡ് ആപ്ലിക്കേഷനുകൾ നിർമ്മിക്കുന്നതിനുള്ള ഒരു ഫ്രെയിംവർക്കാണ് NestJS.
• എന്റെ HTTP എൻഡ്‌പോയിന്റുകൾ ഞാൻ എങ്ങനെ സുരക്ഷിതമാക്കും? — റിക്വസ്റ്റുകൾ സാധൂകരിക്കുന്നതിന് shared secrets അല്ലെങ്കിൽ tokens പോലുള്ള authentication രീതികൾ ഉപയോഗിക്കുക.

ടാഗുകൾ

#cron #nestjs #microservices #scheduling #softwareengineering #dataintegrity #cloudcomputing #distributedsystems