Бул Биржанын иштешин камсыз кылган күчтүү, жогорку жүктөө системасын түзүүдөгү биздин татаал жолубуз жөнүндө узун окуянын уландысы. Биринчи бөлүгү бул жерде:
Табышмактуу ката
Көптөгөн сыноолордон кийин жаңыланган соода жана клиринг системасы ишке киргизилип, биз детективдик-мистикалык окуяны жаза турган катага туш болдук.
Негизги серверде ишке киргизилгенден көп өтпөй транзакциялардын бири ката менен иштетилди. Бирок, резервдик серверде баары жакшы болду. Көрсө, негизги серверде көрсөткүчтү эсептөөнүн жөнөкөй математикалык операциясы чыныгы аргументтен терс жыйынтык берген экен! Биз изилдөөбүздү уланттык жана SSE2 регистринде бир биттин айырмасын таптык, ал калкыма чекиттер менен иштөөдө тегеректөө үчүн жооп берет.
Тегеректөө бит топтому менен экспонентти эсептөө үчүн жөнөкөй сыноо утилитасын жаздык. Көрсө, биз колдонгон RedHat Linux версиясында катаал бит киргизилгенде математикалык функция менен иштөөдө ката бар экен. Бул тууралуу RedHatга кабарладык, бир аздан кийин биз алардан патч алдык жана аны жайылттык. Ката мындан ары пайда болгон жок, бирок бул бит кайдан келип чыкканы белгисиз эле? Функция ага жооптуу болгон fesetround Си тилинен.Биз болжолдонгон катаны издөө үчүн кодубузду кылдаттык менен талдап чыктык: бардык мүмкүн болгон жагдайларды текшердик; тегеректөө колдонулган бардык функцияларды карады; ийгиликсиз сессияны кайра чыгарууга аракет кылды; ар кандай варианттары бар ар кандай компиляторлорду колдонгон; Статикалык жана динамикалык талдоо колдонулган.
Катанын себеби табылган жок.
Андан кийин алар аппараттык жабдыктарды текшере башташты: алар процессорлорду жүктөө боюнча тестирлөө жүргүзүштү; RAM текшерилди; Биз атүгүл бир клеткадагы көп биттик катанын өтө күмөндүү сценарийи үчүн тесттерди өткөрдүк. Пайдасы жок.
Акыр-аягы, биз жогорку энергиялуу физика дүйнөсүнүн бир теориясына токтолдук: кандайдыр бир жогорку энергиялуу бөлүкчө биздин маалымат борборубузга учуп келип, корпустун дубалын тешип, процессорго тийип, триггердин илгичинин дал ошол бөлүккө жабышып калышына себеп болду. Бул абсурд теория "нейтрино" деп аталды. Эгер сиз бөлүкчөлөр физикасынан алыс болсоңуз: нейтрино дээрлик тышкы дүйнө менен өз ара аракеттенишпейт жана процессордун иштешине албетте таасир эте албайт.
Мүчүлүштүктүн себебин табуу мүмкүн болбогондуктан, “тазалоочу” сервер мүмкүн болгон учурда иштен чыгарылды.
Бир нече убакыт өткөндөн кийин, биз ысык резервдик системаны өркүндөтө баштадык: биз "жылуу резервдер" (жылуу) деп аталган асинхрондук репликаларды киргиздик. Алар ар кандай маалымат борборлорунда жайгаша турган транзакциялардын агымын алышты, бирок жылуулар башка серверлер менен активдүү иштешкен жок.
Бул эмне үчүн жасалган? Эгерде резервдик сервер иштебей калса, анда негизги серверге байланган жылуу жаңы резервдик көчүрмө болуп калат. Башкача айтканда, бузулгандан кийин, система соода сессиясынын аягына чейин бир негизги серверде калбайт.
Ал эми системанын жаңы версиясы текшерилип, ишке киргизилгенде тегеректөө бит катасы кайрадан пайда болду. Андан тышкары, жылуу серверлердин санынын өсүшү менен ката тез-тез пайда боло баштады. Ошол эле учурда сатуучунун эч кандай конкреттүү далили болбогондуктан көрсөтө турган эч нерсеси болгон эмес.
Кырдаалды кийинки талдоо учурунда маселе ОС менен байланыштуу болушу мүмкүн деген теория пайда болду. Биз чексиз циклде функцияны чакырган жөнөкөй программа жаздык fesetround, учурдагы абалын эстеп, аны уйку аркылуу текшерет жана бул көптөгөн атаандаш жиптерде жасалат. Уйкунун параметрлерин жана жиптердин санын тандап алып, биз утилитаны 5 мүнөттөй иштеткенден кийин биттин бузулушун ырааттуу түрдө чыгара баштадык. Бирок Red Hat колдоосу аны кайра чыгара алган жок. Башка серверлерибиздин тестирлөөсү белгилүү бир процессорлору барлар гана катага кабыларын көрсөттү. Ошол эле учурда жаңы ядрого өтүү көйгөйдү чечти. Акыр-аягы, биз жөн гана OS алмаштырдык, жана мүчүлүштүктөрдү чыныгы себеби түшүнүксүз бойдон калууда.
Жана күтүлбөгөн жерден өткөн жылы бир макала жарыяланган Habré "" Анда сүрөттөлгөн жагдай биздикиндей эле, бирок автор иликтөөнү андан ары улантып, ката микрокоддо болгон деген теорияны ортого салган. Ал эми Linux ядролору жаңыртылганда, өндүрүүчүлөр микрокодду да жаңыртышат.
Системаны андан ары өнүктүрүү
Биз катадан арылганыбыз менен, бул окуя бизди системанын архитектурасын кайра карап чыгууга мажбур кылды. Анткени, биз мындай мүчүлүштүктөрдү кайталоодон корголбодук.
Төмөнкү принциптер резервациялоо системасын кийинки өркүндөтүү үчүн негиз болгон:
- Эч кимге ишене албайсың. Серверлер туура иштебей калышы мүмкүн.
- Көпчүлүк резерв.
- Консенсусту камсыз кылуу. Көпчүлүк резервацияга логикалык кошумча катары.
- Эки катачылыктар болушу мүмкүн.
- Жашоо. Жаңы ысык күтүү схемасы мурункусунан жаман болбошу керек. Соода акыркы серверге чейин үзгүлтүксүз жүрүшү керек.
- Кечигүүнүн бир аз жогорулашы. Ар кандай токтоп калуу чоң каржылык жоготууларды алып келет.
- Мүмкүн болушунча күтүү убактысын азайтуу үчүн тармактын минималдуу иштеши.
- Бир секунданын ичинде жаңы башкы серверди тандоо.
Базарда жеткиликтүү болгон чечимдердин бири да бизге туура келген жок, жана Raft протоколу али башталгыч баскычында болчу, ошондуктан биз өзүбүздүн чечимибизди түздүк.
Networking
Брондоо системасынан тышкары, биз тармактык өз ара аракеттенүүнү модернизациялай баштадык. Киргизүү/чыгаруу подсистемасы көптөгөн процесстерден турган, алар життерге жана күтүүгө эң начар таасирин тийгизген. TCP байланыштарын иштеткен жүздөгөн процесстер менен биз алардын ортосунда тынымсыз которулууга аргасыз болдук жана микросекунддук масштабда бул өтө көп убакытты талап кылган операция. Бирок эң жаман жери, процесс иштетүү үчүн пакетти алганда, аны бир SystemV кезегине жөнөтүп, андан кийин башка SystemV кезегинде окуяны күткөн. Бирок түйүндөр көп болгондо, бир процессте жаңы TCP пакетинин келиши жана экинчисинде кезектеги маалыматтардын келиши ОС үчүн эки атаандаш окуяны билдирет. Бул учурда, эки тапшырма үчүн тең физикалык процессорлор жок болсо, бири иштетилет, ал эми экинчиси күтүү кезегине коюлат. Мунун кесепеттерин алдын ала айтуу мүмкүн эмес.
Мындай кырдаалдарда динамикалык процесстин приоритеттүү башкаруусу колдонулушу мүмкүн, бирок бул үчүн ресурстарды көп талап кылган системалык чалууларды колдонуу талап кылынат. Натыйжада, биз классикалык epoll аркылуу бир жипке өттүк, бул ылдамдыкты бир топ жогорулатты жана транзакцияны иштетүү убактысын кыскартты. Биз ошондой эле өзүнчө тармактык байланыш процесстеринен жана SystemV аркылуу байланыштан арылдык, системалык чалуулардын санын бир топ кыскарттык жана операциялардын артыкчылыктарын көзөмөлдөй баштадык. I/O подсистемасында эле сценарийге жараша 8-17 микросекундду үнөмдөөгө мүмкүн болгон. Бул бир жиптүү схема ошондон бери өзгөрүүсүз колдонулуп келет; бардык байланыштарды тейлөө үчүн маржа менен бир эполл жип жетиштүү.
Транзакцияны иштетүү
Биздин системанын өсүп жаткан жүктөмү анын дээрлик бардык компоненттерин жаңыртууну талап кылды. Бирок, тилекке каршы, акыркы жылдардагы процессорлордун сааттык ылдамдыгынын өсүшүндөгү стагнация процесстерди масштабдуу масштабда жүргүзүүгө мүмкүнчүлүк бербей калды. Ошондуктан, биз Engine процессин үч деңгээлге бөлүүнү чечтик, алардын ичинен эң көп иштегени тобокелдикти текшерүү системасы болуп саналат, ал эсептердеги каражаттардын болушун баалайт жана транзакцияларды өздөрү түзөт. Бирок акча ар кандай валютада болушу мүмкүн, жана суроо-талаптарды иштетүү кандай негизде бөлүштүрүлүшү керек экенин аныктоо керек болчу.
Логикалык чечим аны валютага бөлүү болуп саналат: бир сервер доллар менен, экинчиси фунт менен, үчүнчүсү евродо соода кылат. Бирок, эгерде мындай схема менен эки транзакция ар кандай валюталарды сатып алууга жөнөтүлсө, анда капчыкты десинхронизациялоо маселеси пайда болот. Бирок синхрондоштуруу кыйын жана кымбат. Ошондуктан, капчыктар боюнча өзүнчө, инструменттер боюнча өзүнчө сындыруу туура болот. Айтмакчы, көпчүлүк батыш биржаларында тобокелдиктерди биздегидей курч текшерүү милдети жок, андыктан бул көбүнчө оффлайн режиминде жүргүзүлөт. Биз онлайн текшерүүнү ишке ашыруубуз керек болчу.
Мисал менен түшүндүрүп берели. Трейдер 30 доллар сатып алууну каалайт жана өтүнүч транзакцияны текшерүүгө барат: биз бул соодагерге бул соода режимине уруксат берилгендигин жана анын керектүү укуктары бар-жоктугун текшеребиз. Эгерде баары өз нугунда болсо, суроо-талап тобокелдикти текшерүү системасына өтөт, б.а. бүтүм түзүү үчүн каражаттардын жетиштүүлүгүн текшерүү. Учурда керектүү сумма бөгөттөлгөн деген жазуу бар. Андан кийин суроо-талап соода системасына жөнөтүлөт, ал транзакцияны жактырат же четке кагат. Келгиле, бүтүм бекитилди дейли - анда тобокелдикти текшерүү системасы акча бөгөттөн чыгарылганын белгилейт, ал эми рубль долларга айланат.
Жалпысынан алганда, тобокелдикти текшерүү системасы татаал алгоритмдерди камтыйт жана абдан көп ресурсту талап кылган эсептөөлөрдү аткарат жана жөн гана "эсептин балансын" текшербейт, бул биринчи караганда көрүнгөн.
Кыймылдаткыч процессин деңгээлдерге бөлө баштаганда, биз көйгөйгө туш болдук: ошол кездеги код валидация жана текшерүү этаптарында ошол эле маалыматтардын массивдерин жигердүү колдонгон, ал бүт код базасын кайра жазууну талап кылган. Натыйжада, биз заманбап процессорлордон инструкцияларды иштетүү ыкмасын алдык: алардын ар бири чакан этаптарга бөлүнөт жана бир циклде параллелдүү бир нече аракеттер аткарылат.
Кодду кичине адаптациялоодон кийин, транзакцияны параллелдүү иштетүү үчүн транзакцияны түздүк, анда транзакция түтүктүн 4 баскычына бөлүнгөн: тармактын өз ара аракеттенүүсү, валидация, аткаруу жана натыйжаны жарыялоо
Келгиле, бир мисал карап көрөлү. Бизде эки иштетүү системасы бар, сериялык жана параллелдүү. Биринчи транзакция келип, эки системада тең текшерүүгө жөнөтүлөт. Экинчи транзакция дароо келет: параллелдүү системада ал дароо ишке киргизилет, ал эми ырааттуу системада биринчи транзакция учурдагы иштетүү стадиясынан өтүшү үчүн кезекке коюлат. Башкача айтканда, түтүктөрдү иштетүүнүн негизги артыкчылыгы - транзакция кезегин тезирээк иштетебиз.
Биз ASTS+ системасын ушинтип ойлоп таптык.
Ырас, конвейерлер менен да бардыгы тец эмес. Бизде кошуна транзакциядагы маалыматтар массивдерине таасир этүүчү транзакция бар дейли; бул алмашуу үчүн типтүү жагдай. Мындай транзакцияны ишке ашыруу мүмкүн эмес, анткени ал башкаларга таасир этиши мүмкүн. Бул жагдай маалымат коркунучу деп аталат жана мындай транзакциялар жөн гана өзүнчө иштетилет: кезектеги “тез” транзакциялар түгөнгөндө, түтүк токтойт, система “жай” транзакцияны иштеп чыгат, анан кайра куурду ишке киргизет. Бактыга жараша, мындай транзакциялардын жалпы агымдагы үлүшү өтө аз, ошондуктан түтүк өтө сейрек токтойт, ал жалпы көрсөткүчтөргө таасирин тийгизбейт.
Андан кийин биз аткаруунун үч жиптерин синхрондоштуруу маселесин чече баштадык. Натыйжада белгиленген өлчөмдөгү клеткалары бар шакек буферине негизделген система пайда болду. Бул системада баары кайра иштетүү ылдамдыгына жараша болот, маалыматтар көчүрүлбөйт.
- Бардык келген тармак пакеттери бөлүштүрүү стадиясына кирет.
- Биз аларды массивге жайгаштырып, №1 этап үчүн жеткиликтүү деп белгилейбиз.
- Экинчи транзакция келди, ал кайрадан №1 этап үчүн жеткиликтүү.
- Биринчи иштетүү жип колдо болгон транзакцияларды көрөт, аларды иштетет жана экинчи иштетүү жипинин кийинки этабына өткөрөт.
- Андан кийин биринчи транзакцияны иштетип, тиешелүү уячаны белгилейт
deleted- азыр жаңы колдонуу үчүн жеткиликтүү.
Бүткүл кезек ушундай жол менен иштетилет.
Ар бир этапты иштетүү бирдиктерди же ондогон микросекунддарды талап кылат. Ал эми биз стандарттык OS синхрондоштуруу схемаларын колдонсок, анда биз синхрондоштуруунун өзүнө көбүрөөк убакыт жоготобуз. Ошондуктан биз спинлокту колдоно баштадык. Бирок, бул реалдуу убакыт тутумунда өтө начар форма, жана RedHat муну катуу сунуштабайт, ошондуктан биз 100 мс үчүн спинлокти колдонобуз, андан кийин туюк калуу мүмкүнчүлүгүн жок кылуу үчүн семафордук режимге өтөбүз.
Натыйжада биз секундасына 8 миллионго жакын транзакцияны аткарууга жетиштик. Жана эки айдан кийин түзмө-түз LMAX Disruptor жөнүндө биз ошол эле функцияга ээ болгон схеманын сүрөттөмөсүн көрдүк.
Эми бир этапта аткаруунун бир нече жиптери болушу мүмкүн. Бардык транзакциялар кабыл алынган тартипте бир-бирден иштелип чыккан. Натыйжада, эң жогорку көрсөткүч секундасына 18 миңден 50 миң транзакцияга чейин өстү.
Биржа тобокелдиктерин башкаруу системасы
Кемчиликсиздикке чек жок, көп өтпөй биз кайрадан модернизациялоону баштадык: ASTS+ алкагында биз тобокелдиктерди башкаруу жана эсептешүү операциялары системаларын автономдуу компоненттерге көчүрө баштадык. Биз ийкемдүү заманбап архитектураны жана жаңы иерархиялык тобокел моделин иштеп чыктык жана мүмкүн болгон жерде классты колдонууга аракет кылдык fixed_point ордуна double.
Бирок дароо эле маселе пайда болду: көп жылдан бери иштеп келе жаткан бардык бизнес логикасын кантип синхрондоштуруу жана аны жаңы системага өткөрүү керек? Натыйжада, жаңы системанын прототипинин биринчи версиясынан баш тартууга туура келди. Учурда өндүрүштө иштеп жаткан экинчи версия, соода жана тобокелдик бөлүктөрүндө иштеген бир эле кодго негизделген. Иштеп чыгуу учурунда эң кыйын нерсе бул эки версиянын ортосунда git бириктирүү болду. Кесиптешибиз Евгений Мазуренок бул операцияны жума сайын жасап, ар бир жолу өтө көпкө чейин сөгүнүп турду.
Жаңы системаны тандоодо дароо өз ара аракеттенүү маселесин чечүүгө туура келди. Маалымат шинасын тандоодо туруктуу життерди жана минималдуу кечиктирүүнү камсыз кылуу керек болчу. Бул үчүн InfiniBand RDMA тармагы эң ылайыктуу болгон: орточо иштетүү убактысы 4 G Ethernet тармактарына караганда 10 эсе аз. Бирок бизди кызыктырган нерсе - 99 жана 99,9 пайыздык айырма болду.
Албетте, InfiniBandдин өз кыйынчылыктары бар. Биринчиден, башка API - розеткалардын ордуна ibverbs. Экинчиден, кеңири жеткиликтүү ачык булактуу билдирүү чечимдери дээрлик жок. Биз өзүбүздүн прототипибизди жасаганга аракет кылдык, бирок бул абдан кыйын болуп чыкты, ошондуктан биз коммерциялык чечимди - Confinity Low Latency Messaging (мурдагы IBM MQ LLM) тандап алдык.
Андан кийин тобокелдик системасын туура бөлүштүрүү милдети келип чыккан. Эгерде сиз жөн гана Risk Engineди алып салсаңыз жана ортодогу түйүн түзбөсөңүз, анда эки булактан транзакциялар аралаштырылышы мүмкүн.
Ultra Low Latency деп аталган чечимдер кайра иреттөө режимине ээ: эки булактан транзакциялар алынгандан кийин талап кылынган тартипте уюштурулушу мүмкүн; бул заказ жөнүндө маалымат алмашуу үчүн өзүнчө канал аркылуу ишке ашырылат. Бирок биз азырынча бул режимди колдоно элекпиз: ал бүт процессти татаалдантат жана бир катар чечимдерде ал такыр колдоого алынбайт. Мындан тышкары, ар бир транзакцияга тиешелүү убакыт белгилери ыйгарылышы керек жана биздин схемада бул механизмди туура ишке ашыруу өтө кыйын. Ошондуктан, биз классикалык схеманы билдирүү брокери менен, башкача айтканда, Risk Engine ортосунда билдирүүлөрдү таратуучу диспетчер менен колдондук.
Экинчи маселе кардардын жеткиликтүүлүгүнө байланыштуу болгон: эгерде бир нече Risk Gateways бар болсо, кардар алардын ар бирине туташуу керек жана бул үчүн кардар катмарына өзгөртүүлөрдү талап кылат. Биз бул этапта мындан арылууну кааладык, андыктан учурдагы Risk Gateway дизайны бүт маалымат агымын иштетет. Бул максималдуу өткөрүү мүмкүнчүлүгүн абдан чектейт, бирок системанын интеграциясын абдан жөнөкөйлөтөт.
копия кылуу
Биздин системада бир да катачылык болбошу керек, башкача айтканда, бардык компоненттер, анын ичинде билдирүү брокери кайталанышы керек. Биз бул маселени CLLM тутумунун жардамы менен чечтик: анда эки диспетчер мастер-кул режиминде иштей турган RCMS кластерин камтыйт жана бири иштебей калганда система автоматтык түрдө экинчисине өтөт.
Камдык маалымат борбору менен иштөө
InfiniBand локалдык тармак катары иштөө үчүн оптималдаштырылган, башкача айтканда, стойкага орнотулган жабдууларды туташтыруу үчүн жана InfiniBand тармагын эки географиялык бөлүштүрүлгөн маалымат борборлорунун ортосуна коюуга болбойт. Ошондуктан, биз кадимки Ethernet тармактары аркылуу билдирүүлөрдү сактоочу жайга туташтырылган жана бардык транзакцияларды экинчи IB тармагына өткөрүүчү көпүрө/диспетчерди ишке ашырдык. Бизге маалымат борборунан көчүү керек болгондо, азыр кайсы маалымат борбору менен иштөөнү тандай алабыз.
натыйжалары
Жогоруда айтылгандардын баары бир эле учурда жасалган эмес, жаңы архитектураны иштеп чыгуу үчүн бир нече итерация талап кылынган. Прототибин бир айдын ичинде түздүк, бирок аны иштөө абалына келтирүү үчүн эки жылдан ашык убакыт кетти. Биз транзакцияларды иштетүү убактысын көбөйтүү менен системанын ишенимдүүлүгүн жогорулатуунун ортосунда эң жакшы компромисске жетишүүгө аракет кылдык.
Система катуу жаңылангандыктан, биз эки көз карандысыз булактан маалыматтарды калыбына келтирүүнү ишке ашырдык. Эгерде билдирүү дүкөнү кандайдыр бир себептерден улам туура иштебей жатса, транзакциялар журналын экинчи булактан - Risk Engine'ден ала аласыз. Бул принцип бүтүндөй системада сакталат.
Башка нерселер менен катар, биз брокерлер да, башка бирөө да жаңы архитектура үчүн олуттуу кайра иштетүүнү талап кылбашы үчүн, кардар API'син сактап алдык. Кээ бир интерфейстерди өзгөртүүгө туура келди, бирок операциялык моделге олуттуу өзгөртүүлөрдү киргизүүнүн кереги жок болчу.
Биз платформабыздын учурдагы версиясын Rebus деп атадык - архитектурадагы эң көрүнүктүү эки инновациянын аббревиатурасы катары, Risk Engine жана BUS.
Башында биз клирингдик бөлүгүн гана бөлгүбүз келген, бирок натыйжада чоң бөлүштүрүлгөн система пайда болду. Кардарлар эми Соода шлюзи, Клиринг шлюзу же экөөсү менен иштеше алышат.
Биз акыры эмнеге жетиштик:
Кечирүү деңгээли кыскарды. Бүтүмдөрдүн кичинекей көлөмү менен система мурунку версиясындай эле иштейт, бирок ошол эле учурда бир топ жогору жүктү көтөрө алат.
Пик көрсөткүчү секундасына 50 миңден 180 миң транзакцияга чейин өстү. Андан аркы өсүш тартипти дал келүүнүн жалгыз агымы менен тоскоол болууда.
Андан ары өркүндөтүүнүн эки жолу бар: дал келүүнү параллелизациялоо жана Gateway менен иштөө ыкмасын өзгөртүү. Эми бардык шлюздар репликация схемасы боюнча иштейт, ал мындай жүктө кадимкидей иштебей калат.
Акыр-аягы, мен ишкана системаларын бүтүрүп жаткандарга бир нече кеңеш бере алам:
- Ар дайым эң жаман нерсеге даяр болуңуз. Көйгөйлөр ар дайым күтүлбөгөн жерден пайда болот.
- Архитектураны тез кайра жасоо адатта мүмкүн эмес. Айрыкча, бир нече көрсөткүчтөр боюнча максималдуу ишенимдүүлүккө жетишүү керек болсо. Канчалык көп түйүн, колдоо үчүн ошончолук көп ресурстар керек.
- Бардык бажы жана менчик чечимдер изилдөө, колдоо жана тейлөө үчүн кошумча ресурстарды талап кылат.
- Тутумдун ишенимдүүлүгү жана бузулуулардан кийин калыбына келтирүү маселелерин чечүүнү кийинкиге калтырбаңыз, аларды долбоордун баштапкы этабында эске алыңыз.
Source: www.habr.com