🥇 تقسیم شدہ ایپلی کیشنز کے بلاکس کی تعمیر۔ دوسرا تخمینہ

اعلان

ساتھیوں، موسم گرما کے وسط میں میں قطار لگانے والے نظام کے ڈیزائن پر مضامین کی ایک اور سیریز جاری کرنے کا ارادہ رکھتا ہوں: "VTrade تجربہ" - تجارتی نظام کے لیے ایک فریم ورک لکھنے کی کوشش۔ یہ سلسلہ تبادلہ، نیلامی اور اسٹور بنانے کے نظریہ اور عمل کا جائزہ لے گا۔ مضمون کے آخر میں، میں آپ کو ان عنوانات کے لیے ووٹ دینے کی دعوت دیتا ہوں جو آپ کی سب سے زیادہ دلچسپی رکھتے ہیں۔

یہ Erlang/Elixir میں تقسیم شدہ رد عمل کی ایپلی کیشنز پر سیریز کا آخری مضمون ہے۔ میں پہلا مضمون آپ رد عمل کے فن تعمیر کی نظریاتی بنیادیں تلاش کر سکتے ہیں۔ دوسرا مضمون اس طرح کے نظاموں کی تعمیر کے بنیادی نمونوں اور طریقہ کار کی وضاحت کرتا ہے۔

آج ہم عام طور پر کوڈ بیس اور منصوبوں کی ترقی کے مسائل اٹھائیں گے۔

خدمات کی تنظیم

حقیقی زندگی میں، سروس تیار کرتے وقت، آپ کو اکثر ایک کنٹرولر میں متعدد تعامل کے نمونوں کو یکجا کرنا پڑتا ہے۔ مثال کے طور پر، صارف کی خدمت، جو پروجیکٹ صارف پروفائلز کے انتظام کے مسئلے کو حل کرتی ہے، کو req-resp کی درخواستوں کا جواب دینا چاہیے اور پب-سب کے ذریعے پروفائل اپ ڈیٹ کی اطلاع دینی چاہیے۔ یہ معاملہ بہت آسان ہے: پیغام رسانی کے پیچھے ایک کنٹرولر ہے جو سروس کی منطق کو نافذ کرتا ہے اور اپ ڈیٹس شائع کرتا ہے۔

صورتحال مزید پیچیدہ ہو جاتی ہے جب ہمیں غلطی برداشت کرنے والی تقسیم شدہ سروس کو نافذ کرنے کی ضرورت ہوتی ہے۔ آئیے تصور کریں کہ صارفین کے لیے تقاضے بدل گئے ہیں:

اب سروس کو 5 کلسٹر نوڈس پر درخواستوں پر کارروائی کرنی چاہیے،
پس منظر کی پروسیسنگ کے کاموں کو انجام دینے کے قابل ہو،
اور پروفائل اپ ڈیٹس کے لیے سبسکرپشن لسٹوں کو متحرک طور پر منظم کرنے کے قابل بھی ہوں۔

نوٹ: ہم مستقل اسٹوریج اور ڈیٹا کی نقل کے مسئلے پر غور نہیں کرتے ہیں۔ آئیے فرض کریں کہ یہ مسائل پہلے ہی حل ہو چکے ہیں اور سسٹم میں پہلے سے ہی ایک قابل اعتماد اور توسیع پذیر سٹوریج کی تہہ موجود ہے، اور ہینڈلرز کے پاس اس کے ساتھ بات چیت کرنے کا طریقہ کار موجود ہے۔

صارفین کی خدمت کی رسمی وضاحت مزید پیچیدہ ہو گئی ہے۔ پروگرامر کے نقطہ نظر سے، پیغام رسانی کے استعمال کی وجہ سے تبدیلیاں کم سے کم ہیں۔ پہلی ضرورت کو پورا کرنے کے لیے، ہمیں req-resp ایکسچینج پوائنٹ پر توازن کو ترتیب دینے کی ضرورت ہے۔

