تکامل معماری سیستم معاملات و تسویه حساب بورس مسکو. قسمت 1

سلام به همه! نام من سرگئی کوستانباف است، در بورس در حال توسعه هسته سیستم معاملاتی هستم.

وقتی فیلم‌های هالیوودی بورس نیویورک را نشان می‌دهند، همیشه اینگونه به نظر می‌رسد: انبوه مردم، همه چیزی فریاد می‌زنند، کاغذها را تکان می‌دهند، هرج و مرج کامل در حال رخ دادن است. این هرگز در بورس مسکو اتفاق نیفتاده است، زیرا معاملات از همان ابتدا به صورت الکترونیکی انجام شده است و بر اساس دو پلت فرم اصلی - Spectra (بازار فارکس) و ASTS (صرافی، سهام و بازار پول) است. و امروز می خواهم در مورد تکامل معماری سیستم معاملات و تسویه حساب ASTS، در مورد راه حل ها و یافته های مختلف صحبت کنم. داستان طولانی خواهد بود، بنابراین مجبور شدم آن را به دو قسمت تقسیم کنم.

ما یکی از معدود صرافی‌هایی در جهان هستیم که دارایی‌های همه طبقات را معامله می‌کنیم و طیف کاملی از خدمات مبادله را ارائه می‌کنیم. به عنوان مثال، در سال گذشته رتبه دوم جهان را از نظر حجم معاملات اوراق قرضه، رتبه 25 در بین کل بورس ها، رتبه سیزدهم در سرمایه گذاری در بین بورس های عمومی را به خود اختصاص دادیم.

برای شرکت کنندگان حرفه ای معاملات، پارامترهایی مانند زمان پاسخ، ثبات توزیع زمان (جتر) و قابلیت اطمینان کل مجموعه بسیار مهم است. ما در حال حاضر روزانه ده ها میلیون تراکنش را پردازش می کنیم. پردازش هر تراکنش توسط هسته سیستم ده ها میکروثانیه طول می کشد. البته اپراتورهای تلفن همراه در شب سال نو یا خود موتورهای جستجو حجم کاری بالاتری نسبت به ما دارند، اما به نظر من از نظر حجم کاری، همراه با ویژگی های ذکر شده در بالا، تعداد کمی با ما قابل مقایسه هستند. در عین حال، برای ما مهم است که سیستم برای یک ثانیه کند نشود، کاملاً پایدار کار کند و همه کاربران در موقعیت برابر باشند.

کمی تاریخچه

در سال 1994، سیستم ASTS استرالیا در بورس ارز بین بانکی مسکو (MICEX) راه اندازی شد و از آن لحظه می توان تاریخ تجارت الکترونیک روسیه را شمارش کرد. در سال 1998، معماری صرافی برای معرفی تجارت اینترنتی مدرن شد. از آن زمان، سرعت اجرای راهکارهای جدید و تغییرات معماری در تمامی سیستم‌ها و زیرسیستم‌ها تنها در حال افزایش است.

