ڈسٹریبیوٹڈ جاب شیڈولنگ کے لیے PostgreSQL Advisory Locks

صرف جاب شیڈولنگ کے لیے اپنے اسٹیک میں Redis یا SQS شامل کرنا بند کریں۔

اس کے بجائے آپ PostgreSQL advisory locks استعمال کر سکتے ہیں۔ یہ طریقہ نئے انفراسٹرکچر کی ضرورت کو ختم کر دیتا ہے۔

میرے تجربات میں، یہ سیٹ اپ ایک ہی ڈیٹا بیس انسٹنس پر فی منٹ 10,000 جابز کو سنبھال سکتا ہے۔ یہ اکثر لیٹنسی (latency) کے معاملے میں Redis سے بہتر کارکردگی دکھاتا ہے کیونکہ آپ کے ورکرز کے پاس پہلے سے ہی ڈیٹا بیس کنکشنز موجود ہوتے ہیں۔ اس طرح آپ ایک اضافی نیٹ ورک ہاپ (network hop) سے بچ جاتے ہیں۔

اسے کیسے نافذ کریں:

• جابز کے دعوے (claiming) کے لیے pg_try_advisory_xact_lock استعمال کریں۔ • رو کنٹینشن (row contention) کو سنبھالنے کے لیے FOR UPDATE SKIP LOCKED استعمال کریں۔ • لاک لیکس (lock leaks) سے بچنے کے لیے ٹرانزیکشنل ورژن (transactional variant) استعمال کریں۔

ٹرانزیکشنل لاکس کیوں اہم ہیں:

ٹرانزیکشنل لاکس خود بخود ریلیز ہو جاتے ہیں جب کوئی ٹرانزیکشن کمٹ (commit) یا رول بیک (rollback) ہوتی ہے۔ یہ آپ کی ایپلی کیشن کریش ہونے کی صورت میں یتیم لاکس (orphaned locks) کو روکتا ہے۔ یہ ٹرانزیکشن موڈ میں PgBouncer کے ساتھ بھی محفوظ طریقے سے کام کرتا ہے۔

اگر آپ PgBouncer استعمال کرتے ہیں تو سیشن لاکس (session locks) سے بچیں۔ PgBouncer ٹرانزیکشنز کے درمیان کنکشنز کو دوبارہ تفویض (reassign) کرتا ہے۔ اس سے سیشن لیول کے لاکس ٹوٹ جاتے ہیں اور خاموش ناکامیاں (silent failures) پیدا ہوتی ہیں۔

اگر آپ کو سیشن لاکس کی ضرورت ہے، تو اپنے ورکرز کے لیے ایک الگ کنکشن پول بنائیں۔ ویب ٹریفک اور جاب ورکر ٹریفک کو ایک ہی پول میں مکس نہ کریں۔

کیز (keys) کے ساتھ اسکیلنگ:

Advisory locks ایک bigint یا دو انٹیجرز استعمال کرتے ہیں۔ دو انٹیجرز کا استعمال قدرتی نیم اسپیسنگ (namespacing) فراہم کرتا ہے۔ اگر آپ ٹیکسٹ کیز کو bigint میں ہیش (hash) کرتے ہیں، تو کولیژنز (collisions) کا خیال رکھیں۔ جب تک آپ 100,000 منفرد لاک آئی ڈیز تک نہیں پہنچتے، کولیژنز کم رہتے ہیں۔ اس سے آگے، محفوظ رہنے کے لیے دو انٹیجرز والا فارم استعمال کریں۔

توازن (The Tradeoff):

• Advisory locks سادگی اور کم آپریشنل لاگت کے معاملے میں بہتر ہیں۔ • Redis خام تھرو پٹ (raw throughput) اور ہوریزنٹل اسکیلنگ (horizontal scaling) میں بہتر ہے۔

زیادہ تر ٹیموں کو فی منٹ 10,000 سے زیادہ جابز کی ضرورت نہیں ہوتی۔ اگر آپ اس حد سے نیچے ہیں، تو PostgreSQL ہی استعمال کریں۔ یہ آپ کے آرکیٹیکچر کو صاف ستھرا اور اخراجات کو کم رکھتا ہے۔

ماخذ: https://dev.to/software_mvp-factory/postgresql-advisory-locks-for-distributed-job-scheduling-15kp