Развитието на архитектурата на системата за търговия и клиринг на Московската борса. Част 1

Здравейте всички! Казвам се Сергей Костанбаев, на борсата разработвам ядрото на системата за търговия.

Когато холивудските филми показват Нюйоркската фондова борса, тя винаги изглежда така: тълпи от хора, всеки вика нещо, размахва листове, настава пълен хаос. Това никога не се е случвало тук, на Московската борса, тъй като търговията се извършва по електронен път от самото начало и се базира на две основни платформи – Spectra (форекс пазар) и ASTS (валутен, фондов и паричен пазар). И днес искам да говоря за еволюцията на архитектурата на системата за търговия и клиринг ASTS, за различни решения и открития. Историята ще е дълга, затова се наложи да я разделя на две части.

Ние сме една от малкото борси в света, която търгува активи от всички класове и предоставя пълна гама от борсови услуги. Например миналата година бяхме на второ място в света по обем на търговия с облигации, 25-то място сред всички фондови борси, 13-то място по капитализация сред публичните борси.

За професионалните участници в търговията такива параметри като време за реакция, стабилност на разпределението на времето (трептене) и надеждност на целия комплекс са критични. В момента обработваме десетки милиони транзакции на ден. Обработката на всяка транзакция от ядрото на системата отнема десетки микросекунди. Разбира се, мобилните оператори в навечерието на Нова година или самите търсачки имат по-голямо натоварване от нашето, но по отношение на натоварването, съчетано с горепосочените характеристики, малцина могат да се сравняват с нас, струва ми се. В същото време за нас е важно системата да не се забавя нито за секунда, да работи абсолютно стабилно и всички потребители да са в равни условия.

Малко история

През 1994 г. австралийската система ASTS стартира на Московската междубанкова валутна борса (MICEX) и от този момент може да се отчита руската история на електронната търговия. През 1998 г. борсовата архитектура беше модернизирана, за да се въведе интернет търговия. Оттогава скоростта на внедряване на нови решения и архитектурни промени във всички системи и подсистеми само набира скорост.

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

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

Беше невъзможно да се издържи такова натоварване със старата архитектура и оборудване. Беше необходимо по някакъв начин да се адаптираме.

Начало

Заявките към системата за обмен могат да бъдат разделени на два типа:

• Транзакции. Ако искате да купите долари, акции или нещо друго, изпращате транзакция към системата за търговия и получавате отговор за успех.
• Заявки за информация. Ако искате да разберете текущата цена, прегледайте книгата с поръчки или индекси, след което изпратете заявки за информация.

Схематично ядрото на системата може да бъде разделено на три нива:

• Клиентското ниво, на което работят брокерите и клиентите. Всички те взаимодействат със сървърите за достъп.
• Gateway сървърите са кеширащи сървъри, които локално обработват всички заявки за информация. Искате ли да знаете на каква цена се търгуват акциите на Сбербанк в момента? Заявката отива към сървъра за достъп.
• Но ако искате да закупите акции, тогава заявката отива до централния сървър (Trade Engine). Има един такъв сървър за всеки тип пазар, те играят жизненоважна роля, за тях създадохме тази система.

Ядрото на системата за търговия е интелигентна база данни в паметта, в която всички транзакции са обменни транзакции. Базата беше написана на C, единствените външни зависимости бяха библиотеката libc и изобщо нямаше динамично разпределение на паметта. За да се намали времето за обработка, системата започва със статичен набор от масиви и със статично преместване на данни: първо всички данни за текущия ден се зареждат в паметта и не се извършва допълнителен достъп до диска, цялата работа се извършва само в паметта. Когато системата стартира, всички справочни данни вече са сортирани, така че търсенето работи много ефективно и отнема малко време по време на изпълнение. Всички таблици са направени с натрапчиви списъци и дървета за динамични структури от данни, така че да не изискват разпределяне на памет по време на изпълнение.

Нека прегледаме накратко историята на развитието на нашата система за търговия и клиринг.
Първата версия на архитектурата на системата за търговия и клиринг беше изградена върху така нареченото Unix взаимодействие: използваха се споделена памет, семафори и опашки и всеки процес се състоеше от една нишка. Този подход беше широко разпространен в началото на 1990-те години.

Първата версия на системата съдържа две нива на Gateway и централен сървър на системата за търговия. Процесът на работа беше следният:

• Клиентът изпраща заявка, която достига до Gateway. Той проверява валидността на формата (но не и самите данни) и отхвърля неправилни транзакции.
• Ако е изпратена заявка за информация, тя се изпълнява локално; ако говорим за транзакция, тогава тя се пренасочва към централния сървър.
• След това механизмът за търговия обработва транзакцията, модифицира локалната памет и изпраща отговор на транзакцията и самата транзакция за репликация, използвайки отделна машина за репликация.
• Шлюзът получава отговора от централния възел и го препраща към клиента.
• След известно време шлюзът получава транзакцията чрез механизма за репликация и този път я изпълнява локално, променяйки своите структури от данни, така че следващите заявки за информация да показват най-новите данни.

Всъщност той описва модел на репликация, при който 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 ms средната скорост е около 16 хиляди транзакции в секунда. Ако намалим прозореца до 20 ms, получаваме средна скорост от 90 хиляди транзакции в секунда, с 200 хиляди транзакции в пика. С други думи, натоварването не е постоянно, с внезапни изблици. И опашката от заявки винаги трябва да се обработва бързо.

