Еволуција на архитектурата на системот за тргување и клириншка на Московската берза. Дел 1

Здраво на сите! Моето име е Сергеј Костанбаев, на Берзата го развивам јадрото на системот за тргување.

Кога холивудските филмови ја прикажуваат Њујоршката берза, секогаш изгледа вака: толпи луѓе, сите викаат по нешто, мавтаат со хартии, се случува целосен хаос. Ова никогаш не се случило овде на Московската берза, бидејќи тргувањето од самиот почеток се спроведува електронски и се заснова на две главни платформи - Spectra (девизен пазар) и ASTS (девизна, берза и пазар на пари). И денес сакам да зборувам за еволуцијата на архитектурата на системот за тргување и клириншки ASTS, за различни решенија и наоди. Приказната ќе биде долга, па морав да ја поделам на два дела.

Ние сме една од ретките берзи во светот што тргува со средства од сите класи и обезбедува целосен опсег на услуги за размена. На пример, минатата година бевме на второ место во светот по обем на тргување со обврзници, 25 место меѓу сите берзи, 13 место по капитализација меѓу јавните берзи.

За професионалните учесници во тргувањето, критични се параметрите како што се времето на одговор, стабилноста на временската распределба (житер) и сигурноста на целиот комплекс. Во моментов обработуваме десетици милиони трансакции дневно. Обработката на секоја трансакција од системското јадро трае десетици микросекунди. Се разбира, мобилните оператори за новогодишната ноќ или самите пребарувачи имаат поголем обем на работа од нашиот, но во однос на обемот на работа, заедно со горенаведените карактеристики, малкумина можат да се споредат со нас, ми се чини. Во исто време, за нас е важно системот да не успори ниту една секунда, да работи апсолутно стабилно, а сите корисници да бидат на еднаква основа.

Малку историја

Во 1994 година, австралискиот ASTS систем беше лансиран на Московската меѓубанкарска берза (MICEX) и од тој момент може да се брои руската историја на електронско тргување. Во 1998 година, архитектурата на размена беше модернизирана за да се воведе интернет трговија. Оттогаш, брзината на имплементација на нови решенија и архитектонски промени во сите системи и потсистеми само добива на интензитет.

Во тие години, системот за размена работеше на висококвалитетен хардвер - ултра доверливи сервери HP Superdome 9000 (изградени на PA-RISC), во која апсолутно сè беше дуплирано: влезно/излезни потсистеми, мрежа, RAM (всушност, имаше RAID низа RAM), процесори (жешко заменливи). Беше можно да се смени која било компонента на серверот без да се запре машината. Се потпиравме на овие уреди и сметавме дека практично не се безбедни. Оперативниот систем беше HP UX систем сличен на Unix.

Но, од околу 2010 година, се појави феномен наречен високофреквентно тргување (HFT), или високофреквентно тргување - едноставно кажано, берзански роботи. За само 2,5 години, оптоварувањето на нашите сервери се зголеми за 140 пати.

Беше невозможно да се издржи таков товар со старата архитектура и опрема. Требаше некако да се прилагодиме.

почеток

Барањата до системот за размена може да се поделат на два вида:

• Трансакции. Ако сакате да купите долари, акции или нешто друго, испраќате трансакција до системот за тргување и добивате одговор за успехот.
• Барања за информации. Ако сакате да ја дознаете моменталната цена, погледнете ја книгата за нарачки или индексите, а потоа испратете барања за информации.

Шематски, јадрото на системот може да се подели на три нивоа:

• Ниво на клиент, на кое работат брокери и клиенти. Сите тие комуницираат со серверите за пристап.
• Гејтвеј серверите се сервери за кеширање кои локално ги обработуваат сите барања за информации. Дали сакате да знаете по која цена моментално се тргуваат акциите на Сбербанк? Барањето оди до серверот за пристап.
• Но, ако сакате да купите акции, тогаш барањето оди до централниот сервер (Trade Engine). Постои еден таков сервер за секој тип на пазар, тие играат витална улога, токму за нив го создадовме овој систем.

