کئی خطوں میں تحریر: تبدیلی دراصل کہاں کی تصدیق ہوتی ہے؟
روٹنگ درخواست کو ایک خطے تک پہنچاتی ہے؛ تحریر کو جوہری صرف لین دین کی حد بناتی ہے۔ انویریئنٹ کا نام دیں، مالک منتخب کریں، پھر اسی کے گرد دوبارہ کوشش کی تشکیل کریں۔
دو خطوں میں دو ایپلیکیشن سرور، VPN کے ذریعے لکھنے والا ایک کلائنٹ، اور ایک سوال جو کسی نے نہیں لکھا: کون سا جزو طے کرتا ہے کہ تحریر ہو گئی؟ روٹنگ درخواست کو ایک عمل تک پہنچاتی ہے۔ لین دین کی حد طے کرتی ہے کہ تبدیلی کب پائیدار اور نظر آنے والی بنتی ہے۔ یہ مختلف نظاموں کے مختلف کام ہیں، اور ان کے درمیان خلا وہ جگہ ہے جہاں کئی خطوں کی تحریر کی زیادہ تر خرابیاں رہتی ہیں۔
نقشے سے نہیں، کاروباری اصول سے شروع کریں
جغرافیے کے بجائے کاروباری اصول کے بارے میں ایک جملے سے شروع کریں: کون سی خواندگیاں اور تحریریں مل کر کامیاب ہونی چاہئیں، اور اس دوران کون سی ہم وقت تبدیلیاں ناممکن ہونی چاہئیں۔ اسٹاک کی بکنگ کے لیے اس کا مطلب یہ ہے کہ اسٹاک کی جانچ اور بکنگ یا دونوں نافذ ہوں یا کوئی نہیں، اور درمیان میں کوئی دوسرا آرڈر وہی اکائی استعمال نہ کر سکے۔
| Requirement | What satisfies it | What does not |
|---|---|---|
| All-or-nothing application | A transaction inside one owning system | A VPN path between regions |
| No double spend | Isolation strong enough to exclude the conflict | Atomicity alone |
| Survive a region loss | Replication the database itself documents | Two independent databases behind one client |
بالکل وہی درمیانی سطر ہے جسے ٹیمیں چھوڑ دیتی ہیں۔ کافی الگ تھلگ کے بغیر جوہریت دو لین دین کو الگ الگ درست طریقے سے تصدیق ہونے دیتی ہے اور پھر بھی ایسی حالت پیدا کرتی ہے جسے کاروبار ناممکن سمجھتا ہے، اور بعد میں کوئی دوبارہ کوشش منطق اسے درست نہیں کرتی۔
ایک مستند حد دو علاقائی سروروں کو شکست دیتی ہے
علاقائی ایپلیکیشن سرور جہاں ہیں وہیں رہ سکتے ہیں، بشرطیکہ وہ عمل کو ایسی خدمت کے سپرد کریں جو اسے ایک معاون لین دین کی حد کے اندر انجام دے۔ ایپلیکیشن کی تہہ نیت کی روٹر بن جاتی ہے؛ ڈیٹا کی تہہ حقیقت کی مالک ہوتی ہے۔
اس حد کو مختصر رکھیں اور اس ڈیٹا کے قریب رکھیں جسے یہ چھوتی ہے۔ ایسا لین دین جو اس وقت کھلا رکھا جائے جب کوئی انسان کسی اشارے کا جواب دے رہا ہو، یا جب کوئی کال دو خطوں کو عبور کر رہی ہو، اپنا وقت تالے تھامنے میں گزارتا ہے اور اس بات کا امکان بڑھاتا ہے کہ اس کے پیچھے کوئی اور چیز وقت سے تجاوز کر جائے۔ وہ ناکامی ڈیٹا بیس کے مسئلے جیسی لگتی ہے اور دراصل ایسا بھیس بدھی ڈیزائن کا مسئلہ ہے۔ فیصلے کو ڈیٹا کی تہہ میں منتقل کرنا عام طور پر اسے مکمل طور پر ختم کر دیتا ہے۔
BEGIN;
UPDATE inventory SET reserved = reserved + 1
WHERE sku = 'A-100' AND available >= 1;
INSERT INTO reservation (sku, order_id) VALUES ('A-100', 'ord-9f');
COMMIT;اس خاکے کو حد کے طور پر پڑھیں، کارکردگی کی سفارش کے طور پر نہیں۔ بات یہ ہے کہ جانچ اور اندراج ایک ہی کمٹ بانٹتے ہیں، اس لیے ہم وقت آرڈر یا تو اسٹاک استعمال شدہ دیکھتا ہے یا بالکل نہیں دیکھتا۔
نقل شدہ ڈیٹا بیس کیا دیتا ہے اور کیا نہیں دیتا
نقل شدہ ڈیٹا بیس وسیع تر حد فراہم کر سکتا ہے جب اس کا اپنا لین دین ماڈل اس کی تائید کرے۔ Spanner ایک ہی ڈیٹا بیس کے اندر جدولوں میں جوہری پڑھنے-لکھنے کے لین دین کی دستاویز کرتا ہے، متعین الگ تھلگ اور دوبارہ کوشش کے رویے کے ساتھ۔ یہ ایسی ضمانت ہے جسے آپ پڑھتے، جانچتے اور دانستہ طور پر اس پر بھروسا کرتے ہیں۔
یہ بھی ایسی ضمانت ہے جو مصنوعات سے آتی ہے، راستے سے نہیں۔ خطوں کے درمیان VPN اس بات کو بدلتا ہے کہ پیکٹ کیسے سفر کرتے ہیں اور ناکامیاں کیسے ظاہر ہوتی ہیں۔ سرنگ کتنی ہی صحت مند نظر آئے، یہ لین دین کی حد میں ایک سطر بھی اضافہ نہیں کرتا۔ دونوں کو ملانا ایسی تعمیرات پیدا کرتا ہے جہاں ہر جزو اپنی جانچ پاس کرتا ہے اور ڈیٹا پھر بھی نہیں ملتا۔
دو ڈیٹا بیس ایک نظام نہیں بنتے
آزادانہ طور پر سنبھالے جانے والے دو ڈیٹا بیس صرف اس لیے مشترکہ لین دین مینیجر حاصل نہیں کرتے کہ کلائنٹ دونوں تک پہنچ سکتے ہیں۔ اگر کاروبار کو واقعی اس جوڑے پر جوہری عہد کی ضرورت ہو، تو ہم آہنگی کا طریقہ، شرکا اور بحالی کا عمل سب کو مفروضہ سمجھنے کے بجائے منتخب اور اہل کیا جانا چاہیے۔
اس لمحے کا سوچیں جب کام تیار ہونے کے بعد کوئی شریک یا ربط غائب ہو جائے۔ معاون تقسیم شدہ تصدیق ایسی غیر یقینی حالت چھوڑ سکتی ہے جس کے لیے بحالی کا طریقہ کار اور انسانی فیصلہ درکار ہو، اور یہ اس بات کی کوئی ضمانت نہیں دیتی کہ ہر تقسیم میں ہر خطہ لکھنے کے قابل رہے گا۔
اگر اس کے بجائے غیر ہم وقت ہم آہنگی قابل قبول ہو، تو یہ واضح طور پر کہیں اور درمیانی کاروباری حالتیں اور مصالحت کے قواعد لکھیں۔ معاوضے کے ساتھ مقامی طور پر تصدیق شدہ مراحل کا سلسلہ جائز ڈیزائن ہے؛ یہ صرف کسی دوسرے نام کے تحت ایک جوہری لین دین نہیں ہے۔
پہلی رکاوٹ سے پہلے دوبارہ کوشش کی تشکیل کریں
عمل کی تصدیق کے بعد کلائنٹ جواب کھو سکتا ہے، اس لیے طلب کرنے والا وقت ختم ہونے کو ناکامی نہیں سمجھ سکتا۔ پائیدار درخواست کی شناخت محفوظ رکھیں اور تبدیلی دوبارہ آزمانے سے پہلے خدمت کا نتیجہ یا عدم تکرار کا طریقہ استعمال کریں، ورنہ دوبارہ کوشش دوسری تحریر بن جاتی ہے۔
خودکار لین دین کال بیکس قابلِ تکرار منسوخی کے بعد ایک سے زیادہ بار چل سکتے ہیں، جو انہیں ناقابلِ واپسی بیرونی اثرات کے لیے بری جگہ بناتا ہے۔ انہیں کال بیک سے باہر رکھیں جب تک کہ ورک فلو ان کے لیے واضح محفوظ پروٹوکول متعین نہ کرے۔ یہی احتیاط ہر اس چیز پر لاگو ہوتی ہے جو پیسہ خرچ کرے یا پیغام بھیجے۔ دوہرا چارج دوہری لاگ سطر سے کہیں زیادہ مشکل گفتگو ہے۔
قبولیت کو چار منظرنامے دوبارہ چلانے چاہئیں: ایک ہی سطر کے لیے دوڑتے دو کلائنٹ، وہ منسوخی جسے خدمت قابلِ تکرار کہتی ہے، وہ تصدیق جس کا جواب کبھی نہیں آتا، اور ایک خطے یا ان کے درمیان ربط کا نقصان۔ تصدیق شدہ کاروباری نتیجہ اور حل نہ ہونے والی حالتیں روٹنگ کے ڈیزائن کے ساتھ درج کریں، تاکہ کوئی نیٹ ورک کو ضمانت دینے والا جزو نہ سمجھے۔