விநியோகிக்கப்பட்ட பணித் திட்டமிடலுக்கான (Distributed Job Scheduling) PostgreSQL Advisory Locks

பணித் திட்டமிடலுக்காக (job scheduling) மட்டும் உங்கள் தொழில்நுட்பத் தொகுப்பில் (stack) Redis அல்லது SQS-ஐச் சேர்ப்பதை நிறுத்துங்கள்.

அதற்குப் பதிலாக நீங்கள் PostgreSQL advisory locks-ஐப் பயன்படுத்தலாம். இந்த அணுகுமுறை புதிய உள்கட்டமைப்பின் (infrastructure) தேவையை நீக்குகிறது.

எனது சோதனைகளில், இந்த அமைப்பு ஒரு ஒற்றை தரவுத்தளத் தொகுப்பில் (single database instance) நிமிடத்திற்கு 10,000 பணிகளைக் கையாள்கிறது. உங்கள் பணியாளர்கள் (workers) ஏற்கனவே தரவுத்தள இணைப்புகளைக் கொண்டுள்ளதால், இது பெரும்பாலும் தாமதத்தில் (latency) Redis-ஐ விடச் சிறப்பாகச் செயல்படுகிறது. இதன் மூலம் கூடுதல் நெட்வொர்க் தாவலை (network hop) நீங்கள் தவிர்க்கலாம்.

இதை எவ்வாறு செயல்படுத்துவது:

• பணிகளை உரிமை கோர (job claiming) pg_try_advisory_xact_lock-ஐப் பயன்படுத்தவும். • வரிசை மோதல்களைக் (row contention) கையாள FOR UPDATE SKIP LOCKED-ஐப் பயன்படுத்தவும். • லாக் கசிவுகளைத் (lock leaks) தவிர்க்க பரிவர்த்தனை முறையிலான (transactional variant) வடிவத்தைப் பயன்படுத்தவும்.

பரிவர்த்தனை லாக் (transactional locks) ஏன் முக்கியமானது:

ஒரு பரிவர்த்தனை (transaction) முடிவடையும்போதோ (commit) அல்லது ரத்து செய்யப்படும்போதோ (rollback) பரிவர்த்தனை லாக் தானாகவே விடுவிக்கப்படும். இது உங்கள் பயன்பாடு செயலிழந்தால் (crash), அனாதையாக இருக்கும் லாக் (orphaned locks) உருவாவதைத் தடுக்கிறது. இது PgBouncer-ன் transaction mode-உடன் பாதுகாப்பாகச் செயல்படுகிறது.

நீங்கள் PgBouncer பயன்படுத்தினால், session locks-ஐத் தவிர்க்கவும். PgBouncer பரிவர்த்தனைகளுக்கு இடையே இணைப்புகளை மறுஒதுவாக்கம் (reassigns) செய்கிறது. இது session-level locks-ஐப் பாதித்து, அமைதியான தோல்விகளுக்கு (silent failures) வழிவகுக்கும்.

உங்களுக்கு session locks தேவைப்பட்டால், உங்கள் பணியாளர்களுக்காகத் தனி இணைப்புத் தொகுப்பை (connection pool) உருவாக்கவும். இணையப் போக்குவரத்து (web traffic) மற்றும் பணிப் பணியாளர் போக்குவரத்து (job worker traffic) ஆகிய இரண்டையும் ஒரே தொகுப்பில் கலக்க வேண்டாம்.

விசைகளைப் (keys) பயன்படுத்தி அளவிடுதல் (Scaling):

Advisory locks ஒரு bigint அல்லது இரண்டு முழு எண்களைப் (integers) பயன்படுத்துகின்றன. இரண்டு முழு எண்களைப் பயன்படுத்துவது இயற்கையான பெயரிடல் முறையை (namespacing) வழங்குகிறது. உரை விசைகளை (text keys) ஒரு bigint-ஆக மாற்றினால் (hash), மோதல்களைக் (collisions) கவனத்தில் கொள்ளவும். 100,000 தனித்துவமான லாக் ஐடிகளைத் (lock IDs) தாண்டும் வரை மோதல்கள் குறைவாகவே இருக்கும். அதற்கு மேல், பாதுகாப்பாக இருக்க இரண்டு முழு எண்களைக் கொண்ட வடிவத்தைப் பயன்படுத்தவும்.

சமநிலை (The Tradeoff):

• எளிமை மற்றும் குறைந்த செயல்பாட்டுச் செலவில் (operational cost) Advisory locks வெற்றி பெறுகின்றன. • அதிகத் திறன் (raw throughput) மற்றும் கிடைமட்ட அளவிடுதலில் (horizontal scaling) Redis வெற்றி பெறுகிறது.

பெரும்பாலான குழுக்களுக்கு நிமிடத்திற்கு 10,000 பணிகளுக்கு மேல் தேவைப்படுவதில்லை. நீங்கள் அந்த வரம்பிற்கு கீழே இருந்தால், PostgreSQL-ஐயே பயன்படுத்தவும். இது உங்கள் கட்டமைப்பை (architecture) சுத்தமாகவும், செலவுகளைக் குறைவாகவும் வைத்திருக்கும்.

ஆதாரம்: https://dev.to/software_mvp-factory/postgresql-advisory-locks-for-distributed-job-scheduling-15kp