Надстройка на OKEx Lightning 2.0

Система за търговия от следващо поколение, която осигурява по-бързо представяне

I. Развитие на системата за електронна търговия

Нарастващите изисквания към основните технологии на търговията с активи отразяват бързия растеж на световната финансова индустрия през първата половина на 20 век. През 50-те години купувачите и продавачите търгуват по договаряне, а цените на запитване се записват ръчно на хартия. На фона на различни видове ценни книжа и нарастващ обем на търговия, този начин за справяне с котировките постепенно създава криза с документооборота през 60-те и 70-те години поради неговата неефективност и висока цена. Нюйоркската фондова борса (NYSE) нямаше друг избор, освен да спре търговията всяка сряда и да намали часовете в други търговски дни, за да ограничи дейността си. Със своята ненадмината способност да обработват едновременно огромен брой транзакции, компютрите започнаха да влизат в игра. Безхартиен процес или електронна революция беше решаващ поврат в глобалната финансова история. Транзакциите са преминали към платформи за електронна търговия, предлагайки по-бързи и евтини операции без времеви или географски бариери.

Американската безхартийна криза през 70-те

Системи за електронна търговия се появиха в цял свят, включително Currenex на State Street, INET на HKEX, EBS Spot Ai на ICAP и LIFE CONNECT на LIFFE. Тъй като крипто активите съществуват само в електронна форма, те естествено са свързани с платформи за електронна търговия, но изискванията за крипто търговия и традиционните системи за търговия са малко по-различни. Като цяло, системата за крипто търговия трябва да притежава следните характеристики:

а. Ниска латентност и висока производителност

Латентността и производителността са ключовите показатели за измерване на ефективността на системата за търговия. Нашата основна цел е да постигнем ниска латентност и висока производителност при проектиране на търговска система.

В контекста на търговията латентността се отнася до интервал от време между заявка, получена от, и отговор, направен от система за търговия. Нарастването на обема на високочестотната търговия до голяма степен движи търсенето на пазара за ниска латентност. За да се даде възможност на високочестотните търговци да извършват кръстосана търговия на крипто борси, техните системи за търговия трябва да бъдат оборудвани с двигатели за търговия с ниска латентност за бързо обработване на поръчки и отразяване на пазарните реалности на силно конкурентния крипто пазар.

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

б. Поддържаемост и мащабируемост

В сравнение с традиционните активи, крипто цените са по-нестабилни и уязвими на глобални шокове. Тъй като системите за крипто търговия непрекъснато обработват заявки 24/7, те са проектирани да преминават възможно най-малко офлайн поддръжка. В допълнение, очевидно е, че крипто секторът претърпява бърза трансформация, тъй като различни услуги за цифрови деривати, вариращи като марж, фючърси и търговия с опции, са въведени само за едно десетилетие от неговия възход. Разпространението на иновативни услуги повиши изискванията за поддържане и мащабируемост на системите за крипто търговия.

II. OKEx Lightning System 2.0: Lightspeed Performance

Като един от най-добрите световни борси за цифрови активи, OKEx обслужва десетки хиляди потребители със своите цялостни крипто активи и деривативни продукти, със среден дневен обем на търговия от милиарди щатски долари. Като лидер в индустрията, ние поставихме изключително високи стандарти за нашите търговски системи. В допълнение към надстройката на нашата система за търговия през август 2018 г., ние внедрихме нашата система от следващо поколение Lightning 2.0 с водеща производителност в света след множество надстройки. Основните характеристики на ъпгрейда на Lightning 2.0 са както следва:

Рамка за надстройка на Lightning 2.0

1. Мемоизиране


На ранния етап на разработка на системите за крипто търговия, платформите обикновено извличат подробности за поръчката за участие на контрагента, като автоматично го съпоставят в базата данни, докато поръчката изтече или бъде попълнена. След това системата изчислява търгуваната сума и генерира запис на транзакция след съвпадението. Този метод може да осигури последователност на данните, но не успя да се справи с много пазарни заявки едновременно поради дългото време за обработка.

Нашата система за търговия от следващо поколение, Lightning 2.0, е приела най-новата техника за съвпадение в паметта, при която нашата система съхранява данни за поръчки в паметта в механизма за съвпадение на поръчките по време на автоматичното съвпадение и по-рядък достъп до базата данни по време на търговия. Всички съвпадащи резултати и междинни данни също се съхраняват в паметта, което може да намали количеството входящи входове и изходи, което значително увеличава скоростта на съвпадение на поръчката.

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

Освен това съвременните централни процесори (CPU) осъществяват достъп до данните в паметта с по-ниска скорост от очакваната. Според a тест, отнема само 1/7 от времето за извличане на данни от L2 кеша на процесор в сравнение с техниката за съвпадение в паметта. За да намалите допълнително латентността, е важно да разберете как да използвате добре кеша на процесора. Единицата за пренос на данни е кеш линията, която обикновено е 64 байта. Докато процесорът зарежда данни в паметта, той прехвърля съседни данни в 64 байта в кеша. Съответно направихме следните подобрения в нашата система Lightning, като контролирахме разпределението на данните в паметта:

  • Контролирайте разпределението в паметта, като опаковате заедно парчета данни, които са необходими за непрекъсната обработка. След като се съберат всички данни, се изисква само първото зареждане от паметта в паметта в кеша, докато се четат множество части от данните. След това последващите четения могат да ударят кеша, за да подобрят производителността на системата.
  • Контролирайте разпределението в паметта, като поставяте данни, които могат да се променят с по-висока скорост (като данни на броячи), в различни линии на кеша. Когато множество CPU модифицират едновременно различни байтове в една кеш линия, възниква фалшиво споделяне. Например, след като CPU1 модифицира собствените си данни, CPU2 трябва да презареди цялата линия на кеша, когато прочете отново собствените си данни, тъй като данните в кеша са актуализирани. В резултат на това и двата процесора трябва да изчакат взаимно. Ето защо съхраняваме данни в различни линии на кеша чрез подложка, за да избегнем този проблем.