پس منظر کے کاموں کو پروسیس کرنے کی ضرورت اکثر ہوتی ہے۔ صارفین میں، یہ صارف کے دستاویزات کی جانچ پڑتال، ڈاؤن لوڈ کردہ ملٹی میڈیا پر کارروائی، یا سوشل میڈیا کے ساتھ ڈیٹا کو ہم آہنگ کرنا ہو سکتا ہے۔ نیٹ ورکس ان کاموں کو کسی نہ کسی طرح کلسٹر کے اندر تقسیم کرنے اور عملدرآمد کی پیشرفت کی نگرانی کرنے کی ضرورت ہے۔ لہذا، ہمارے پاس حل کے دو اختیارات ہیں: یا تو پچھلے مضمون سے ٹاسک ڈسٹری بیوشن ٹیمپلیٹ استعمال کریں، یا، اگر یہ مناسب نہیں ہے، تو ایک حسب ضرورت ٹاسک شیڈیولر لکھیں جو پروسیسرز کے پول کو ہماری ضرورت کے مطابق منظم کرے گا۔

پوائنٹ 3 کو پب سب ٹیمپلیٹ کی توسیع کی ضرورت ہے۔ اور عمل درآمد کے لیے، ایک پب-سب ایکسچینج پوائنٹ بنانے کے بعد، ہمیں اپنی سروس کے اندر اس پوائنٹ کے کنٹرولر کو بھی لانچ کرنا ہوگا۔ اس طرح، یہ ایسا ہی ہے جیسے ہم سبسکرپشن پر کارروائی کرنے کی منطق کو منتقل کر رہے ہیں اور پیغام رسانی کی تہہ سے ان سبسکرائب کو صارفین کے نفاذ میں لے جا رہے ہیں۔

نتیجے کے طور پر، مسئلہ کے گلنے سے پتہ چلتا ہے کہ ضروریات کو پورا کرنے کے لیے، ہمیں مختلف نوڈس پر سروس کی 5 مثالیں شروع کرنے اور ایک اضافی ادارہ بنانے کی ضرورت ہے - ایک پب-سب کنٹرولر، جو سبسکرپشن کے لیے ذمہ دار ہے۔
5 ہینڈلرز چلانے کے لیے، آپ کو سروس کوڈ تبدیل کرنے کی ضرورت نہیں ہے۔ صرف اضافی کارروائی ایکسچینج پوائنٹ پر توازن کے اصولوں کو ترتیب دینا ہے، جس کے بارے میں ہم تھوڑی دیر بعد بات کریں گے۔
ایک اضافی پیچیدگی بھی ہے: پب سب کنٹرولر اور کسٹم ٹاسک شیڈیولر کو ایک ہی کاپی میں کام کرنا چاہیے۔ ایک بار پھر، پیغام رسانی کی خدمت، ایک بنیادی کے طور پر، رہنما کے انتخاب کے لیے ایک طریقہ کار فراہم کرے۔

لیڈر کا انتخاب

تقسیم شدہ نظاموں میں، لیڈر کا انتخاب کسی ایک عمل کو مقرر کرنے کا طریقہ کار ہے جو کچھ بوجھ کی تقسیم شدہ پروسیسنگ کو شیڈول کرنے کے لیے ذمہ دار ہے۔

ایسے نظاموں میں جو سنٹرلائزیشن کا شکار نہیں ہیں، آفاقی اور اتفاق پر مبنی الگورتھم، جیسے کہ پیکسوس یا رافٹ، استعمال کیے جاتے ہیں۔
چونکہ پیغام رسانی ایک بروکر اور مرکزی عنصر ہے، اس لیے یہ تمام سروس کنٹرولرز - امیدوار لیڈروں کے بارے میں جانتا ہے۔ پیغام رسانی ووٹ ڈالے بغیر رہنما کا تقرر کر سکتی ہے۔

ایکسچینج پوائنٹ سے شروع ہونے اور منسلک ہونے کے بعد، تمام سروسز کو سسٹم کا پیغام موصول ہوتا ہے۔ #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}. اگر LeaderPid کے ساتھ موافق ہے pid موجودہ عمل، یہ رہنما، اور فہرست کے طور پر مقرر کیا جاتا ہے Servers تمام نوڈس اور ان کے پیرامیٹرز شامل ہیں۔
اس وقت ایک نیا نمودار ہوتا ہے اور ایک ورکنگ کلسٹر نوڈ منقطع ہوتا ہے، تمام سروس کنٹرولرز وصول کرتے ہیں #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} и #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} بالترتیب.

