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

این ادامه یک داستان طولانی در مورد مسیر خاردار ما برای ایجاد یک سیستم قدرتمند و پر بار است که عملکرد Exchange را تضمین می کند. قسمت اول اینجاست: habr.com/fa/post/444300

خطای مرموز

پس از آزمایش های متعدد، سامانه به روز شده معاملات و تسویه حساب کاربری به بهره برداری رسید و با اشکالی مواجه شدیم که می توانستیم درباره آن یک داستان کارآگاهی – عرفانی بنویسیم.

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

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

علت خطا پیدا نشد.

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

در پایان، ما بر روی یک نظریه از دنیای فیزیک پرانرژی مستقر شدیم: مقداری ذره پرانرژی به مرکز داده ما پرواز کرد، دیوار کیس را سوراخ کرد، به پردازنده برخورد کرد و باعث شد که قفل ماشه در همان قسمت بچسبد. این نظریه پوچ "نوترینو" نامیده شد. اگر از فیزیک ذرات دور هستید: نوترینوها تقریباً با دنیای بیرون تعامل ندارند و مطمئناً نمی توانند بر عملکرد پردازنده تأثیر بگذارند.

از آنجایی که یافتن علت خرابی ممکن نبود، سرور "متخلف" در هر صورت از کار خارج شد.

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

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

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

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

و ناگهان سال گذشته مقاله ای در Habré منتشر شد.چگونه یک اشکال در پردازنده های Skylake اینتل پیدا کردم" وضعیت توصیف شده در آن بسیار شبیه به وضعیت ما بود، اما نویسنده تحقیق را بیشتر کرد و نظریه ای را مطرح کرد که خطا در میکروکد است. و هنگامی که هسته های لینوکس به روز می شوند، سازندگان میکروکد را نیز به روز می کنند.

توسعه بیشتر سیستم

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

اصول زیر اساس پیشرفت های بعدی در سیستم رزرواسیون را تشکیل دادند:

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

هیچ یک از راه حل های موجود در بازار برای ما مناسب نبود و پروتکل Raft هنوز در مراحل اولیه خود بود، بنابراین ما راه حل خود را ایجاد کردیم.

شبکه سازی

علاوه بر سیستم رزرواسیون، ما شروع به نوسازی تعامل شبکه کردیم. زیرسیستم ورودی/خروجی متشکل از فرآیندهای زیادی بود که بدترین تأثیر را بر روی لرزش و تأخیر داشتند. با صدها فرآیندی که اتصالات TCP را مدیریت می‌کنند، ما مجبور شدیم دائماً بین آنها سوئیچ کنیم و در مقیاس میکروثانیه این یک عملیات نسبتاً وقت‌گیر است. اما بدترین قسمت این است که وقتی یک پردازش یک بسته را برای پردازش دریافت می‌کند، آن را به یک صف SystemV می‌فرستد و سپس منتظر یک رویداد از صف دیگر SystemV می‌شود. با این حال، هنگامی که تعداد زیادی گره وجود دارد، ورود یک بسته TCP جدید در یک فرآیند و دریافت داده ها در صف در فرآیند دیگر نشان دهنده دو رویداد رقابتی برای سیستم عامل است. در این حالت، اگر هیچ پردازنده فیزیکی برای هر دو کار موجود نباشد، یکی پردازش می‌شود و دومی در صف انتظار قرار می‌گیرد. پیش بینی عواقب آن غیرممکن است.

در چنین شرایطی می توان از کنترل پویای اولویت فرآیند استفاده کرد، اما این امر مستلزم استفاده از فراخوانی های سیستمی با منابع فشرده است. در نتیجه، ما با استفاده از epoll کلاسیک به یک رشته سوئیچ کردیم، این سرعت را تا حد زیادی افزایش داد و زمان پردازش تراکنش را کاهش داد. ما همچنین از فرآیندهای ارتباطی شبکه جداگانه و ارتباط از طریق SystemV خلاص شدیم، تعداد تماس های سیستمی را به میزان قابل توجهی کاهش دادیم و شروع به کنترل اولویت های عملیات کردیم. تنها در زیرسیستم ورودی/خروجی، بسته به سناریو می‌توان حدود 8 تا 17 میکروثانیه ذخیره کرد. این طرح تک رشته ای از آن زمان بدون تغییر استفاده شده است؛ یک رشته epoll با حاشیه برای سرویس دهی به همه اتصالات کافی است.

پروسه جابجایی پول

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

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

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

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

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

