د مسکو د تبادلې د سوداګرۍ او پاکولو سیسټم جوړښت ته وده ورکول. برخه 1

سلام و ټولو ته! زما نوم سرګي کوستانبایف دی، په تبادله کې زه د سوداګرۍ سیسټم اصلي ته وده ورکوم.

کله چې د هالیوډ فلمونه د نیویارک سټاک ایکسچینج وښیې، دا تل داسې ښکاري: د خلکو ګڼه ګوڼه، هرڅوک یو څه چیغې کوي، کاغذونه وهي، بشپړ ګډوډي پیښیږي. دا دلته هیڅکله د مسکو په تبادله کې ندي پیښ شوي ، ځکه چې سوداګرۍ له پیل څخه په بریښنایی ډول ترسره شوې او د دوه اصلي پلیټ فارمونو پراساس ده - سپیکٹرا (فاریکس بازار) او ASTS (بهرنۍ تبادله ، سټاک او د پیسو بازار). او نن زه غواړم د ASTS سوداګرۍ او پاکولو سیسټم د جوړښت د ارتقا په اړه خبرې وکړم، د مختلفو حلونو او موندنو په اړه. کیسه به اوږده وي، نو باید په دوو برخو وویشلم.

موږ په نړۍ کې یو له څو تبادلو څخه یو چې د ټولو ټولګیو شتمنیو تجارت کوي او د تبادلې بشپړ خدمتونه وړاندې کوي. د مثال په توګه، تیر کال موږ د بانډ سوداګرۍ حجم له مخې په نړۍ کې دوهم ځای درلود، د ټولو سټاک ایکسچینجونو په منځ کې 25 ځای، د عامه تبادلې په منځ کې د پانګونې په برخه کې 13 ځای.

د مسلکي سوداګرۍ برخه اخیستونکو لپاره، د غبرګون وخت، د وخت د ویش ثبات (جیټ) او د ټول کمپلیکس اعتبار په څیر پیرامیټونه مهم دي. موږ اوس مهال هره ورځ لسګونه ملیون لیږدونه پروسس کوو. د سیسټم کرنل لخوا د هرې لیږد پروسس لسګونه مایکرو ثانیې وخت نیسي. البته، د نوي کال په ماښام یا د لټون انجنونو کې ګرځنده چلونکي پخپله زموږ په پرتله لوړ کاري بار لري، مګر د کار بار په شرایطو کې، د پورته ذکر شویو ځانګړتیاو سره یوځای، لږ شمیر زموږ سره پرتله کولی شي، داسې ښکاري. په ورته وخت کې، دا زموږ لپاره مهم دی چې سیسټم د یوې ثانیې لپاره سست نه کوي، په بشپړ ډول په ثبات سره کار کوي، او ټول کاروونکي په مساوي پښو دي.

لږ تاریخ

په 1994 کې، د آسټرالیا ASTS سیسټم د مسکو انټربینک اسعارو تبادله (MICEX) کې پیل شو، او له هغې شیبې څخه د روسیې د بریښنایی سوداګرۍ تاریخ شمیرل کیدی شي. په 1998 کې، د تبادلې جوړښت د انټرنیټ سوداګرۍ معرفي کولو لپاره عصري شو. له هغه وخت راهیسې، په ټولو سیسټمونو او فرعي سیسټمونو کې د نوي حلونو او معماري بدلونونو پلي کولو سرعت یوازې سرعت ترلاسه کوي.

په دې کلونو کې، د تبادلې سیسټم د لوړ پای هارډویر - خورا معتبر HP سوپرډوم 9000 سرورونو باندې کار کاوه (په دې باندې جوړ شوی. PA-RISC)، په کوم کې چې په بشپړ ډول هر څه نقل شوي وو: ان پټ/آؤټ پټ فرعي سیسټمونه، شبکه، RAM (په حقیقت کې، د RAID RAM شتون درلود)، پروسیسرونه (ګرم بدلیدونکي). دا ممکنه وه چې د ماشین بندولو پرته د سرور کوم برخې بدل کړئ. موږ په دې وسیلو تکیه وکړه او دوی یې په حقیقت کې ناکام خوندي وګڼل. عملیاتي سیسټم د یونیکس په څیر HP UX سیسټم و.