2. Публикуване – абониране на модел и двоичен протокол

Двата основни типа модели за съобщения са както следва:

Сравнение на Lightning 1.0 и Lightning 2.0

В модела за публикуване-абониране се използва опашка за съобщения. Когато дадена услуга трябва да поиска други услуги, информацията за заявката се капсулира в съобщение и се поставя на опашката. Други услуги ще се абонират за опашката за съобщения, за да получат информацията и да обработят заявката.

В модела заявка-отговор клиентът и сървърът са силно свързани заедно. Те трябва да бъдат на разположение по едно и също време. Клиентът може само да изчака, докато сървърът завърши обработката на заявката, което намалява скоростта му на обработка. В модела за публикуване-абониране обаче обработката на заявки е завършена, след като издателят постави съобщението в опашката. Издателят е отделен от абоната. От друга страна, ако услугата на абоната бъде прекъсната, съобщението продължава на опашката и обработката продължава, когато услугата му се възобнови, без да е необходимо издателят да изпраща повторно съобщението, като по този начин повишава надеждността на системната комуникация. Следователно този модел е приет в почти всички сценарии за подобряване на наличността и производителността на нашата система Lightning 2.0.

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

Два често срещани типа формати на съобщенията: текстови & двоичен

Недостатъците на текстовия комуникационен протокол са очевидни. Той лесно генерира грешки и отнема широчина на честотната лента, когато се прави синтактичен анализ на голям текстов файл, което не работи добре за системи за търговия, които са изключително чувствителни към проблеми с ефективността и производителността. Двоичен протокол обаче може лесно да се използва за синтактичен анализ, така че да генерира по-добра производителност. Следователно ние приехме двоичния протокол в нашата система Lightning 2.0.

3. Хоризонтално мащабиране

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

Първото съображение е състезанието с данни. Въпреки че добавянето на сървъри може да подобри способността на системата да обработва паралелно данни, нейният капацитет за обработка не може да бъде ефективно подобрен, ако възникне неразумно разпределение, тъй като паралелните изчисления могат да накарат сървърите му да се надпреварват често за едни и същи данни.

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

4. Мащабиране на системата

Основен начин за подобряване на поддържаемостта и мащабируемостта на системата за търговия е отделянето на нейната функционалност. В това надстройване ние допълнително разделяме функционалността на нашата система на 3 модула, а именно съвпадение на поръчки, брояч и контрол на риска. Всеки модул съдържа свои собствени вътрешни данни и статус. По-конкретно, модулът за съвпадение на поръчките е отговорен за поддържането на книгата с поръчки, а модулът брояч съхранява данни за позициите и салдата по сметките, докато модулът за контрол на риска изпълнява функцията за управление на риска.

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

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

В резултат на това модулите на нашата система Lightning 2.0 са проектирани да запазват собствените си данни, а не да споделят данни помежду си. Ако вътрешното състояние на модулите се промени, промяната ще бъде капсулирана в събитие и поставена в цикъла на събитието. Това може да намали свързването и конкуренцията между системните модули и те могат да комуникират помежду си с оптимална скорост след капсулирането на събитието, което значително подобрява скоростта на комуникация на нашата система.

III. Изпълнение на данни на Lightning 2.0

Завършихме цялостно надграждане на нашата система Lightning 2.0 през втората половина на 2019 г. Как се подобри нейната производителност в сравнение с Lightning 1.0?

Ето последните статистически данни за нашето тестване на сървъри в Хонконг през ноември:

По отношение на капацитета за обработка на поръчките, нашата система има максимален капацитет за обработка на поръчки от 100 000 txn / s, сравним с основните системи за търговия на глобалния пазар на акции.

Следните три показателя се използват за тестване на латентността на системата:

Три често срещани индикатора за тестване на латентността: ACK, Live и Cancel

Използвахме тестови данни от септември и ноември, за да сравним ефективността на системата за търговия преди надстройката и след надстройката (вижте по-долу). Както е посочено по-долу, средната латентност на ACK е намаляла от 50 ms на 25 ms, средната латентност на живо е нараснала от 134 ms на 63 ms, а средната латентност на Cancel е намалена от 230 ms на 180 ms.

Това показва, че нашата система за търговия Lightning 2.0 има по-ниска латентност.

Преди надстройка / след надстройка

IV. Лидер в индустрията в технологиите

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

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

Следвайте OKEx на:

Steemit: https://steemit.com/@okex-official

Уебсайт: https://www.okex.com

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me
Like this post? Please share to your friends:
Adblock
detector
map