Јадрото на системот за тргување е паметна база на податоци во меморијата во која сите трансакции се трансакции за размена. Основата беше напишана во C, единствените надворешни зависности беа библиотеката libc и воопшто немаше динамична распределба на меморијата. За да се намали времето за обработка, системот започнува со статички сет на низи и со статичко преместување на податоци: прво, сите податоци за тековниот ден се вчитуваат во меморијата и не се врши дополнителен пристап на дискот, целата работа се врши само во меморијата. Кога системот ќе стартува, сите референтни податоци се веќе подредени, така што пребарувањето работи многу ефикасно и трае малку време во траењето. Сите табели се направени со наметливи списоци и стебла за динамички структури на податоци, така што тие не бараат распределба на меморијата при извршување.

Ајде накратко да ја разгледаме историјата на развојот на нашиот систем за тргување и клириншка.
Првата верзија на архитектурата на системот за тргување и расчистување беше изградена на таканаречената интеракција Unix: се користеа споделена меморија, семафори и редици, и секој процес се состоеше од една нишка. Овој пристап беше широко распространет во раните 1990-ти.

Првата верзија на системот содржеше две нивоа на Gateway и централен сервер на системот за тргување. Работниот тек беше вака:

• Клиентот испраќа барање, кое стигнува до Портата. Ја проверува валидноста на форматот (но не и самите податоци) и ги отфрла неточните трансакции.
• Доколку е испратено барање за информации, тоа се извршува локално; ако зборуваме за трансакција, тогаш таа се пренасочува на централниот сервер.
• Моторот за тргување потоа ја обработува трансакцијата, ја модифицира локалната меморија и испраќа одговор на трансакцијата и самата трансакција за репликација користејќи посебен мотор за репликација.
• Портата го прима одговорот од централниот јазол и го проследува до клиентот.
• По некое време, Gateway ја прима трансакцијата преку механизмот за репликација и овој пат ја извршува локално, менувајќи ги структурите на податоци, така што следните барања за информации ги прикажуваат најновите податоци.

Всушност, тој опишува модел на репликација во кој Gateway целосно ги реплицираше дејствата извршени во системот за тргување. Посебен канал за репликација обезбеди трансакциите да се извршуваат по ист редослед низ повеќекратните пристапни јазли.

Бидејќи кодот беше со една нишка, се користеше класична шема со процесни вилушки за опслужување на многу клиенти. Сепак, беше многу скапо да се раздели целата база на податоци, па се користеа лесни сервисни процеси кои собираа пакети од TCP сесиите и ги пренесуваа во една редица (SystemV Message Queue). Gateway и Trade Engine работеа само со оваа редица, земајќи трансакции од таму за извршување. Веќе не беше можно да се испрати одговор на него, бидејќи не беше јасно кој сервисен процес треба да го прочита. Така, прибегнавме кон еден трик: секој процес со чаталест создаваше редица за одговор за себе, и кога барањето дојде во дојдовната редица, веднаш беше додадена ознака за редот за одговор.

Постојаното копирање на големи количини на податоци од редица до редица создаваше проблеми, особено типични за барања за информации. Затоа, користевме уште еден трик: покрај редот за одговор, секој процес создаваше и споделена меморија (SystemV Shared Memory). Самите пакети беа ставени во него, а само ознака беше зачувана во редот, овозможувајќи човек да го пронајде оригиналниот пакет. Ова помогна да се складираат податоците во кешот на процесорот.

SystemV IPC вклучува алатки за прегледување на состојбата на редот, меморијата и објектите на семафорот. Активно го користевме ова за да разбереме што се случува во системот во одреден момент, каде се акумулираат пакетите, што е блокирано итн.

Првите модернизации