پس از یک انطباق کوچک از کد، یک خط لوله برای پردازش تراکنش موازی ایجاد کردیم که در آن تراکنش به 4 مرحله از خط لوله تقسیم شد: تعامل شبکه، اعتبارسنجی، اجرا و انتشار نتیجه.

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

اینگونه بود که ما به سیستم ASTS+ رسیدیم.

درست است، با نوار نقاله نیز همه چیز آنقدر هموار نیست. فرض کنید یک تراکنش داریم که بر آرایه‌های داده در یک تراکنش همسایه تأثیر می‌گذارد؛ این یک وضعیت معمولی برای یک مبادله است. چنین تراکنشی را نمی توان در خط لوله اجرا کرد زیرا ممکن است بر دیگران تأثیر بگذارد. این وضعیت خطر داده نامیده می‌شود و چنین تراکنش‌هایی به سادگی جداگانه پردازش می‌شوند: وقتی تراکنش‌های «سریع» در صف تمام می‌شوند، خط لوله متوقف می‌شود، سیستم تراکنش «آهسته» را پردازش می‌کند و سپس خط لوله را دوباره شروع می‌کند. خوشبختانه، نسبت چنین معاملاتی در جریان کلی بسیار کم است، بنابراین خط لوله به ندرت متوقف می شود که بر عملکرد کلی تأثیر نمی گذارد.

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

• تمام بسته های شبکه ورودی وارد مرحله تخصیص می شوند.
• آنها را در یک آرایه قرار می دهیم و آنها را به عنوان موجود برای مرحله شماره 1 علامت گذاری می کنیم.
• تراکنش دوم رسید، دوباره برای مرحله شماره 1 موجود است.
• نخ پردازش اول تراکنش های موجود را می بیند، آنها را پردازش می کند و آنها را به مرحله بعدی رشته پردازش دوم منتقل می کند.
• سپس اولین تراکنش را پردازش کرده و سلول مربوطه را علامت گذاری می کند deleted - اکنون برای استفاده جدید در دسترس است.

کل صف به این ترتیب پردازش می شود.

پردازش هر مرحله واحد یا ده ها میکروثانیه طول می کشد. و اگر از طرح های استاندارد همگام سازی سیستم عامل استفاده کنیم، زمان بیشتری را در خود همگام سازی از دست خواهیم داد. به همین دلیل ما شروع به استفاده از spinlock کردیم. با این حال، این حالت در یک سیستم بلادرنگ بسیار بد است و RedHat اکیداً انجام این کار را توصیه نمی‌کند، بنابراین ما یک spinlock را برای 100 میلی‌ثانیه اعمال می‌کنیم و سپس به حالت سمافور تغییر می‌دهیم تا احتمال بن‌بست را از بین ببریم.

در نتیجه به عملکردی حدود 8 میلیون تراکنش در ثانیه دست یافتیم. و به معنای واقعی کلمه دو ماه بعد در مقاله در مورد LMAX Disruptor شرحی از مداری با عملکرد مشابه دیدیم.

اکنون ممکن است چندین رشته اجرا در یک مرحله وجود داشته باشد. تمامی تراکنش ها به ترتیبی که دریافت شدند، یک به یک پردازش شدند. در نتیجه اوج عملکرد از 18 هزار تراکنش در ثانیه به 50 هزار تراکنش افزایش یافت.

سیستم مدیریت ریسک بورس

هیچ محدودیتی برای کمال وجود ندارد و به زودی دوباره نوسازی را آغاز کردیم: در چارچوب ASTS+، ما شروع به انتقال سیستم های مدیریت ریسک و عملیات تسویه به اجزای مستقل کردیم. ما یک معماری مدرن انعطاف پذیر و یک مدل ریسک سلسله مراتبی جدید ایجاد کردیم و سعی کردیم تا جایی که امکان داشت از کلاس استفاده کنیم fixed_point به جای double.

اما بلافاصله یک مشکل ایجاد شد: چگونه می توان تمام منطق تجاری را که سال هاست کار می کند هماهنگ کرد و آن را به سیستم جدید منتقل کرد؟ در نتیجه، اولین نسخه از نمونه اولیه سیستم جدید باید رها می شد. نسخه دوم که در حال حاضر در حال تولید است، بر اساس همین کد است که در دو بخش تجاری و ریسک کار می کند. در طول توسعه، سخت‌ترین کار، ادغام git بین دو نسخه بود. همکار ما Evgeniy Mazurenok هر هفته این عمل را انجام می داد و هر بار برای مدت بسیار طولانی فحش می داد.