در آن سال‌ها، سیستم تبادل روی سخت‌افزار پیشرفته کار می‌کرد - سرورهای HP Superdome 9000 فوق‌العاده قابل اعتماد (ساخته شده بر روی PA-RISC، که در آن کاملاً همه چیز تکراری بود: زیرسیستم های ورودی / خروجی، شبکه، رم (در واقع یک آرایه RAID از RAM وجود داشت)، پردازنده ها (قابل تعویض گرم). امکان تغییر هر جزء سرور بدون توقف دستگاه وجود داشت. ما به این دستگاه‌ها تکیه کردیم و آنها را عملاً ایمن در نظر گرفتیم. سیستم عامل یک سیستم HP UX شبیه یونیکس بود.

اما از حدود سال 2010، پدیده ای به نام تجارت با فرکانس بالا (HFT) یا تجارت با فرکانس بالا - به زبان ساده، روبات های بورس اوراق بهادار ظهور کرد. تنها در 2,5 سال، بار روی سرورهای ما 140 برابر افزایش یافته است.

تحمل چنین باری با معماری و تجهیزات قدیمی غیرممکن بود. لازم بود به نحوی سازگار شود.

شروع

درخواست ها به سیستم مبادله ای را می توان به دو نوع تقسیم کرد:

• معاملات. اگر می خواهید دلار، سهام یا چیز دیگری بخرید، تراکنش را به سیستم معاملاتی ارسال می کنید و پاسخ موفقیت را دریافت می کنید.
• درخواست های اطلاعاتی اگر می خواهید از قیمت فعلی مطلع شوید، دفترچه سفارش یا شاخص ها را مشاهده کنید، سپس درخواست اطلاعات ارسال کنید.

از نظر شماتیک، هسته سیستم را می توان به سه سطح تقسیم کرد:

• سطح مشتری، که در آن کارگزاران و مشتریان کار می کنند. همه آنها با سرورهای دسترسی تعامل دارند.
• سرورهای دروازه سرورهایی هستند که به صورت محلی تمام درخواست های اطلاعات را پردازش می کنند. آیا می خواهید بدانید که سهام Sberbank در حال حاضر با چه قیمتی معامله می شود؟ درخواست به سرور دسترسی می رود.
• اما اگر بخواهید سهام بخرید، درخواست به سرور مرکزی (Trade Engine) می رود. برای هر نوع بازار یک سرور وجود دارد، آنها نقش حیاتی دارند، این سیستم را برای آنها ایجاد کردیم.

هسته سیستم معاملاتی یک پایگاه داده هوشمندانه در حافظه است که در آن تمام تراکنش ها معاملات مبادله ای هستند. پایه به زبان C نوشته شده بود، تنها وابستگی های خارجی کتابخانه libc بود و اصلاً تخصیص حافظه پویا وجود نداشت. برای کاهش زمان پردازش، سیستم با مجموعه ای استاتیک از آرایه ها و با جابجایی داده های ایستا شروع می شود: ابتدا، تمام داده های روز جاری در حافظه بارگذاری می شود و دیگر دسترسی به دیسک انجام نمی شود، تمام کارها فقط در حافظه انجام می شود. هنگامی که سیستم شروع به کار می کند، تمام داده های مرجع از قبل مرتب شده اند، بنابراین جستجو بسیار کارآمد عمل می کند و زمان کمی را در زمان اجرا می گیرد. همه جداول با لیست ها و درخت های نفوذی برای ساختارهای داده پویا ساخته شده اند تا در زمان اجرا نیازی به تخصیص حافظه نداشته باشند.

بیایید به طور خلاصه تاریخچه توسعه سیستم معاملات و تسویه حساب خود را مرور کنیم.
اولین نسخه از معماری سیستم معاملات و تسویه بر اساس تعامل یونیکس ساخته شد: حافظه مشترک، سمافورها و صف‌ها استفاده می‌شد و هر فرآیند شامل یک رشته واحد بود. این رویکرد در اوایل دهه 1990 گسترده بود.

نسخه اول سیستم شامل دو سطح Gateway و یک سرور مرکزی سیستم معاملاتی بود. روند کار به این صورت بود:

• مشتری درخواستی را ارسال می کند که به Gateway می رسد. اعتبار قالب (اما نه خود داده ها) را بررسی می کند و تراکنش های نادرست را رد می کند.
• اگر درخواست اطلاعات ارسال شده باشد، به صورت محلی اجرا می شود. اگر در مورد تراکنش صحبت می کنیم، آنگاه به سرور مرکزی هدایت می شود.
• سپس موتور معاملاتی تراکنش را پردازش می کند، حافظه محلی را اصلاح می کند و با استفاده از یک موتور تکرار جداگانه، پاسخی به تراکنش و خود تراکنش برای تکرار ارسال می کند.
• Gateway پاسخ را از گره مرکزی دریافت می کند و آن را به مشتری ارسال می کند.
• پس از مدتی Gateway تراکنش را از طریق مکانیزم Replication دریافت می کند و این بار آن را به صورت محلی اجرا می کند و ساختار داده های خود را تغییر می دهد تا درخواست های اطلاعات بعدی آخرین داده ها را نمایش دهند.

در واقع یک مدل تکراری را توصیف می کند که در آن Gateway به طور کامل اقدامات انجام شده در سیستم معاملاتی را تکرار می کند. یک کانال تکرار جداگانه تضمین می‌کند که تراکنش‌ها به همان ترتیب در گره‌های دسترسی چندگانه اجرا می‌شوند.

از آنجایی که کد تک رشته ای بود، یک طرح کلاسیک با انشعابات فرآیند برای خدمت رسانی به بسیاری از مشتریان استفاده شد. با این حال، انشعاب کل پایگاه داده بسیار گران بود، بنابراین از فرآیندهای خدماتی سبکی استفاده می شد که بسته ها را از جلسات TCP جمع آوری می کرد و آنها را به یک صف (صف پیام SystemV) منتقل می کرد. Gateway و Trade Engine فقط با این صف کار می کردند و تراکنش ها را از آنجا برای اجرا می گرفتند. دیگر امکان ارسال پاسخ به آن وجود نداشت، زیرا مشخص نبود کدام فرآیند سرویس باید آن را بخواند. بنابراین ما به یک ترفند متوسل شدیم: هر فرآیند فورک شده یک صف پاسخ برای خود ایجاد می کند و زمانی که یک درخواست وارد صف ورودی می شود، بلافاصله یک برچسب برای صف پاسخ به آن اضافه می شود.

کپی کردن مداوم مقادیر زیادی از داده ها از صف به صف، مشکلاتی را ایجاد می کند، به ویژه برای درخواست های اطلاعاتی معمولی. بنابراین، از ترفند دیگری استفاده کردیم: علاوه بر صف پاسخ، هر فرآیند حافظه مشترک (SystemV Shared Memory) را نیز ایجاد کرد. خود بسته‌ها در آن قرار می‌گرفتند و فقط یک برچسب در صف ذخیره می‌شد که به فرد اجازه می‌داد بسته اصلی را پیدا کند. این به ذخیره داده ها در حافظه پنهان پردازنده کمک کرد.

SystemV IPC شامل ابزارهایی برای مشاهده وضعیت صف، حافظه و اشیاء سمافور است. ما فعالانه از این برای درک آنچه در سیستم در یک لحظه خاص اتفاق می افتد، جایی که بسته ها انباشته شده اند، چه چیزی مسدود شده است و غیره استفاده می کنیم.

اولین ارتقا

اول از همه، ما از Gateway تک فرآیندی خلاص شدیم. اشکال مهم آن این بود که می‌توانست یک تراکنش تکراری یا یک درخواست اطلاعاتی از مشتری را مدیریت کند. و با افزایش بار، Gateway برای پردازش درخواست‌ها بیشتر طول می‌کشد و نمی‌تواند جریان تکرار را پردازش کند. علاوه بر این، اگر مشتری تراکنشی را ارسال کرده باشد، فقط باید اعتبار آن را بررسی کرده و آن را بیشتر ارسال کنید. بنابراین، ما فرآیند تک Gateway را با چندین مؤلفه جایگزین کردیم که می‌توانند به صورت موازی اجرا شوند: اطلاعات چند رشته‌ای و فرآیندهای تراکنش که مستقل از یکدیگر در یک منطقه حافظه مشترک با استفاده از قفل RW اجرا می‌شوند. و همزمان فرآیندهای ارسال و تکرار را معرفی کردیم.

تاثیر تجارت با فرکانس بالا

نسخه فوق از معماری تا سال 2010 وجود داشت. در این میان، دیگر از عملکرد سرورهای HP Superdome راضی نبودیم. علاوه بر این، معماری PA-RISC تقریباً مرده بود؛ فروشنده هیچ به روز رسانی قابل توجهی ارائه نکرد. در نتیجه، ما شروع به حرکت از HP UX/PA RISC به Linux/x86 کردیم. انتقال با تطبیق سرورهای دسترسی آغاز شد.

چرا مجبور شدیم دوباره معماری را تغییر دهیم؟ واقعیت این است که معاملات با فرکانس بالا به طور قابل توجهی پروفایل بار روی هسته سیستم را تغییر داده است.

فرض کنید یک معامله کوچک داریم که باعث تغییر قیمت قابل توجهی شد - شخصی نیم میلیارد دلار خرید. پس از چند میلی ثانیه، همه فعالان بازار متوجه این موضوع می شوند و شروع به اصلاح می کنند. طبیعتاً درخواست‌ها در یک صف بزرگ قرار می‌گیرند که پاک کردن آن‌ها توسط سیستم زمان زیادی طول می‌کشد.

در این بازه 50 میلی‌ثانیه سرعت متوسط ​​حدود 16 هزار تراکنش در ثانیه است. اگر پنجره را به 20 میلی‌ثانیه کاهش دهیم، میانگین سرعت 90 هزار تراکنش در ثانیه با 200 هزار تراکنش در اوج به دست می‌آید. به عبارت دیگر، بار ثابت نیست، با ترکیدن ناگهانی. و صف درخواست ها همیشه باید سریع پردازش شود.

اما اصلا چرا صف است؟ بنابراین، در مثال ما، بسیاری از کاربران متوجه تغییر قیمت شده و بر اساس آن تراکنش‌ها را ارسال کردند. آنها به Gateway می آیند، آنها را سریال می کند، نظم خاصی را تنظیم می کند و آنها را به شبکه می فرستد. روترها بسته ها را به هم می زنند و آنها را ارسال می کنند. چه کسی بسته اول وارد شد، آن تراکنش "برنده شد". در نتیجه، مشتریان صرافی متوجه شدند که اگر همان تراکنش از چندین دروازه ارسال شود، شانس پردازش سریع آن افزایش می‌یابد. به زودی، روبات های مبادله ای شروع به بمباران گیت وی با درخواست ها کردند و بهمنی از تراکنش ها به وجود آمد.

دور جدیدی از تکامل

پس از آزمایش و تحقیق گسترده، به هسته سیستم عامل بلادرنگ تغییر مکان دادیم. برای این کار RedHat Enterprise MRG Linux را انتخاب کردیم، جایی که MRG مخفف شبکه پیام رسانی بلادرنگ است. مزیت وصله‌های بلادرنگ این است که سیستم را برای سریع‌ترین اجرای ممکن بهینه می‌کنند: همه فرآیندها در یک صف FIFO ردیف می‌شوند، هسته‌ها را می‌توان ایزوله کرد، بدون خروج، همه تراکنش‌ها به ترتیب دقیق پردازش می‌شوند.

قرمز - کار با یک صف در یک هسته معمولی، سبز - کار در یک هسته بلادرنگ.

اما دستیابی به تاخیر کم در سرورهای معمولی چندان آسان نیست:

• حالت SMI که در معماری x86 اساس کار با تجهیزات جانبی مهم است، تداخل زیادی ایجاد می کند. پردازش انواع رویدادهای سخت افزاری و مدیریت قطعات و دستگاه ها توسط فریمور در حالت به اصطلاح شفاف SMI انجام می شود که در آن سیستم عامل اصلا نمی بیند که فریمور چه کاری انجام می دهد. به عنوان یک قاعده، همه فروشندگان اصلی افزونه های ویژه ای را برای سرورهای سیستم عامل ارائه می دهند که امکان کاهش میزان پردازش SMI را فراهم می کند.
• نباید کنترل دینامیکی فرکانس پردازنده وجود داشته باشد، این منجر به خرابی اضافی می شود.
• هنگامی که لاگ سیستم فایل پاک می شود، فرآیندهای خاصی در هسته رخ می دهد که باعث تاخیرهای غیرقابل پیش بینی می شود.
• شما باید به مواردی مانند CPU Affinity، Interrupt Affinity، NUMA توجه کنید.

باید بگویم که مبحث راه اندازی سخت افزار و هسته لینوکس برای پردازش بلادرنگ مستحق یک مقاله جداگانه است. قبل از اینکه به نتیجه خوبی برسیم، زمان زیادی را صرف آزمایش و تحقیق کردیم.

هنگام انتقال از سرورهای PA-RISC به x86، عملاً مجبور نبودیم کد سیستم را زیاد تغییر دهیم، فقط آن را تطبیق داده و پیکربندی مجدد کردیم. در همان زمان، چندین باگ را برطرف کردیم. به عنوان مثال، پیامدهای این واقعیت که PA RISC یک سیستم اندیان بزرگ و x86 یک سیستم اندیان کوچک بود، به سرعت نمایان شد: به عنوان مثال، داده ها اشتباه خوانده شدند. مشکل پیچیده تر این بود که PA RISC از آن استفاده می کند به طور مداوم سازگار است (متوالی سازگار است) دسترسی به حافظه، در حالی که x86 می تواند عملیات خواندن را دوباره ترتیب دهد، بنابراین کدی که در یک پلتفرم کاملاً معتبر بود، در پلتفرم دیگر شکسته شد.

پس از تغییر به x86، عملکرد تقریباً سه برابر افزایش یافت، میانگین زمان پردازش تراکنش به 60 میکرو ثانیه کاهش یافت.

حال بیایید نگاهی دقیق‌تر به تغییرات کلیدی در معماری سیستم داشته باشیم.

حماسه ذخیره داغ

هنگام تغییر به سرورهای کالا، متوجه بودیم که آنها کمتر قابل اعتماد هستند. بنابراین، هنگام ایجاد یک معماری جدید، ما پیش از این احتمال شکست یک یا چند گره را در نظر گرفتیم. بنابراین، یک سیستم آماده به کار داغ مورد نیاز بود که بتواند خیلی سریع به ماشین های پشتیبان سوئیچ کند.

علاوه بر این، الزامات دیگری نیز وجود داشت:

• تحت هیچ شرایطی نباید تراکنش های پردازش شده را از دست بدهید.
• سیستم باید برای زیرساخت های ما کاملا شفاف باشد.
• مشتریان نباید اتصالات قطع شده را ببینند.
• رزروها نباید تاخیر قابل توجهی ایجاد کنند زیرا این یک عامل مهم برای تبادل است.

هنگام ایجاد یک سیستم آماده به کار داغ، ما چنین سناریوهایی را به عنوان خرابی مضاعف در نظر نمی گیریم (به عنوان مثال، شبکه در یک سرور کار نمی کند و سرور اصلی مسدود می شود). احتمال خطا در نرم افزار را در نظر نگرفت زیرا در هنگام تست شناسایی می شوند. و عملکرد نادرست سخت افزار را در نظر نگرفت.

در نتیجه به طرح زیر رسیدیم:

• سرور اصلی مستقیماً با سرورهای Gateway تعامل داشت.
• تمام تراکنش‌های دریافتی روی سرور اصلی بلافاصله از طریق یک کانال جداگانه به سرور پشتیبان تکرار شدند. داور (فرماندار) در صورت بروز هرگونه مشکل، تعویض را هماهنگ کرد.

  

• سرور اصلی هر تراکنش را پردازش می کند و منتظر تایید سرور پشتیبان می باشد. برای به حداقل رساندن تاخیر، از انتظار برای تکمیل تراکنش در سرور پشتیبان اجتناب کردیم. از آنجایی که مدت زمان انجام تراکنش در سراسر شبکه با زمان اجرا قابل مقایسه بود، هیچ تاخیر اضافی اضافه نشد.
• ما فقط توانستیم وضعیت پردازش سرورهای اصلی و پشتیبان را برای تراکنش قبلی بررسی کنیم و وضعیت پردازش تراکنش فعلی ناشناخته بود. از آنجایی که ما هنوز از فرآیندهای تک رشته‌ای استفاده می‌کردیم، انتظار برای پاسخ از پشتیبان‌گیری می‌توانست کل جریان پردازش را کند کند، بنابراین یک مصالحه معقول انجام دادیم: نتیجه تراکنش قبلی را بررسی کردیم.

این طرح به شرح زیر عمل کرد.

فرض کنید سرور اصلی دیگر پاسخ نمی دهد، اما دروازه ها به برقراری ارتباط ادامه می دهند. یک مهلت زمانی روی سرور پشتیبان رخ می دهد، با فرماندار تماس می گیرد، که نقش سرور اصلی را به آن اختصاص می دهد، و همه دروازه ها به سرور اصلی جدید سوئیچ می شوند.

اگر سرور اصلی دوباره آنلاین شود، یک مهلت زمانی داخلی نیز ایجاد می‌کند، زیرا برای مدت معینی از Gateway هیچ تماسی با سرور برقرار نشده است. سپس او نیز به فرماندار مراجعه می کند و او را از طرح خارج می کند. در نتیجه صرافی تا پایان دوره معاملاتی با یک سرور کار می کند. از آنجایی که احتمال خرابی سرور بسیار کم است، این طرح کاملاً قابل قبول در نظر گرفته شد؛ این طرح حاوی منطق پیچیده نبود و آزمایش آن آسان بود.

ادامه دارد

منبع: www.habr.com