Како прво, се ослободивме од портата со еден процес. Неговиот значаен недостаток беше тоа што можеше да се справи или со една трансакција за репликација или со едно барање за информации од клиент. И како што се зголемува оптоварувањето, на Gateway ќе му треба подолго време за да ги обработи барањата и нема да може да го обработи протокот на репликација. Дополнително, ако клиентот испрати трансакција, тогаш треба само да ја проверите нејзината валидност и да ја проследите понатаму. Затоа, го заменивме единечниот процес Gateway со повеќе компоненти кои можат да работат паралелно: информации со повеќе нишки и процеси на трансакции кои работат независно еден од друг на заедничка мемориска област користејќи RW заклучување. И во исто време воведовме процеси за испраќање и репликација.

Влијанието на тргувањето со висока фреквенција

Горенаведената верзија на архитектурата постоеше до 2010 година. Во меѓувреме, повеќе не бевме задоволни од перформансите на серверите на HP Superdome. Покрај тоа, архитектурата PA-RISC беше практично мртва; продавачот не понуди никакви значајни ажурирања. Како резултат на тоа, почнавме да се движиме од HP UX/PA RISC на Linux/x86. Транзицијата започна со адаптација на пристапните сервери.

Зошто моравме повторно да ја менуваме архитектурата? Факт е дека тргувањето со висока фреквенција значително го промени профилот на оптоварување на јадрото на системот.

Да речеме дека имаме мала трансакција која предизвика значителна промена на цената - некој купил половина милијарда долари. По неколку милисекунди, сите учесници на пазарот го забележуваат ова и почнуваат да прават корекција. Секако, барањата се редат во огромна редица, што на системот ќе му треба долго време да ги расчисти.

Во овој интервал од 50 ms, просечната брзина е околу 16 илјади трансакции во секунда. Ако го намалиме прозорецот на 20 ms, добиваме просечна брзина од 90 илјади трансакции во секунда, со 200 илјади трансакции на врвот. Со други зборови, оптоварувањето не е константно, со ненадејни рафали. И редот на барања мора секогаш да се обработува брзо.

Но, зошто воопшто има ред? Така, во нашиот пример, многу корисници ја забележаа промената на цената и соодветно испратија трансакции. Доаѓаат до Gateway, тој ги серијализира, поставува одреден ред и ги испраќа на мрежата. Рутерите ги мешаат пакетите и ги проследуваат. Чиј пакет пристигна прв, таа трансакција „победи“. Како резултат на тоа, клиентите на размена почнаа да забележуваат дека ако истата трансакција е испратена од неколку портали, тогаш се зголемуваат шансите за нејзина брза обработка. Наскоро, роботите за размена почнаа да го бомбардираат Гејтвеј со барања, и се појави лавина од трансакции.

Нов круг на еволуција

По опсежно тестирање и истражување, се префрливме на кернелот на оперативниот систем во реално време. За ова го избравме RedHat Enterprise MRG Linux, каде што MRG значи мрежа за пораки во реално време. Предноста на закрпите во реално време е што тие го оптимизираат системот за најбрзо можно извршување: сите процеси се наредени во редица FIFO, јадрата може да се изолира, нема исфрлања, сите трансакции се обработуваат во строга низа.

Црвено - работа со редица во редовно јадро, зелено - работа во кернел во реално време.

Но, постигнувањето ниска латентност на редовните сервери не е толку лесно:

• Режимот SMI, кој во архитектурата x86 е основа за работа со важни периферни уреди, многу пречи. Обработката на сите видови хардверски настани и управувањето со компонентите и уредите се врши од фирмверот во таканаречениот транспарентен SMI режим, во кој оперативниот систем воопшто не гледа што прави фирмверот. Како по правило, сите големи продавачи нудат специјални екстензии за сервери на фирмверот што овозможуваат намалување на количината на обработка на SMI.
• Не треба да има динамична контрола на фреквенцијата на процесорот, тоа доведува до дополнително застој.
• Кога дневникот на датотечниот систем е исфрлен, во кернелот се случуваат одредени процеси кои предизвикуваат непредвидливи одложувања.
• Треба да обрнете внимание на работи како што се афинитет на процесорот, афинитет на прекини, NUMA.