هنگام انتخاب یک سیستم جدید، ما بلافاصله باید مشکل تعامل را حل می کردیم. هنگام انتخاب یک گذرگاه داده، لازم بود از لرزش پایدار و حداقل تاخیر اطمینان حاصل شود. شبکه InfiniBand RDMA بهترین گزینه برای این بود: میانگین زمان پردازش 4 برابر کمتر از شبکه های اترنت 10 G است. اما آنچه واقعاً ما را مجذوب خود کرد تفاوت در صدک ها - 99 و 99,9 بود.

البته InfiniBand چالش های خودش را دارد. در مرحله اول، یک API متفاوت - ibverbs به جای سوکت. ثانیاً، تقریباً هیچ راه حل گسترده ای برای پیام رسانی منبع باز وجود ندارد. ما سعی کردیم نمونه اولیه خود را بسازیم، اما معلوم شد که بسیار دشوار است، بنابراین یک راه حل تجاری را انتخاب کردیم - Confinity Low Latency Messaging (قبلاً IBM MQ LLM).

سپس وظیفه تقسیم صحیح سیستم ریسک مطرح شد. اگر به سادگی Risk Engine را حذف کنید و یک گره میانی ایجاد نکنید، تراکنش های دو منبع می توانند با هم ترکیب شوند.

راه حل های به اصطلاح Ultra Low Latency حالت سفارش مجدد دارند: تراکنش ها از دو منبع را می توان به ترتیب مورد نیاز در هنگام دریافت مرتب کرد؛ این با استفاده از یک کانال جداگانه برای تبادل اطلاعات در مورد سفارش اجرا می شود. اما ما هنوز از این حالت استفاده نمی کنیم: کل فرآیند را پیچیده می کند و در تعدادی از راه حل ها اصلاً پشتیبانی نمی شود. علاوه بر این، به هر تراکنش باید مهرهای زمانی مربوطه اختصاص داده شود، و در طرح ما اجرای صحیح این مکانیسم بسیار دشوار است. بنابراین، ما از طرح کلاسیک با یک کارگزار پیام، یعنی با توزیع کننده ای که پیام ها را بین موتور ریسک توزیع می کند، استفاده کردیم.

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

تکثیر. مضاعف شدن

سیستم ما نباید یک نقطه خرابی داشته باشد، یعنی همه اجزاء از جمله بروکر پیام باید کپی شوند. ما این مشکل را با استفاده از سیستم CLLM حل کردیم: شامل یک خوشه RCMS است که در آن دو توزیع کننده می توانند در حالت master-slave کار کنند و وقتی یکی از کار بیفتد، سیستم به طور خودکار به دیگری سوئیچ می کند.

کار با یک مرکز داده پشتیبان

InfiniBand برای عملیات به عنوان یک شبکه محلی بهینه شده است، یعنی برای اتصال تجهیزات rack-mount، و شبکه InfiniBand را نمی توان بین دو مرکز داده جغرافیایی توزیع شده قرار داد. بنابراین، ما یک Bridge/Dispatcher را پیاده‌سازی کردیم که از طریق شبکه‌های اترنت معمولی به ذخیره‌سازی پیام متصل می‌شود و همه تراکنش‌ها را به شبکه دوم IB منتقل می‌کند. هنگامی که ما نیاز به مهاجرت از یک مرکز داده داریم، می توانیم انتخاب کنیم که اکنون با کدام مرکز داده کار کنیم.

نمایش نتایج: از

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

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

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

ما نسخه فعلی پلتفرم خود را Rebus نامیدیم - به عنوان مخفف دو نوآوری قابل توجه در معماری، Risk Engine و BUS.

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

آنچه در نهایت به دست آوردیم:

سطح تأخیر را کاهش داد. با حجم کم تراکنش، سیستم مانند نسخه قبلی کار می کند، اما در عین حال می تواند بار بسیار بیشتری را تحمل کند.

اوج عملکرد از 50 هزار تراکنش در ثانیه به 180 هزار تراکنش افزایش یافت. افزایش بیشتر توسط تنها جریان تطبیق سفارش با مشکل مواجه می شود.

دو راه برای بهبود بیشتر وجود دارد: تطبیق موازی و تغییر روش کار با Gateway. اکنون همه دروازه‌ها بر اساس یک طرح تکرار عمل می‌کنند، که تحت چنین باری، عملکرد عادی خود را متوقف می‌کند.

در نهایت، من می توانم به کسانی که در حال نهایی کردن سیستم های سازمانی هستند، توصیه هایی داشته باشم:

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

منبع: www.habr.com