مګر د 2010 راهیسې، یوه پدیده راڅرګنده شوې چې د لوړې فریکونسۍ سوداګرۍ (HFT) په نوم یادیږي، یا د لوړې فریکونسۍ سوداګرۍ - په ساده ډول د سټاک ایکسچینج روبوټونه. یوازې په 2,5 کلونو کې، زموږ په سرورونو بار 140 ځله زیات شوی.

دا ناشونې وه چې د زاړه معمارۍ او تجهیزاتو سره دا ډول بار ودرول شي. دا اړینه وه چې یو څه تطبیق شي.

پیل

د تبادلې سیسټم ته غوښتنې په دوه ډوله ویشل کیدی شي:

• راکړه ورکړه. که تاسو غواړئ ډالر، ونډې یا بل څه واخلئ، تاسو د سوداګرۍ سیسټم ته لیږد لیږئ او د بریالیتوب په اړه ځواب ترلاسه کوئ.
• د معلوماتو غوښتنه. که تاسو غواړئ اوسنی نرخ ومومئ، د امر کتاب یا شاخصونه وګورئ، بیا د معلوماتو غوښتنې واستوئ.

په سکیماتیک ډول، د سیسټم اصلي برخه په دریو کچو ویشل کیدی شي:

• د پیرودونکي کچه، په کوم کې چې بروکران او پیرودونکي کار کوي. دوی ټول د لاسرسي سرورونو سره اړیکه لري.
• د ګیټ وے سرورونه د کیچ کولو سرورونه دي چې په محلي ډول د ټولو معلوماتو غوښتنې پروسس کوي. ایا تاسو غواړئ پوه شئ چې د Sberbank ونډو اوس مهال په کوم قیمت تجارت کیږي؟ غوښتنه د لاسرسي سرور ته ځي.
• مګر که تاسو غواړئ ونډې واخلئ، نو بیا غوښتنه مرکزي سرور (تجارتي انجن) ته ځي. د هر ډول بازار لپاره یو ورته سرور شتون لري، دوی مهم رول لوبوي، دا د دوی لپاره دی چې موږ دا سیسټم رامینځته کړی.

د سوداګرۍ سیسټم اصلي د حافظې په حافظه کې یو هوښیار ډیټابیس دی چیرې چې ټولې معاملې د تبادلې معاملې دي. اډه په C کې لیکل شوې وه، یوازینۍ بهرنۍ انحصار د libc کتابتون و او په هیڅ ډول متحرک حافظه تخصیص نه و. د پروسس کولو وخت کمولو لپاره، سیسټم د صفونو جامد سیټ سره او د جامد ډیټا ځای په ځای کولو سره پیل کیږي: لومړی، د نن ورځې ټول معلومات په حافظه کې بار شوي، او نور ډیسک ته لاسرسی نه ترسره کیږي، ټول کار یوازې په حافظه کې ترسره کیږي. کله چې سیسټم پیل شي، د حوالې ټول معلومات لا دمخه ترتیب شوي، نو لټون خورا اغیزمن کار کوي او د چلولو په وخت کې لږ وخت نیسي. ټول جدولونه د مداخلې لیستونو او ونو سره د متحرک ډیټا جوړښتونو لپاره جوړ شوي ترڅو د چلولو په وخت کې د حافظې تخصیص ته اړتیا ونلري.

راځئ چې په لنډه توګه زموږ د سوداګرۍ او پاکولو سیسټم پراختیا تاریخ ته لاړ شو.
د سوداګرۍ او پاکولو سیسټم جوړښت لومړۍ نسخه د یونکس تعامل په نوم جوړه شوې وه: ګډ حافظه ، سیمفورز او کتارونه کارول شوي ، او هره پروسه یو واحد تار لري. دا طریقه د 1990 لسیزې په لومړیو کې پراخه وه.