Морам да кажам дека темата за поставување хардвер и кернел Линукс за обработка во реално време заслужува посебна статија. Потрошивме многу време експериментирајќи и истражувајќи пред да постигнеме добар резултат.

Кога се префрлавме од PA-RISC серверите на x86, практично не моравме многу да го менуваме системскиот код, само го приспособивме и реконфигуриравме. Во исто време, поправивме неколку грешки. На пример, брзо се појавија последиците од фактот дека PA RISC беше Big ендијански систем, а x86 беше мал ендијански систем: на пример, податоците беа прочитани погрешно. Посложената грешка беше што ја користи PA RISC постојано доследно (Секвенцијално конзистентно) пристап до меморија, додека x86 може да ги преуреди операциите за читање, така што кодот што беше апсолутно валиден на една платформа стана скршен на друга.

По префрлањето на x86, перформансите се зголемија речиси трипати, просечното време за обработка на трансакциите се намали на 60 μs.

Ајде сега да погледнеме подетално кои клучни промени се направени во архитектурата на системот.

Жешка резерва еп

Кога се префрлавме на сервери за стоки, бевме свесни дека тие се помалку доверливи. Затоа, при креирањето на нова архитектура, априори ја претпоставивме можноста за неуспех на еден или повеќе јазли. Затоа, беше потребен жежок систем на подготвеност кој може многу брзо да се префрли на резервни машини.

Покрај тоа, имаше и други барања:

• Во никој случај не треба да ги губите обработените трансакции.
• Системот мора да биде апсолутно транспарентен за нашата инфраструктура.
• Клиентите не треба да гледаат испуштени врски.
• Резервациите не треба да воведат значително доцнење бидејќи тоа е критичен фактор за размената.

Кога креиравме жежок систем на подготвеност, таквите сценарија не ги разгледувавме како двојни неуспеси (на пример, мрежата на еден сервер престана да работи и главниот сервер замрзна); не ја разгледа можноста за грешки во софтверот бидејќи тие се идентификувани при тестирањето; и не ја разгледал неправилната работа на хардверот.

Како резултат на тоа, дојдовме до следнава шема:

• Главниот сервер директно комуницираше со серверите на Gateway.
• Сите трансакции примени на главниот сервер веднаш беа реплицирани на резервниот сервер преку посебен канал. Арбитерот (гувернерот) го координирал префрлувањето доколку се појават некакви проблеми.

  

• Главниот сервер ја обработуваше секоја трансакција и чекаше потврда од резервниот сервер. За да го одржиме доцнењето на минимум, избегнавме да чекаме да заврши трансакцијата на резервниот сервер. Бидејќи времето потребно за трансакцијата да патува низ мрежата беше споредливо со времето на извршување, не беше додадена дополнителна латентност.
• Можевме само да го провериме статусот на обработка на главниот и резервниот сервер за претходната трансакција, а статусот на обработка на тековната трансакција беше непознат. Бидејќи сè уште користевме процеси со една нишка, чекањето одговор од Backup ќе го забави целиот процес на процесирање, па направивме разумен компромис: го проверивме резултатот од претходната трансакција.

Шемата функционираше на следниов начин.

Да речеме дека главниот сервер престанува да реагира, но Gateways продолжуваат да комуницираат. Настанува истек на време на резервниот сервер, тој контактира со гувернерот, кој му ја доделува улогата на главниот сервер и сите портали се префрлаат на новиот главен сервер.

Ако главниот сервер се врати онлајн, тој исто така предизвикува внатрешен истек на време, бидејќи немало повици до серверот од Gateway одредено време. Потоа му се обраќа и на гувернерот, а тој го исклучува од шемата. Како резултат на тоа, размената работи со еден сервер до крајот на периодот на тргување. Бидејќи веројатноста за неуспех на серверот е прилично мала, оваа шема се сметаше за сосема прифатлива; не содржи сложена логика и беше лесна за тестирање.

Да се ​​продолжи.

Извор: www.habr.com