اس طرح، تمام اجزاء تمام تبدیلیوں سے واقف ہیں، اور کلسٹر میں کسی بھی وقت ایک لیڈر ہونے کی ضمانت ہے۔

بیچوان

پیچیدہ تقسیم شدہ پروسیسنگ کے عمل کو لاگو کرنے کے ساتھ ساتھ موجودہ فن تعمیر کو بہتر بنانے کے مسائل میں، بیچوانوں کا استعمال کرنا آسان ہے۔
سروس کوڈ کو تبدیل نہ کرنے اور حل کرنے کے لیے، مثال کے طور پر، اضافی پروسیسنگ، روٹنگ یا لاگنگ پیغامات کے مسائل، آپ سروس سے پہلے ایک پراکسی ہینڈلر کو فعال کر سکتے ہیں، جو تمام اضافی کام انجام دے گا۔

پب-سب آپٹیمائزیشن کی ایک بہترین مثال بزنس کور کے ساتھ ایک تقسیم شدہ ایپلی کیشن ہے جو اپ ڈیٹ کے واقعات، جیسے مارکیٹ میں قیمتوں میں تبدیلی، اور ایک رسائی لیئر - N سرور جو ویب کلائنٹس کے لیے ویب ساکٹ API فراہم کرتی ہے۔
اگر آپ فیصلہ کرتے ہیں، تو کسٹمر سروس اس طرح نظر آتی ہے:

کلائنٹ پلیٹ فارم کے ساتھ روابط قائم کرتا ہے۔ سرور کی طرف جو ٹریفک کو ختم کرتا ہے، اس کنکشن کی خدمت کے لیے ایک عمل شروع کیا جاتا ہے۔
سروس کے عمل کے تناظر میں، اجازت اور اپ ڈیٹس کی رکنیت ہوتی ہے۔ یہ عمل عنوانات کے لیے سبسکرائب کا طریقہ کہتا ہے۔
دانا میں ایک واقعہ پیدا ہونے کے بعد، یہ کنکشن کی خدمت کرنے والے عمل کو پہنچایا جاتا ہے۔

آئیے تصور کریں کہ ہمارے پاس "خبر" کے عنوان کے 50000 سبسکرائبرز ہیں۔ سبسکرائبرز کو 5 سرورز میں یکساں طور پر تقسیم کیا جاتا ہے۔ نتیجے کے طور پر، ایکسچینج پوائنٹ پر پہنچنے والی ہر اپ ڈیٹ کو 50000 بار نقل کیا جائے گا: ہر سرور پر 10000 بار، اس پر موجود صارفین کی تعداد کے مطابق۔ ایک بہت مؤثر سکیم نہیں ہے، ٹھیک ہے؟
صورت حال کو بہتر بنانے کے لیے، آئیے ایک ایسی پراکسی متعارف کراتے ہیں جس کا نام ایکسچینج پوائنٹ جیسا ہو۔ عالمی نام کے رجسٹرار کو اس قابل ہونا چاہیے کہ وہ نام کے ذریعے قریب ترین عمل کو واپس کر سکے، یہ ضروری ہے۔

آئیے اس پراکسی کو ایکسیس لیئر سرورز پر لانچ کریں، اور ویب ساکٹ اے پی آئی کو پیش کرنے والے ہمارے تمام عمل اس کو سبسکرائب کریں گے، نہ کہ کرنل میں اصل پب-سب ایکسچینج پوائنٹ پر۔ پراکسی صرف منفرد سبسکرپشن کی صورت میں بنیادی کو سبسکرائب کرتا ہے اور آنے والے پیغام کو اپنے تمام سبسکرائبرز کو نقل کرتا ہے۔
نتیجے کے طور پر، کرنل اور رسائی سرورز کے درمیان 5،50000 کے بجائے XNUMX پیغامات بھیجے جائیں گے۔

روٹنگ اور توازن

Req-Resp

موجودہ پیغام رسانی کے نفاذ میں، درخواست کی تقسیم کی 7 حکمت عملییں ہیں:

default. درخواست تمام کنٹرولرز کو بھیجی جاتی ہے۔
round-robin. درخواستوں کی گنتی کی جاتی ہے اور کنٹرولرز کے درمیان سائیکلی طور پر تقسیم کی جاتی ہے۔
consensus. خدمت کرنے والے کنٹرولرز لیڈروں اور غلاموں میں تقسیم ہیں۔ درخواستیں صرف لیڈر کو بھیجی جاتی ہیں۔
consensus & round-robin. گروپ کا ایک لیڈر ہے، لیکن درخواستیں تمام ممبران میں تقسیم کی جاتی ہیں۔
sticky. ہیش فنکشن کا حساب لگایا جاتا ہے اور ایک مخصوص ہینڈلر کو تفویض کیا جاتا ہے۔ اس دستخط کے ساتھ بعد کی درخواستیں اسی ہینڈلر کے پاس جاتی ہیں۔
sticky-fun. ایکسچینج پوائنٹ کو شروع کرتے وقت، ہیش کیلکولیشن فنکشن کے لیے sticky توازن
fun. چپچپا تفریح کی طرح، صرف آپ اسے اضافی طور پر ری ڈائریکٹ، مسترد یا پری پروسیس کر سکتے ہیں۔

تقسیم کی حکمت عملی تب سیٹ کی جاتی ہے جب ایکسچینج پوائنٹ شروع کیا جاتا ہے۔

توازن کے علاوہ، پیغام رسانی آپ کو اداروں کو ٹیگ کرنے کی اجازت دیتی ہے۔ آئیے سسٹم میں ٹیگز کی اقسام کو دیکھتے ہیں:

کنکشن ٹیگ۔ آپ کو یہ سمجھنے کی اجازت دیتا ہے کہ واقعات کس تعلق سے آئے۔ استعمال کیا جاتا ہے جب ایک کنٹرولر عمل ایک ہی ایکسچینج پوائنٹ سے جڑتا ہے، لیکن مختلف روٹنگ کیز کے ساتھ۔
سروس ٹیگ۔ آپ کو ایک سروس کے لیے ہینڈلرز کو گروپس میں جوڑنے اور روٹنگ اور توازن کی صلاحیتوں کو بڑھانے کی اجازت دیتا ہے۔ req-resp پیٹرن کے لیے، روٹنگ لکیری ہے۔ ہم ایکسچینج پوائنٹ پر ایک درخواست بھیجتے ہیں، پھر یہ اسے سروس پر بھیج دیتا ہے۔ لیکن اگر ہمیں ہینڈلرز کو منطقی گروپوں میں تقسیم کرنے کی ضرورت ہے، تو اسپلٹنگ ٹیگز کا استعمال کرتے ہوئے کی جاتی ہے۔ ٹیگ کی وضاحت کرتے وقت، درخواست کنٹرولرز کے ایک مخصوص گروپ کو بھیجی جائے گی۔
ٹیگ کی درخواست کریں۔ آپ کو جوابات کے درمیان فرق کرنے کی اجازت دیتا ہے۔ چونکہ ہمارا نظام متضاد ہے، سروس کے جوابات پر کارروائی کرنے کے لیے ہمیں درخواست بھیجتے وقت RequestTag کی وضاحت کرنے کے قابل ہونا چاہیے۔ اس سے ہم سمجھ سکیں گے کہ ہمارے پاس کس درخواست کا جواب آیا۔

پب ذیلی

پب سب کے لیے سب کچھ تھوڑا آسان ہے۔ ہمارے پاس ایک تبادلہ نقطہ ہے جس پر پیغامات شائع کیے جاتے ہیں۔ ایکسچینج پوائنٹ ان سبسکرائبرز کے درمیان پیغامات تقسیم کرتا ہے جنہوں نے اپنی ضرورت کی روٹنگ کیز کو سبسکرائب کیا ہے (ہم کہہ سکتے ہیں کہ یہ عنوانات کے مطابق ہے)۔

توسیع پذیری اور غلطی کی رواداری

مجموعی طور پر نظام کی توسیع پذیری نظام کی تہوں اور اجزاء کی توسیع پذیری کی ڈگری پر منحصر ہے:

اس سروس کے لیے ہینڈلرز کے ساتھ کلسٹر میں اضافی نوڈس شامل کر کے خدمات کی پیمائش کی جاتی ہے۔ آزمائشی آپریشن کے دوران، آپ بہترین توازن کی پالیسی کا انتخاب کر سکتے ہیں۔
خود ایک علیحدہ کلسٹر کے اندر پیغام رسانی کی خدمت کو عام طور پر یا تو خاص طور پر بھری ہوئی ایکسچینج پوائنٹس کو الگ کلسٹر نوڈس میں منتقل کرکے، یا کلسٹر کے خاص طور پر بھری ہوئی جگہوں پر پراکسی پروسیسز شامل کرکے اسکیل کیا جاتا ہے۔
ایک خصوصیت کے طور پر پورے نظام کی توسیع پذیری کا انحصار فن تعمیر کی لچک اور انفرادی کلسٹرز کو ایک مشترکہ منطقی وجود میں جوڑنے کی صلاحیت پر ہے۔

کسی پروجیکٹ کی کامیابی کا انحصار اکثر اسکیلنگ کی سادگی اور رفتار پر ہوتا ہے۔ اس کے موجودہ ورژن میں پیغام رسانی ایپلی کیشن کے ساتھ ساتھ بڑھتی ہے۔ یہاں تک کہ اگر ہمارے پاس 50-60 مشینوں کے کلسٹر کی کمی ہے تو ہم وفاق کا سہارا لے سکتے ہیں۔ بدقسمتی سے وفاق کا موضوع اس مضمون کے دائرہ کار سے باہر ہے۔

بکنگ

لوڈ بیلنسنگ کا تجزیہ کرتے وقت، ہم نے پہلے ہی سروس کنٹرولرز کی فالتو پن پر بات کی ہے۔ تاہم، پیغام رسانی کو بھی محفوظ رکھنا ضروری ہے۔ نوڈ یا مشین کریش ہونے کی صورت میں، پیغام رسانی خود بخود ٹھیک ہو جانا چاہیے، اور کم سے کم وقت میں۔

اپنے پروجیکٹس میں میں اضافی نوڈس استعمال کرتا ہوں جو گرنے کی صورت میں بوجھ اٹھا لیتے ہیں۔ ایرلانگ میں OTP ایپلیکیشنز کے لیے معیاری تقسیم شدہ وضع کا نفاذ ہے۔ ڈسٹری بیوٹڈ موڈ ناکامی کی صورت میں پہلے سے شروع کردہ کسی اور نوڈ پر ناکام ایپلیکیشن لانچ کر کے ریکوری کرتا ہے۔ یہ عمل شفاف ہے؛ ناکامی کے بعد، ایپلیکیشن خود بخود فیل اوور نوڈ پر چلی جاتی ہے۔ آپ اس فعالیت کے بارے میں مزید پڑھ سکتے ہیں۔ یہاں.

کارکردگی

آئیے کم از کم rabbitmq کی کارکردگی اور اپنی مرضی کے مطابق پیغام رسانی کا موازنہ کرنے کی کوشش کریں۔
میں نے ڈھونڈا سرکاری نتائج اوپن اسٹیک ٹیم سے rabbitmq ٹیسٹنگ۔

پیراگراف 6.14.1.2.1.2.2 میں۔ اصل دستاویز RPC CAST کا نتیجہ ظاہر کرتی ہے:

ہم OS کرنل یا erlang VM میں پہلے سے کوئی اضافی سیٹنگ نہیں کریں گے۔ ٹیسٹ کی شرائط:

erl opts: +A1 +sbtu۔
واحد ایرلانگ نوڈ کے اندر ٹیسٹ موبائل ورژن میں پرانے i7 والے لیپ ٹاپ پر چلایا جاتا ہے۔
کلسٹر ٹیسٹ 10G نیٹ ورک والے سرورز پر کیے جاتے ہیں۔
کوڈ ڈاکر کنٹینرز میں چلتا ہے۔ نیٹ موڈ میں نیٹ ورک۔

ٹیسٹ کوڈ:

req_resp_bench(_) ->
  W = perftest:comprehensive(10000,
    fun() ->
      messaging:request(?EXCHANGE, default, ping, self()),
      receive
        #'$msg'{message = pong} -> ok
      after 5000 ->
        throw(timeout)
      end
    end
  ),
  true = lists:any(fun(E) -> E >= 30000 end, W),
  ok.

منظر نامہ 1: یہ ٹیسٹ ایک پرانے i7 موبائل ورژن والے لیپ ٹاپ پر چلایا جاتا ہے۔ ٹیسٹ، میسجنگ اور سروس کو ایک ڈوکر کنٹینر میں ایک نوڈ پر عمل میں لایا جاتا ہے:

Sequential 10000 cycles in ~0 seconds (26987 cycles/s)
Sequential 20000 cycles in ~1 seconds (26915 cycles/s)
Sequential 100000 cycles in ~4 seconds (26957 cycles/s)
Parallel 2 100000 cycles in ~2 seconds (44240 cycles/s)
Parallel 4 100000 cycles in ~2 seconds (53459 cycles/s)
Parallel 10 100000 cycles in ~2 seconds (52283 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (49317 cycles/s)

منظر نامہ 2: ڈوکر (NAT) کے تحت مختلف مشینوں پر چلنے والے 3 نوڈس۔

Sequential 10000 cycles in ~1 seconds (8684 cycles/s)
Sequential 20000 cycles in ~2 seconds (8424 cycles/s)
Sequential 100000 cycles in ~12 seconds (8655 cycles/s)
Parallel 2 100000 cycles in ~7 seconds (15160 cycles/s)
Parallel 4 100000 cycles in ~5 seconds (19133 cycles/s)
Parallel 10 100000 cycles in ~4 seconds (24399 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (34517 cycles/s)

تمام معاملات میں، CPU کا استعمال 250% سے زیادہ نہیں ہوا

کے نتائج

مجھے امید ہے کہ یہ سائیکل دماغی ڈمپ کی طرح نہیں لگتا ہے اور میرا تجربہ تقسیم شدہ نظاموں کے محققین اور پریکٹیشنرز دونوں کے لیے حقیقی فائدہ مند ہوگا جو اپنے کاروباری نظاموں کے لیے تقسیم شدہ فن تعمیرات کی تعمیر کے بالکل آغاز میں ہیں اور دلچسپی کے ساتھ Erlang/Elixir کو دیکھ رہے ہیں۔ ، لیکن شک ہے کہ کیا یہ قابل ہے ...

تصویر @chuttersnap

سروے میں صرف رجسٹرڈ صارفین ہی حصہ لے سکتے ہیں۔ سائن ان، برائے مہربانی.

VTrade تجرباتی سلسلے کے حصے کے طور پر مجھے کن موضوعات کو مزید تفصیل سے احاطہ کرنا چاہیے؟

تھیوری: مارکیٹس، آرڈرز اور ان کا ٹائمنگ: DAY، GTD، GTC، IOC، FOK، MOO، MOC، LOO، LOC
احکامات کی کتاب۔ گروپ بندی کے ساتھ کتاب کو نافذ کرنے کا نظریہ اور عمل
ٹریڈنگ کا تصور: ٹِکس، بارز، ریزولوشنز۔ ذخیرہ کرنے کا طریقہ اور گلو کیسے کرنا ہے۔
واپس دفتر. منصوبہ بندی اور ترقی۔ ملازمین کی نگرانی اور واقعہ کی تحقیقات
API آئیے معلوم کریں کہ کن انٹرفیسز کی ضرورت ہے اور انہیں کیسے نافذ کیا جائے۔
معلومات کا ذخیرہ: پوسٹگری ایس کیو ایل، ٹائم اسکیل، ٹریڈنگ سسٹم میں ٹرانٹول
تجارتی نظام میں رد عمل
دیگر کمنٹس میں لکھوں گا۔

6 صارفین نے ووٹ دیا۔ 4 صارفین غیر حاضر رہے۔

ماخذ: www.habr.com

تقسیم شدہ ایپلی کیشنز کے بلڈنگ بلاکس۔ دوسری قربت