د سیسټم لومړۍ نسخه د ګیټ وے دوه کچې او د سوداګرۍ سیسټم مرکزي سرور درلود. د کار جریان داسې وو:

• پیرودونکی یوه غوښتنه لیږي، کوم چې ګیټ وے ته رسیږي. دا د فارمیټ اعتبار چک کوي (مګر پخپله ډاټا نه) او غلط لیږدونه ردوي.
• که د معلوماتو غوښتنه لیږل شوې وي، دا په محلي توګه اجرا کیږي؛ که موږ د راکړې ورکړې په اړه خبرې کوو، نو دا مرکزي سرور ته لیږدول کیږي.
• د سوداګرۍ انجن بیا لیږد پروسس کوي، ځایی حافظه بدلوي، او لیږد ته ځواب لیږي او پخپله لیږد د جلا نقل انجن په کارولو سره د نقل لپاره.
• ګیټ وے د مرکزي نوډ څخه ځواب ترلاسه کوي او پیرودونکي ته یې لیږي.
• د یو څه وخت وروسته، ګیټس د نقل میکانیزم له لارې لیږد ترلاسه کوي، او دا ځل دا په محلي توګه اجرا کوي، د دې ډاټا جوړښتونه بدلوي ترڅو د راتلونکو معلوماتو غوښتنې وروستي ډاټا ښکاره کړي.

په حقیقت کې، دا د نقل کولو ماډل تشریح کوي په کوم کې چې ګیټ وے په بشپړ ډول د سوداګرۍ سیسټم کې ترسره شوي عملونه تکرار کړي. یو جلا نقل چینل ډاډ ترلاسه کړ چې لیږدونه په ورته ترتیب کې د ډیری لاسرسي نوډونو کې اجرا شوي.

څرنګه چې کوډ واحد تار شوی و، د پروسې فورکس سره یو کلاسیک سکیم د ډیری پیرودونکو خدمت کولو لپاره کارول کیده. په هرصورت، دا ډیره ګرانه وه چې د ټول ډیټابیس فورک ولګول شي، نو د لږ وزن خدماتو پروسې کارول شوي چې د TCP غونډو څخه پاکټونه راټول کړي او یو قطار (SystemV Message Queue) ته یې انتقال کړي. ګیټ وے او د سوداګرۍ انجن یوازې د دې کتار سره کار کاوه، د اجرا کولو لپاره له هغه ځایه لیږدونه اخلي. دا نور ممکنه نه وه چې دې ته ځواب واستوي، ځکه چې دا روښانه نه وه چې د کوم خدمت پروسه باید دا ولولي. نو موږ یو چال ته لاره هواره کړه: هر ټوخی شوي پروسې د ځان لپاره د ځواب کتار رامینځته کړی ، او کله چې غوښتنه راتلونکي کتار کې راشي ، نو د ځواب کتار لپاره ټاګ سمدلاسه دې ته اضافه شوی.

په دوامداره توګه د ډیټا لوی مقدار کاپي کول له قطار څخه قطار ته ستونزې رامینځته کوي ، په ځانګړي توګه د معلوماتو غوښتنو لپاره عادي. له همدې امله، موږ یو بل چل وکاراوه: د غبرګون کتار سربیره، هرې پروسې هم شریکه حافظه جوړه کړه (SystemV Shared Memory). کڅوړې پخپله په دې کې ځای پر ځای شوي، او یوازې یو ټاګ په کتار کې زیرمه شوی، یو چا ته اجازه ورکوي چې اصلي کڅوړه ومومي. دا د پروسیسر کیچ کې د معلوماتو ذخیره کولو کې مرسته کړې.

SystemV IPC کې د کتار حالت، حافظې، او سیمفور شیانو لیدلو لپاره اسانتیاوې شاملې دي. موږ دا په فعاله توګه وکاروو ترڅو پوه شو چې په سیسټم کې په یوه ځانګړي شیبه کې څه پیښیږي ، چیرې چې پاکټونه راټول شوي ، څه بلاک شوي ، او داسې نور.

