Здраво свима! Моје име је Сергеј Костанбајев, на Берзи развијам језгро система трговања.
Када холивудски филмови приказују Њујоршку берзу, то увек изгледа овако: гомиле људи, сви нешто вичу, машу папирима, прави се потпуни хаос. Ово се никада није десило овде на Московској берзи, јер се трговање од самог почетка одвија електронским путем и базира се на две главне платформе – Спецтра (форек тржиште) и АСТС (девизно, берзанско и тржиште новца). И данас желим да причам о еволуцији архитектуре АСТС система трговања и клиринга, о разним решењима и налазима. Прича ће бити дуга, па сам морао да је поделим на два дела.
Ми смо једна од ретких берзи у свету која тргује имовином свих класа и пружа читав низ услуга размене. На пример, прошле године смо били на другом месту у свету по обиму трговања обвезницама, на 25. месту међу свим берзама, на 13. месту по капитализацији међу јавним берзама.
За професионалне учеснике у трговању, такви параметри као што су време одзива, стабилност временске дистрибуције (јиттер) и поузданост читавог комплекса су критични. Тренутно обрађујемо десетине милиона трансакција дневно. Обрада сваке трансакције од стране језгра система траје десетине микросекунди. Наравно, мобилни оператери у новогодишњој ноћи или сами претраживачи имају већи обим посла од наших, али по оптерећености, уз горе наведене карактеристике, мало ко може да се пореди са нама, чини ми се. При томе нам је важно да систем не успорава ни на секунду, ради апсолутно стабилно, а сви корисници су равноправни.
Мало историје
Године 1994. аустралијски АСТС систем је покренут на Московској међубанкарској берзи валута (МИЦЕКС) и од тог тренутка се може рачунати руска историја електронског трговања. 1998. године архитектура берзе је модернизована да би се увела интернет трговина. Од тада, брзина имплементације нових решења и архитектонских промена у свим системима и подсистемима само добија на замаху.
Тих година, систем размене је радио на врхунском хардверу - ултра-поузданим ХП Супердоме 9000 серверима (изграђеним на), у којој је дуплирано апсолутно све: улазно-излазни подсистеми, мрежа, РАМ (у ствари, постојао је РАИД низ РАМ-а), процесори (заменљиви на врућу). Било је могуће променити било коју компоненту сервера без заустављања машине. Ослонили смо се на ове уређаје и сматрали их практично безопасним. Оперативни систем је био ХП УКС систем сличан Уник-у.
Али од отприлике 2010. године појавио се феномен који се зове високофреквентно трговање (ХФТ), или високофреквентно трговање – једноставно речено, берзански роботи. За само 2,5 године оптерећење на нашим серверима се повећало 140 пута.
Било је немогуће издржати такво оптерећење са старом архитектуром и опремом. Требало се некако прилагодити.
почетак
Захтеви за систем размене могу се поделити у два типа:
- Трансакције. Ако желите да купите доларе, акције или нешто друго, шаљете трансакцију у систем трговања и добијате одговор о успеху.
- Захтеви за информацијама. Ако желите да сазнате тренутну цену, погледате књигу налога или индексе, а затим пошаљите захтеве за информацијама.
Шематски, језгро система се може поделити на три нивоа:
- Ниво клијента, на коме раде брокери и клијенти. Сви они комуницирају са приступним серверима.
- Гатеваи сервери су сервери за кеширање који локално обрађују све захтеве за информацијама. Да ли желите да знате по којој цени се тренутно тргује акцијама Сбербанке? Захтев иде на приступни сервер.
- Али ако желите да купите акције, онда захтев иде на централни сервер (Траде Енгине). За сваку врсту тржишта постоји по један такав сервер, они играју виталну улогу, за њих смо креирали овај систем.
Срж система трговања је паметна база података у меморији у којој су све трансакције трансакције размене. База је написана у Ц, једине спољне зависности биле су либц библиотека и уопште није било динамичке алокације меморије. Да би се смањило време обраде, систем почиње са статичким скупом низова и са статичким премештањем података: прво се сви подаци за текући дан учитавају у меморију и не врши се даљи приступ диску, сав рад се обавља само у меморији. Када се систем покрене, сви референтни подаци су већ сортирани, тако да претрага ради веома ефикасно и траје мало времена. Све табеле су направљене са наметљивим листама и стаблима за динамичке структуре података, тако да не захтевају доделу меморије током извршавања.
Хајде да укратко прођемо кроз историју развоја нашег система трговања и клиринга.
Прва верзија архитектуре система трговања и клиринга изграђена је на такозваној Уник интеракцији: коришћена је заједничка меморија, семафори и редови, а сваки процес се састојао од једне нити. Овај приступ је био широко распрострањен почетком 1990-их.
Прва верзија система је садржала два нивоа Гатеваи-а и централни сервер система трговања. Ток рада је био овакав:
- Клијент шаље захтев који стиже до мрежног пролаза. Проверава валидност формата (али не и самих података) и одбија нетачне трансакције.
- Ако је захтев за информацијама послат, он се извршава локално; ако говоримо о трансакцији, онда се она преусмерава на централни сервер.
- Трговачки механизам затим обрађује трансакцију, модификује локалну меморију и шаље одговор на трансакцију и саму трансакцију за репликацију користећи посебан механизам за репликацију.
- Гатеваи прима одговор од централног чвора и прослеђује га клијенту.
- Након неког времена, мрежни пролаз прима трансакцију путем механизма репликације, и овог пута је извршава локално, мењајући своје структуре података тако да следећи захтеви за информацијама приказују најновије податке.
У ствари, он описује модел репликације у којем је Гатеваи у потпуности реплицирао радње извршене у систему трговања. Одвојени канал за репликацију је осигурао да се трансакције извршавају истим редоследом на више приступних чворова.
Пошто је код био једнонитни, класична шема са процесним виљушкама је коришћена за опслуживање многих клијената. Међутим, било је веома скупо раздвојити целу базу података, па су коришћени лаки сервисни процеси који су прикупљали пакете са ТЦП сесија и пренели их у један ред (СистемВ Мессаге Куеуе). Гатеваи и Траде Енгине су радили само са овим редом, узимајући трансакције одатле за извршење. Више није било могуће послати одговор на њега, јер није било јасно који сервисни процес треба да га прочита. Зато смо прибегли трику: сваки рачвани процес креирао је ред одговора за себе, а када је захтев дошао у долазни ред, одмах му је додата ознака за ред одговора.
Константно копирање великих количина података из реда у ред је створило проблеме, посебно типичне за захтеве за информацијама. Стога смо користили још један трик: поред реда за одговоре, сваки процес је креирао и заједничку меморију (СистемВ Схаред Мемори). Сами пакети су били смештени у њега, а само је ознака била сачувана у реду, омогућавајући проналажење оригиналног пакета. Ово је помогло да се подаци чувају у кешу процесора.
СистемВ ИПЦ укључује услужне програме за преглед стања реда, меморије и објеката семафора. Ово смо активно користили да бисмо разумели шта се дешава у систему у одређеном тренутку, где су се пакети акумулирали, шта је блокирано итд.
Прве надоградње
Пре свега, решили смо се Гатеваи-а са једним процесом. Његов значајан недостатак је био то што је могао да обради или једну трансакцију репликације или један захтев за информацијама од клијента. А како се оптерећење повећава, гејтвеју ће бити потребно више времена да обради захтеве и неће моћи да обради ток репликације. Поред тога, ако је клијент послао трансакцију, потребно је само да проверите њену валидност и да је проследите даље. Због тога смо заменили један процес мрежног пролаза са више компоненти које могу да раде паралелно: вишенитне информације и трансакцијски процеси који се покрећу независно један од другог на дељеној меморијској области користећи РВ закључавање. У исто време смо увели процесе отпреме и репликације.
Утицај високофреквентног трговања
Горња верзија архитектуре постојала је до 2010. године. У међувремену, више нисмо били задовољни перформансама ХП Супердоме сервера. Поред тога, ПА-РИСЦ архитектура је практично била мртва; продавац није понудио никаква значајна ажурирања. Као резултат тога, почели смо да прелазимо са ХП УКС/ПА РИСЦ на Линук/к86. Транзиција је почела адаптацијом приступних сервера.
Зашто смо морали поново да мењамо архитектуру? Чињеница је да је високофреквентно трговање значајно променило профил оптерећења на језгру система.
Рецимо да имамо малу трансакцију која је изазвала значајну промену цене – неко је купио пола милијарде долара. Након неколико милисекунди, сви учесници на тржишту то примећују и почињу да врше корекцију. Наравно, захтеви се поређају у огромном реду, за који ће систему требати доста времена да га очисти.
У овом интервалу од 50 мс, просечна брзина је око 16 хиљада трансакција у секунди. Ако смањимо прозор на 20 мс, добијамо просечну брзину од 90 хиљада трансакција у секунди, са 200 хиљада трансакција на врхунцу. Другим речима, оптерећење није константно, са изненадним рафалима. А ред захтева увек мора бити брзо обрађен.
Али зашто уопште постоји ред? Дакле, у нашем примеру, многи корисници су приметили промену цене и послали трансакције у складу са тим. Дођу у Гатеваи, он их серијализује, постави одређени ред и пошаље их у мрежу. Рутери мешају пакете и прослеђују их даље. Чији је пакет први стигао, та трансакција је „победила“. Као резултат тога, клијенти размене су почели да примећују да ако је иста трансакција послата са неколико мрежних пролаза, онда су се шансе за њену брзу обраду повећале. Убрзо су роботи за размену почели да бомбардују Гатеваи захтевима и подигла се лавина трансакција.
Нови круг еволуције
Након опсежног тестирања и истраживања, прешли смо на кернел оперативног система у реалном времену. За ово смо изабрали РедХат Ентерприсе МРГ Линук, где МРГ означава мрежу за размену порука у реалном времену. Предност закрпа у реалном времену је у томе што оптимизују систем за најбрже могуће извршење: сви процеси су поређани у ФИФО реду, језгра се могу изоловати, нема избацивања, све трансакције се обрађују у строгом редоследу.
Црвена - рад са редом у обичном кернелу, зелена - рад у језгру у реалном времену.
Али постизање ниске латенције на редовним серверима није тако лако:
- СМИ режим, који у архитектури к86 представља основу за рад са важним периферијама, у великој мери омета. Обраду свих врста хардверских догађаја и управљање компонентама и уређајима врши фирмвер у такозваном транспарентном СМИ режиму, у коме оперативни систем уопште не види шта фирмвер ради. По правилу, сви главни произвођачи нуде посебна проширења за сервере фирмвера која омогућавају смањење количине СМИ обраде.
- Не би требало да постоји динамичка контрола фреквенције процесора, што доводи до додатног застоја.
- Када се евиденција система датотека испразни, у кернелу се јављају одређени процеси који узрокују непредвидива кашњења.
- Морате да обратите пажњу на ствари као што су ЦПУ афинитет, афинитет прекида, НУМА.
Морам рећи да тема подешавања Линук хардвера и кернела за обраду у реалном времену заслужује посебан чланак. Провели смо доста времена експериментишући и истражујући пре него што смо постигли добар резултат.
Приликом преласка са ПА-РИСЦ сервера на к86, практично нисмо морали много да мењамо системски код, само смо га прилагодили и реконфигурисали. Истовремено смо поправили неколико грешака. На пример, последице чињенице да је ПА РИСЦ био Биг ендиан систем, а к86 био Литтле ендиан систем, брзо су се појавиле: на пример, подаци су погрешно прочитани. Тежа грешка је била коју ПА РИСЦ користи () приступ меморији, док к86 може да промени редослед операција читања, тако да је код који је био апсолутно важећи на једној платформи постао покварен на другој.
Након преласка на к86, перформансе су се повећале скоро три пута, просечно време обраде трансакције је смањено на 60 μс.
Хајде да сада ближе погледамо које су кључне промене направљене у архитектури система.
Хот резервни еп
Када смо прешли на робне сервере, били смо свесни да су они мање поуздани. Стога смо при креирању нове архитектуре а приори претпоставили могућност отказа једног или више чворова. Због тога је био потребан систем вруће приправности који би се врло брзо могао пребацити на резервне машине.
Поред тога, постојали су и други захтеви:
- Ни у ком случају не би требало да изгубите обрађене трансакције.
- Систем мора бити апсолутно транспарентан за нашу инфраструктуру.
- Клијенти не би требало да виде прекинуте везе.
- Резервације не би требало да уносе значајно одлагање јер је то критичан фактор за размену.
Приликом креирања система вруће приправности, такве сценарије нисмо сматрали двоструким кваровима (на пример, мрежа на једном серверу је престала да ради и главни сервер се замрзнуо); није разматрао могућност грешака у софтверу јер су идентификоване током тестирања; и није разматрао неисправан рад хардвера.
Као резултат, дошли смо до следеће шеме:
- Главни сервер је директно комуницирао са серверима мрежног пролаза.
- Све трансакције примљене на главном серверу су тренутно реплициране на резервни сервер преко посебног канала. Арбитар (гувернер) је координирао пребацивање ако би се појавили проблеми.
- Главни сервер је обрадио сваку трансакцију и чекао потврду од резервног сервера. Да бисмо свели кашњење на минимум, избегавали смо чекање да се трансакција заврши на резервном серверу. Пошто је време које је било потребно да трансакција прође кроз мрежу било упоредиво са временом извршења, није додато додатно кашњење.
- Могли смо само да проверимо статус обраде главног и резервног сервера за претходну трансакцију, а статус обраде тренутне трансакције је био непознат. Пошто смо још увек користили једнонитне процесе, чекање на одговор од Бацкуп-а би успорило цео ток обраде, па смо направили разуман компромис: проверили смо резултат претходне трансакције.
Шема је функционисала на следећи начин.
Рецимо да главни сервер престаје да реагује, али мрежни пролази настављају да комуницирају. На резервном серверу долази до истека времена, он контактира гувернера, који му додељује улогу главног сервера, и сви мрежни пролази прелазе на нови главни сервер.
Ако се главни сервер врати на мрежу, он такође покреће интерно временско ограничење, јер није било позива ка серверу са мрежног пролаза одређено време. Онда се и он обраћа гувернеру, а он га искључује из шеме. Као резултат тога, размена ради са једним сервером до краја периода трговања. Пошто је вероватноћа квара сервера прилично мала, ова шема се сматрала сасвим прихватљивом; није садржала сложену логику и била је лака за тестирање.
Наставити.
Извор: ввв.хабр.цом