Но защо изобщо има опашка? Така че в нашия пример много потребители забелязаха промяната в цената и изпратиха транзакции съответно. Те идват в Gateway, той ги сериализира, задава определен ред и ги изпраща в мрежата. Рутерите разбъркват пакетите и ги препращат. Чийто пакет пристигна пръв, тази транзакция „печели“. В резултат на това клиентите на борсата започнаха да забелязват, че ако една и съща транзакция е изпратена от няколко шлюза, тогава шансовете за нейната бърза обработка се увеличават. Скоро обменните роботи започнаха да бомбардират Gateway със заявки и се появи лавина от транзакции.

Нов кръг от еволюция

След задълбочено тестване и проучване преминахме към ядрото на операционната система в реално време. За това избрахме RedHat Enterprise MRG Linux, където MRG означава мрежа за съобщения в реално време. Предимството на пачовете в реално време е, че те оптимизират системата за възможно най-бързо изпълнение: всички процеси са подредени в FIFO опашка, ядрата могат да бъдат изолирани, няма изхвърляния, всички транзакции се обработват в стриктна последователност.

Червено - работа с опашка в обикновено ядро, зелено - работа в ядро ​​в реално време.

Но постигането на ниска латентност на обикновени сървъри не е толкова лесно:

• Силно пречи режимът SMI, който в x86 архитектурата е основа за работа с важни периферни устройства. Обработката на всякакви хардуерни събития и управлението на компоненти и устройства се извършва от фърмуера в така наречения прозрачен SMI режим, при който операционната система изобщо не вижда какво прави фърмуерът. По правило всички големи доставчици предлагат специални разширения за сървъри на фърмуера, които позволяват намаляване на обема на SMI обработка.
• Не трябва да има динамичен контрол на честотата на процесора, това води до допълнителен престой.
• Когато регистрационният файл на файловата система се изчисти, в ядрото възникват определени процеси, които причиняват непредвидими забавяния.
• Трябва да обърнете внимание на неща като афинитет на процесора, афинитет на прекъсване, NUMA.

Трябва да кажа, че темата за настройка на хардуера и ядрото на Linux за обработка в реално време заслужава отделна статия. Прекарахме много време в експерименти и проучвания, преди да постигнем добър резултат.

При преминаването от PA-RISC сървъри към x86 практически не се наложи да променяме много системния код, просто го адаптирахме и преконфигурирахме. В същото време поправихме няколко грешки. Например, бързо се появиха последствията от факта, че PA RISC беше Big endian система, а x86 беше Little endian система: например данните бяха прочетени неправилно. По-сложният бъг беше, че PA RISC използва последователно последователен (Последователно последователен) достъп до паметта, докато x86 може да пренарежда операциите за четене, така че кодът, който е бил абсолютно валиден на една платформа, се е повредил на друга.

След преминаване към x86 производителността се увеличи почти три пъти, средното време за обработка на транзакция намаля до 60 μs.

Нека сега разгледаме по-подробно какви ключови промени са направени в системната архитектура.

Горещ резервен епос

Когато преминахме към стокови сървъри, бяхме наясно, че те са по-малко надеждни. Следователно, когато създаваме нова архитектура, ние априори приехме възможността за повреда на един или повече възли. Следователно беше необходима система с горещ режим на готовност, която може много бързо да превключи към резервни машини.

Освен това имаше и други изисквания:

• При никакви обстоятелства не трябва да губите обработени транзакции.
• Системата трябва да е абсолютно прозрачна за нашата инфраструктура.
• Клиентите не трябва да виждат прекъснати връзки.
• Резервациите не трябва да водят до значително забавяне, защото това е критичен фактор за обмена.

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

В резултат на това стигнахме до следната схема:

• Основният сървър взаимодейства директно със сървърите на Gateway.
• Всички транзакции, получени на главния сървър, бяха незабавно копирани на резервния сървър чрез отделен канал. Арбитърът (губернаторът) координира смяната, ако възникнат проблеми.

  

• Основният сървър обработваше всяка транзакция и чакаше потвърждение от резервния сървър. За да сведем забавянето до минимум, избягвахме да чакаме транзакцията да завърши на резервния сървър. Тъй като времето, необходимо на една транзакция да премине през мрежата, беше сравнимо с времето за изпълнение, не беше добавено допълнително забавяне.
• Можехме да проверим само състоянието на обработка на главния и резервния сървър за предишната транзакция, а състоянието на обработка на текущата транзакция беше неизвестно. Тъй като все още използвахме еднонишкови процеси, чакането на отговор от Backup щеше да забави целия процес на обработка, така че направихме разумен компромис: проверихме резултата от предишната транзакция.

Схемата работеше по следния начин.

Да приемем, че основният сървър спира да отговаря, но шлюзовете продължават да комуникират. Времето за изчакване възниква на резервния сървър, той се свързва с управителя, който му присвоява ролята на основен сървър и всички шлюзове преминават към новия основен сървър.

Ако основният сървър се върне онлайн, той също задейства вътрешно изчакване, тъй като не е имало повиквания към сървъра от Gateway за определено време. Тогава той също се обръща към губернатора и той го изключва от схемата. В резултат на това борсата работи с един сървър до края на периода на търговия. Тъй като вероятността от повреда на сървъра е доста ниска, тази схема се счита за доста приемлива; тя не съдържа сложна логика и е лесна за тестване.

Да продължи.

Източник: www.habr.com