لومړی عصري کول

له هرڅه دمخه ، موږ د واحد پروسې ګیټ ویز څخه خلاص شو. د دې مهم نیمګړتیا دا وه چې دا کولی شي د یو نقل لیږد یا د پیرودونکي څخه د معلوماتو غوښتنه اداره کړي. او لکه څنګه چې بار ډیریږي، ګیټ وے به د غوښتنو پروسس کولو لپاره ډیر وخت ونیسي او د نقل کولو جریان به پروسس کولو توان ونلري. سربیره پردې ، که چیرې پیرودونکي لیږد لیږلی وي ، نو تاسو یوازې اړتیا لرئ د دې اعتبار چیک کړئ او نور یې پریږدئ. له همدې امله، موږ د واحد ګیټ وے پروسه د څو برخو سره بدله کړه چې کولی شي په موازي توګه پرمخ بوځي: څو اړخیز معلومات او د راکړې ورکړې پروسې د یو بل څخه په خپلواکه توګه د ګډ حافظې ساحه کې د RW تالاشۍ په کارولو سره پرمخ ځي. او په ورته وخت کې موږ د لیږلو او نقل کولو پروسې معرفي کړې.

د لوړې فریکونسۍ سوداګرۍ اغیزه

د معمارۍ پورته نسخه تر 2010 پورې شتون درلود. په ورته وخت کې ، موږ نور د HP سوپرډوم سرورونو فعالیت څخه راضي نه یو. سربیره پردې، د PA-RISC جوړښت په حقیقت کې مړ شوی و؛ پلورونکي کوم مهم تازه معلومات وړاندې نه کړل. د پایلې په توګه، موږ د HP UX/PA RISC څخه لینکس/x86 ته حرکت پیل کړ. لیږد د لاسرسي سرورونو موافقت سره پیل شو.

ولې موږ بیا د معمارۍ بدلولو ته اړ شو؟ حقیقت دا دی چې د لوړې فریکونسۍ سوداګرۍ د سیسټم په کور کې د بار پروفایل د پام وړ بدل کړی.

راځئ چې ووایو چې موږ یو کوچنی لیږد لرو چې د پام وړ نرخ بدلون لامل شوی - یو څوک نیم ملیارد ډالر اخیستي. د څو ملی ثانیو وروسته، د بازار ټول ګډونوال دا خبر ورکوي او د سمون پیل کوي. په طبیعي توګه، غوښتنې په لوی کتار کې ولاړې دي، کوم چې سیسټم به پاکولو لپاره ډیر وخت ونیسي.

په دې 50 ms وقفه کې، اوسط سرعت په هره ثانیه کې شاوخوا 16 زره لیږدونه دي. که موږ کړکۍ 20 ms ته راټیټ کړو، موږ په هر ثانیه کې د 90 زره لیږدونو اوسط سرعت ترلاسه کوو، د 200 زره لیږدونو سره. په بل عبارت، بار د ناڅاپه درزونو سره ثابت نه دی. او د غوښتنو کتار باید تل په چټکۍ سره پروسس شي.

خو ولې په ټوله کې کتار دی؟ نو، زموږ په مثال کې، ډیری کاروونکو د نرخ بدلون لیدلی او د هغې مطابق یې لیږدونه لیږلي. دوی ګیټ وے ته راځي، دا دوی سریال کوي، یو ټاکلی ترتیب ترتیبوي او شبکې ته یې لیږي. روټرونه پاکټونه بدلوي او پر مخ وړي. د چا کڅوړه لومړی راغله ، دا معامله "ګټل شوې". د پایلې په توګه، د تبادلې پیرودونکي په دې پوهیدل پیل کړل چې که ورته لیږد د څو ګیټ ویز څخه لیږل شوی وي، نو د دې چټک پروسس امکانات زیات شوي. ډیر ژر، د تبادلې روبوټونو د غوښتنو سره په ګیټ وے بمباري پیل کړه، او د راکړې ورکړې واوره را منځته شوه.

