డిస్ట్రిబ్యూటెడ్ జాబ్ షెడ్యూలింగ్ కోసం PostgreSQL అడ్వైజరీ లాక్స్

కేవలం జాబ్ షెడ్యూలింగ్ కోసం మీ స్టాక్‌కు Redis లేదా SQSలను జోడించడం ఆపండి.

దానికి బదులుగా మీరు PostgreSQL అడ్వైజరీ లాక్స్‌ను ఉపయోగించవచ్చు. ఈ విధానం వల్ల కొత్త ఇన్‌ఫ్రాస్ట్రక్చర్ అవసరం ఉండదు.

నా పరీక్షల ప్రకారం, ఈ సెటప్ ఒకే డేటాబేస్ ఇన్‌స్టెన్స్‌పై నిమిషానికి 10,000 జాబ్‌లను హ్యాండిల్ చేయగలదు. మీ వర్కర్లు ఇప్పటికే డేటాబేస్ కనెక్షన్‌లను కలిగి ఉండటం వల్ల, ఇది లేటెన్సీ (latency) విషయంలో తరచుగా Redis కంటే మెరుగ్గా ఉంటుంది. దీనివల్ల అదనపు నెట్‌వర్క్ హాప్ (network hop) అవసరం ఉండదు.

దీనిని ఎలా అమలు చేయాలి:

• జాబ్‌లను క్లెయిమ్ చేయడానికి pg_try_advisory_xact_lock ఉపయోగించండి. • రో కాంటెన్షన్‌ను (row contention) హ్యాండిల్ చేయడానికి FOR UPDATE SKIP LOCKED ఉపయోగించండి. • లాక్ లీక్స్ (lock leaks) కాకుండా ఉండటానికి ట్రాన్సాక్షనల్ వేరియంట్‌ను ఉపయోగించండి.

ట్రాన్సాక్షనల్ లాక్స్ ఎందుకు ముఖ్యమైనవి:

ట్రాన్సాక్షన్ కమిట్ అయినప్పుడు లేదా రోల్‌బ్యాక్ అయినప్పుడు ట్రాన్సాక్షనల్ లాక్స్ ఆటోమేటిక్‌గా విడుదలవుతాయి. దీనివల్ల మీ అప్లికేషన్ క్రాష్ అయినా 'ఆర్ఫన్డ్ లాక్స్' (orphaned locks) ఏర్పడవు. ఇది PgBouncer యొక్క ట్రాన్సాక్షన్ మోడ్‌లో కూడా సురక్షితంగా పనిచేస్తుంది.

మీరు PgBouncer ఉపయోగిస్తుంటే సెషన్ లాక్స్‌ను (session locks) నివారించండి. PgBouncer ట్రాన్సాక్షన్‌ల మధ్య కనెక్షన్‌లను తిరిగి కేటాయిస్తుంది (reassigns). ఇది సెషన్-లెవల్ లాక్స్‌ను విచ్ఛిన్నం చేసి, సైలెంట్ ఫెయిల్యూర్స్‌కు (silent failures) దారితీస్తుంది.

మీకు సెషన్ లాక్స్ అవసరమైతే, మీ వర్కర్ల కోసం ప్రత్యేకమైన కనెక్షన్ పూల్‌ను సృష్టించండి. వెబ్ ట్రాఫిక్ మరియు జాబ్ వర్కర్ ట్రాఫిక్‌ను ఒకే పూల్‌లో కలపకండి.

కీలతో స్కేలింగ్ (Scaling with keys):

అడ్వైజరీ లాక్స్ ఒక bigint లేదా రెండు ఇంటిజర్‌లను ఉపయోగిస్తాయి. రెండు ఇంటిజర్‌లను ఉపయోగించడం వల్ల సహజమైన నేమ్‌స్పేసింగ్ (namespacing) లభిస్తుంది. మీరు టెక్స్ట్ కీలను bigintగా హాష్ చేస్తే, కొలిజన్స్ (collisions) పట్ల జాగ్రత్తగా ఉండండి. 100,000 విభిన్న లాక్ ఐడిల వరకు కొలిజన్స్ తక్కువగా ఉంటాయి. అంతకంటే ఎక్కువ అవసరమైతే, సురక్షితంగా ఉండటానికి రెండు-ఇంటిజర్ ఫార్మ్‌ను ఉపయోగించండి.

లాభనష్టాల విశ్లేషణ (The Tradeoff):

• అడ్వైజరీ లాక్స్ సరళత మరియు తక్కువ నిర్వహణ ఖర్చు విషయంలో మెరుగ్గా ఉంటాయి. • Redis ముడి త్రూపుట్ (raw throughput) మరియు హారిజాంటల్ స్కేలింగ్ విషయంలో మెరుగ్గా ఉంటుంది.

చాలా టీమ్‌లకు నిమిషానికి 10,000 కంటే ఎక్కువ జాబ్‌లు అవసరం ఉండదు. మీరు ఆ పరిమితి కంటే తక్కువగా ఉంటే, PostgreSQLనే వాడండి. ఇది మీ ఆర్కిటెక్చర్‌ను క్లీన్‌గా మరియు ఖర్చులను తక్కువగా ఉంచుతుంది.

Source: https://dev.to/software_mvp-factory/postgresql-advisory-locks-for-distributed-job-scheduling-15kp