د تکامل نوی پړاو

د پراخه ازموینې او څیړنې وروسته، موږ د ریښتیني وخت عملیاتي سیسټم کرنل ته واړوو. د دې لپاره موږ د RedHat Enterprise MRG لینکس غوره کړ، چیرته چې MRG د ریښتیني وخت پیغام رسولو لپاره ولاړ دی. د ریښتیني وخت پیچونو ګټه دا ده چې دوی سیسټم د ګړندۍ ممکنه اجرا کولو لپاره غوره کوي: ټولې پروسې د FIFO کتار کې ځای په ځای شوي ، کورونه جلا کیدی شي ، نه ایستل کیږي ، ټولې معاملې په سخت ترتیب کې پروسس کیږي.

سور - په منظم دانه کې د قطار سره کار کول، شنه - په ریښتیني وخت دانه کې کار کول.

مګر په منظم سرورونو کې د ټیټ ځنډ ترلاسه کول دومره اسانه ندي:

• د SMI حالت، کوم چې په x86 جوړښت کې د مهمو پردیو سره د کار کولو اساس دی، خورا مداخله کوي. د هر ډول هارډویر پیښو پروسس کول او د اجزاو او وسیلو مدیریت د فرم ویئر لخوا په تش په نوم شفاف SMI حالت کې ترسره کیږي ، په کوم کې چې عملیاتي سیسټم نه ګوري چې فرم ویئر په بشپړ ډول څه کوي. د یوې قاعدې په توګه، ټول لوی پلورونکي د فرم ویئر سرورونو لپاره ځانګړي توسیع وړاندیز کوي چې د SMI پروسس کولو مقدار کمولو ته اجازه ورکوي.
• د پروسیسر فریکوینسي هیڅ متحرک کنټرول شتون نلري ، دا د اضافي ځنډیدو لامل کیږي.
• کله چې د فایل سیسټم لاګ فلش شي، ځینې پروسې په دانه کې واقع کیږي چې د اټکل وړ ځنډ لامل کیږي.
• تاسو اړتیا لرئ شیانو ته پاملرنه وکړئ لکه د CPU تړاو، مداخله اړیکه، NUMA.

زه باید ووایم چې د ریښتیني وخت پروسس کولو لپاره د لینکس هارډویر او کرنل تنظیم کولو موضوع د جلا مقالې مستحق دي. مخکې لدې چې ښه پایله ترلاسه کړو موږ ډیر وخت په تجربه او څیړلو تیر کړو.

کله چې د PA-RISC سرورونو څخه x86 ته حرکت وکړو، موږ په عملي توګه د سیسټم کوډ ډیر بدلولو ته اړتیا نه درلوده، موږ یوازې دا تطابق او بیا تنظیم کړ. په ورته وخت کې، موږ څو کیچونه حل کړل. د مثال په توګه، د دې حقیقت پایلې چې PA RISC یو لوی انډین سیسټم و، او x86 یو کوچنی انډین سیسټم و، په چټکۍ سره ښکاره شو: د بیلګې په توګه، ډاټا په غلط ډول لوستل شوي. ستونزمنه ستونزه دا وه چې PA RISC یې کاروي په دوامداره توګه متواتر (په پرله پسې ډول) حافظې ته لاسرسی ، پداسې حال کې چې x86 کولی شي د لوستلو عملیات له سره تنظیم کړي ، نو کوډ چې په یو پلیټ فارم کې بالکل معتبر و په بل کې مات شو.

x86 ته د بدلولو وروسته، فعالیت نږدې درې چنده زیات شو، د اوسط لیږد پروسس وخت 60 μs ته راټیټ شو.

راځئ چې اوس نږدې وګورو چې د سیسټم جوړښت کې کوم مهم بدلونونه رامینځته شوي.

د ګرمې زیرمې ایپیک

کله چې د اجناسو سرورونو ته لاړ شو، موږ پوهیږو چې دوی لږ باوري دي. نو ځکه، کله چې یو نوی جوړښت رامینځته کړو، موږ لومړیتوب د یو یا ډیرو نوډونو د ناکامۍ احتمال په غاړه اخیستو. له همدې امله، یو ګرم سټنډرډ سیسټم ته اړتیا وه چې کولی شي په چټکۍ سره د بیک اپ ماشینونو ته لاړ شي.

برسېره پر دې، نور اړتیاوې وې:

• په هیڅ حالت کې تاسو باید پروسس شوي لیږد له لاسه ورنکړو.
• سیسټم باید زموږ زیربنا ته بالکل شفاف وي.
• پیرودونکي باید ورک شوي اړیکې ونه ګوري.
• ریزرویشنونه باید د پام وړ ځنډ معرفي نکړي ځکه چې دا د تبادلې لپاره یو مهم فکتور دی.

کله چې د ګرم سټنډرډ سیسټم رامینځته کول ، موږ ورته سناریوګانې د دوه ګوني ناکامیو په توګه په پام کې نه نیسو (د مثال په توګه ، په یو سرور کې شبکه کار کول بند کړل او اصلي سرور کنګل شو)؛ په سافټویر کې د غلطیو احتمال په پام کې نه نیسي ځکه چې دوی د ازموینې پرمهال پیژندل شوي؛ او د هارډویر غلط عملیات په پام کې نه نیسي.

د پایلې په توګه، موږ لاندې سکیم ته راغلو:

• اصلي سرور د ګیټ وے سرورونو سره مستقیم اړیکه لري.
• په اصلي سرور کې ترلاسه شوي ټولې معاملې په سمدستي توګه د جلا چینل له لارې بیک اپ سرور ته نقل شوي. ثالث ( والي ) د بدلون سره همغږي کړي که کومه ستونزه رامنځته شي.

  

• اصلي سرور هره معامله پروسس کړې او د بیک اپ سرور څخه تایید ته انتظار باسي. لږ تر لږه د ځنډ ساتلو لپاره، موږ په بیک اپ سرور کې د لیږد بشپړولو لپاره انتظار کولو څخه ډډه وکړه. له هغه وخت راهیسې چې په ټوله شبکه کې د لیږد لپاره د لیږد وخت د اجرا کولو وخت سره د پرتلې وړ و ، هیڅ اضافي ځنډ ندی اضافه شوی.
• موږ یوازې د پخوانۍ راکړې ورکړې لپاره د اصلي او بیک اپ سرورونو د پروسس حالت چیک کولی شو، او د اوسني لیږد پروسس کولو حالت نامعلوم و. څنګه چې موږ لاهم د واحد تار شوي پروسې کاروو، د بیک اپ څخه ځواب ته انتظار کول به د پروسس ټول جریان ورو کړي، نو موږ یو مناسب جوړجاړی وکړ: موږ د تیرې معاملې پایله چیک کړه.

سکیم په لاندې ډول کار کاوه.

راځئ چې ووایو اصلي سرور ځواب ورکول ودروي، مګر ګیټ ویز خبرو اترو ته دوام ورکوي. په بیک اپ سرور کې یو وخت پای ته رسیږي، دا د والي سره اړیکه نیسي، څوک چې دا د اصلي سرور رول ګماري، او ټولې ګیټ ویز نوي اصلي سرور ته ځي.

که اصلي سرور بیرته آنلاین راشي، دا د داخلي وخت پای هم رامینځته کوي، ځکه چې د یو ټاکلي وخت لپاره د ګیټ وے څخه سرور ته هیڅ زنګونه ندي راغلي. بیا هغه والي ته هم مراجعه کوي، او هغه له سکیم څخه لرې کوي. د پایلې په توګه، تبادله د سوداګرۍ دورې پای ته رسیدو پورې د یو سرور سره کار کوي. څرنګه چې د سرور د ناکامۍ احتمال خورا ټیټ دی، دا سکیم خورا د منلو وړ ګڼل کیده؛ پدې کې پیچلي منطق نه و او ازموینه یې اسانه وه.

دوام ته دوام ورکول.

سرچینه: www.habr.com