Moskva Birjasının ticarət və klirinq sisteminin arxitekturasının təkamülü. 1-ci hissə

Hamıya salam! Mənim adım Sergey Kostanbaev, Birjada ticarət sisteminin əsasını inkişaf etdirirəm.

Hollivud filmləri Nyu-York Birjasını göstərəndə həmişə belə görünür: izdihamlı insanlar, hamı nəsə qışqırır, kağız yelləyir, tam xaos baş verir. Burada Moskva Birjasında bu heç vaxt baş verməyib, çünki ticarət əvvəldən elektron şəkildə aparılıb və iki əsas platformaya - Spectra (forex bazarı) və ASTS (xarici birja, fond və pul bazarı) əsasında qurulub. Və bu gün mən ASTS ticarət və klirinq sisteminin arxitekturasının təkamülü, müxtəlif həllər və tapıntılar haqqında danışmaq istəyirəm. Hekayə uzun olacaq, ona görə də onu iki hissəyə bölməli oldum.

Biz dünyada bütün siniflərin aktivlərini alqı-satqı edən və mübadilə xidmətlərinin tam spektrini təqdim edən azsaylı birjalardan biriyik. Məsələn, biz ötən il istiqrazların ticarətinin həcminə görə dünyada ikinci, bütün birjalar arasında 25-ci, kapitallaşma üzrə dövlət birjaları arasında 13-cü yeri tutmuşuq.

Peşəkar ticarət iştirakçıları üçün cavab müddəti, vaxt paylanmasının sabitliyi (jitter) və bütün kompleksin etibarlılığı kimi parametrlər vacibdir. Hazırda biz gündə on milyonlarla əməliyyatları emal edirik. Hər bir əməliyyatın sistem nüvəsi tərəfindən işlənməsi onlarla mikrosaniyə çəkir. Təbii ki, Yeni il ərəfəsində mobil operatorların və ya axtarış sistemlərinin özlərinin iş yükü bizdən daha yüksəkdir, lakin iş yükü baxımından yuxarıda qeyd olunan xüsusiyyətlərlə birləşdikdə, mənə elə gəlir ki, bizimlə müqayisə oluna bilənlər azdır. Eyni zamanda, sistemin bir saniyə belə yavaşlamaması, tamamilə stabil işləməsi və bütün istifadəçilərin bərabər səviyyədə olması bizim üçün vacibdir.

Bir az tarix

1994-cü ildə Moskva Banklararası Valyuta Birjasında (MICEX) Avstraliya ASTS sistemi işə salındı ​​və o andan etibarən Rusiyanın elektron ticarət tarixini saymaq olar. 1998-ci ildə birja arxitekturası internet ticarətini tətbiq etmək üçün modernləşdirildi. O vaxtdan bəri bütün sistemlərdə və alt sistemlərdə yeni həllərin və arxitektura dəyişikliklərinin tətbiqi sürəti yalnız sürət qazanır.

Həmin illərdə mübadilə sistemi yüksək səviyyəli aparatlarda - ultra etibarlı HP Superdome 9000 serverlərində işləyirdi. PA-RİSK), burada tamamilə hər şey təkrarlanırdı: giriş/çıxış alt sistemləri, şəbəkə, RAM (əslində RAM-ın RAID massivi var idi), prosessorlar (isti dəyişdirilə bilən). Maşını dayandırmadan istənilən server komponentini dəyişmək mümkün idi. Biz bu cihazlara güvəndik və onları praktiki olaraq uğursuz hesab etdik. Əməliyyat sistemi Unix-ə bənzər HP UX sistemi idi.

Ancaq təxminən 2010-cu ildən bəri yüksək tezlikli ticarət (HFT) və ya yüksək tezlikli ticarət adlanan bir fenomen meydana çıxdı - sadəcə olaraq, birja robotları. Cəmi 2,5 il ərzində serverlərimizin yükü 140 dəfə artıb.

Köhnə memarlıq və avadanlıqla belə bir yükə tab gətirmək mümkün deyildi. Birtəhər uyğunlaşmaq lazım idi.

Start

Mübadilə sisteminə müraciətlər iki növə bölünə bilər:

• Əməliyyatlar. Dollar, səhmlər və ya başqa bir şey almaq istəyirsinizsə, ticarət sisteminə əməliyyat göndərir və uğur haqqında cavab alırsınız.
• Məlumat sorğuları. Cari qiyməti öyrənmək istəyirsinizsə, sifariş kitabçasına və ya indekslərə baxın, sonra məlumat sorğuları göndərin.

Sxematik olaraq sistemin əsasını üç səviyyəyə bölmək olar:

• Brokerlərin və müştərilərin işlədiyi müştəri səviyyəsi. Onların hamısı giriş serverləri ilə qarşılıqlı əlaqədədir.
• Gateway serverləri bütün məlumat sorğularını yerli olaraq emal edən serverləri keşləyir. Sberbank səhmlərinin hazırda hansı qiymətə satıldığını bilmək istəyirsiniz? Sorğu giriş serverinə gedir.
• Amma səhmləri almaq istəyirsinizsə, o zaman sorğu mərkəzi serverə (Ticarət Mühərriki) gedir. Hər bir bazar növü üçün bir belə server var, onlar həyati rol oynayırlar, biz bu sistemi onlar üçün yaratdıq.

Ticarət sisteminin əsasını bütün əməliyyatların mübadilə əməliyyatları olduğu ağıllı yaddaşdaxili verilənlər bazası təşkil edir. Baza C dilində yazılmışdı, yeganə xarici asılılıqlar libc kitabxanası idi və heç bir dinamik yaddaş bölgüsü yox idi. Emal müddətini azaltmaq üçün sistem statik massivlər dəsti və statik məlumatların yerdəyişməsi ilə başlayır: birincisi, cari gün üçün bütün məlumatlar yaddaşa yüklənir və diskə əlavə giriş həyata keçirilmir, bütün işlər yalnız yaddaşda aparılır. Sistem işə salındıqda, bütün istinad məlumatları artıq çeşidlənir, ona görə də axtarış çox səmərəli işləyir və işləmə müddətində az vaxt tələb olunur. Bütün cədvəllər dinamik məlumat strukturları üçün müdaxilə siyahıları və ağaclarla hazırlanmışdır ki, onlar icra zamanı yaddaşın ayrılmasını tələb etmir.

Ticarət və klirinq sistemimizin inkişaf tarixinə qısaca nəzər salaq.
Ticarət və klirinq sisteminin arxitekturasının ilk versiyası Unix adlı qarşılıqlı əlaqə üzərində qurulmuşdur: paylaşılan yaddaş, semaforlar və növbələrdən istifadə edilmişdir və hər bir proses bir ipdən ibarət idi. Bu yanaşma 1990-cı illərin əvvəllərində geniş yayılmışdı.

Sistemin ilk versiyasında iki səviyyəli Gateway və ticarət sisteminin mərkəzi serveri var idi. İş axını belə idi:

• Müştəri Gateway-ə çatan sorğu göndərir. O, formatın etibarlılığını yoxlayır (ancaq məlumatların özünü yox) və yanlış əməliyyatları rədd edir.
• Əgər məlumat sorğusu göndərilibsə, o, yerli icra olunur; bir əməliyyatdan danışırıqsa, o zaman mərkəzi serverə yönləndirilir.
• Ticarət mühərriki daha sonra tranzaksiyanı emal edir, yerli yaddaşı dəyişdirir və ayrıca təkrarlama mühərrikindən istifadə edərək təkrarlama üçün əməliyyata və əməliyyatın özünə cavab göndərir.
• Gateway mərkəzi qovşaqdan cavab alır və onu müştəriyə ötürür.
• Müəyyən müddətdən sonra Gateway replikasiya mexanizmi vasitəsilə tranzaksiyanı qəbul edir və bu dəfə onu yerli olaraq icra edir, məlumat strukturlarını dəyişir ki, növbəti informasiya sorğularında ən son məlumatları əks etdirsin.

Əslində, Gateway-in ticarət sistemində həyata keçirilən hərəkətləri tamamilə təkrarladığı bir replikasiya modelini təsvir edir. Ayrı bir təkrarlama kanalı əməliyyatların birdən çox giriş qovşağında eyni ardıcıllıqla yerinə yetirilməsini təmin etdi.

Kod tək yivli olduğundan, bir çox müştəriyə xidmət etmək üçün proses çəngəlləri olan klassik sxemdən istifadə edilmişdir. Bununla belə, bütün verilənlər bazasını çəngəlləmək çox baha idi, ona görə də TCP seanslarından paketləri toplayan və onları bir növbəyə (SystemV Mesaj Növbəsi) köçürən yüngül xidmət proseslərindən istifadə olunurdu. Gateway və Trade Engine yalnız bu növbə ilə işləyirdi, əməliyyatları icra üçün oradan götürürdü. Artıq ona cavab göndərmək mümkün deyildi, çünki onu hansı xidmət prosesinin oxuması lazım olduğu bəlli deyildi. Beləliklə, biz bir hiyləyə əl atdıq: hər bir çəngəlli proses özü üçün cavab növbəsi yaratdı və gələn növbəyə sorğu gələndə dərhal ona cavab növbəsi üçün bir etiket əlavə edildi.

Böyük həcmli məlumatların növbədən növbəyə daimi surətdə köçürülməsi xüsusilə informasiya sorğuları üçün xarakterik problemlər yaradırdı. Buna görə də biz başqa bir hiylə işlətdik: cavab növbəsinə əlavə olaraq hər bir proses həm də ortaq yaddaş (SystemV Shared Memory) yaratdı. Paketlərin özləri orada yerləşdirildi və növbədə yalnız bir etiket saxlanıldı, bu da orijinal paketi tapmağa imkan verdi. Bu, məlumatların prosessor keşində saxlanmasına kömək etdi.

SystemV IPC növbə, yaddaş və semafor obyektlərinin vəziyyətinə baxmaq üçün utilitləri ehtiva edir. Müəyyən bir anda sistemdə nə baş verdiyini, paketlərin harada yığıldığını, nəyin bloklandığını və s. anlamaq üçün bundan fəal şəkildə istifadə etdik.

İlk modernləşdirmələr

İlk növbədə, biz tək proses Gateway-dən xilas olduq. Onun əhəmiyyətli çatışmazlığı ondan ibarət idi ki, o, ya bir təkrarlama əməliyyatını, ya da müştəridən bir məlumat sorğusunu idarə edə bilirdi. Və yük artdıqca, Gateway sorğuları emal etmək üçün daha çox vaxt aparacaq və replikasiya axınını emal edə bilməyəcək. Bundan əlavə, əgər müştəri əməliyyat göndəribsə, onda yalnız onun etibarlılığını yoxlamaq və onu daha da irəli sürmək lazımdır. Buna görə də, biz vahid Gateway prosesini paralel olaraq işləyə bilən çoxlu komponentlərlə əvəz etdik: RW kilidindən istifadə edərək paylaşılan yaddaş sahəsində bir-birindən asılı olmayaraq işləyən çox yivli məlumat və əməliyyat prosesləri. Və eyni zamanda biz göndərmə və təkrarlama proseslərini təqdim etdik.

Yüksək Tezlikli Ticarətin Təsiri

Arxitekturanın yuxarıdakı versiyası 2010-cu ilə qədər mövcud idi. Bu arada, biz artıq HP Superdome serverlərinin performansından razı qalmadıq. Bundan əlavə, PA-RISC arxitekturası faktiki olaraq ölü idi; satıcı heç bir əhəmiyyətli yeniləmə təklif etmədi. Nəticədə biz HP UX/PA RISC-dən Linux/x86-a keçməyə başladıq. Keçid giriş serverlərinin uyğunlaşdırılması ilə başladı.

Niyə yenidən memarlığı dəyişməli olduq? Fakt budur ki, yüksək tezlikli ticarət sistemin nüvəsindəki yük profilini əhəmiyyətli dərəcədə dəyişdi.

Deyək ki, qiymət dəyişikliyinə səbəb olan kiçik bir əməliyyatımız var - kimsə yarım milyard dollar alıb. Bir neçə millisaniyədən sonra bütün bazar iştirakçıları bunu fərq edir və düzəliş etməyə başlayırlar. Təbii ki, sorğular böyük bir növbə ilə düzülür ki, bunun da sistem tərəfindən aradan qaldırılması çox vaxt aparacaq.

Bu 50 ms intervalda orta sürət saniyədə təxminən 16 min əməliyyat təşkil edir. Pəncərəni 20 ms-ə endirsək, pikdə 90 min əməliyyat olmaqla, saniyədə 200 min əməliyyat sürəti əldə edirik. Başqa sözlə, yük sabit deyil, ani partlayışlarla. Və sorğuların növbəsi həmişə tez işlənməlidir.

Bəs niyə ümumiyyətlə növbə var? Beləliklə, nümunəmizdə bir çox istifadəçi qiymət dəyişikliyini fərq etdi və buna uyğun olaraq əməliyyatlar göndərdi. Onlar Gateway-ə gəlirlər, o, onları seriallaşdırır, müəyyən bir sıra təyin edir və şəbəkəyə göndərir. Routerlər paketləri qarışdırır və yönləndirirlər. Kimin paketi birinci gəlibsə, həmin əməliyyat “qalib”. Nəticədə, mübadilə müştəriləri fərq etməyə başladılar ki, əgər eyni əməliyyat bir neçə Gateway-dən göndərilibsə, onda onun sürətli emal şansı artıb. Tezliklə mübadilə robotları Gateway-i sorğularla bombalamağa başladılar və əməliyyatlar uçqunu yarandı.

Təkamülün yeni mərhələsi

Geniş sınaq və araşdırmalardan sonra biz real vaxt rejimində əməliyyat sisteminin nüvəsinə keçdik. Bunun üçün biz RedHat Enterprise MRG Linux-u seçdik, burada MRG real vaxt mesajlaşma şəbəkəsini ifadə edir. Real vaxt rejimində yamaqların üstünlüyü ondan ibarətdir ki, onlar sistemi mümkün qədər tez icra etmək üçün optimallaşdırırlar: bütün proseslər FIFO növbəsinə düzülür, nüvələr təcrid oluna bilər, boşalma yoxdur, bütün əməliyyatlar ciddi ardıcıllıqla emal olunur.

Qırmızı - adi nüvədə növbə ilə işləyir, yaşıl - real vaxt nüvəsində işləyir.

Lakin adi serverlərdə aşağı gecikməyə nail olmaq o qədər də asan deyil:

• X86 arxitekturasında mühüm periferiya qurğuları ilə işləmək üçün əsas olan SMI rejimi çox müdaxilə edir. Hər cür aparat hadisələrinin emalı və komponentlərin və cihazların idarə edilməsi əməliyyat sisteminin proqram təminatının ümumiyyətlə nə etdiyini görməyən şəffaf SMI rejimində proqram təminatı tərəfindən həyata keçirilir. Bir qayda olaraq, bütün əsas satıcılar SMI emalının həcmini azaltmağa imkan verən proqram təminatı serverləri üçün xüsusi genişləndirmələr təklif edirlər.
• Prosessor tezliyinə dinamik nəzarət olmamalıdır, bu, əlavə fasilələrə səbəb olur.
• Fayl sistemi jurnalı təmizləndikdə, nüvədə gözlənilməz gecikmələrə səbəb olan müəyyən proseslər baş verir.
• CPU yaxınlığı, kəsmə yaxınlığı, NUMA kimi şeylərə diqqət yetirməlisiniz.

Deməliyəm ki, real vaxt rejimində işləmə üçün Linux aparatının və nüvəsinin qurulması mövzusu ayrıca məqaləyə layiqdir. Yaxşı nəticə əldə etməzdən əvvəl çoxlu təcrübə və araşdırmalara sərf etdik.

PA-RISC serverlərindən x86-ya keçərkən, praktiki olaraq sistem kodunu çox dəyişməli olmadıq, sadəcə onu uyğunlaşdırdıq və yenidən konfiqurasiya etdik. Eyni zamanda, bir neçə səhvi düzəltdik. Məsələn, PA RISC-nin Big endian sistemi, x86-nın isə Little endian sistemi olmasının nəticələri tez bir zamanda ortaya çıxdı: məsələn, məlumatlar səhv oxundu. Ən çətin səhv PA RISC-nin istifadə etməsi idi ardıcıl ardıcıl (Ardıcıl olaraq ardıcıl) yaddaşa giriş, halbuki x86 oxu əməliyyatlarını yenidən sıralaya bilər, beləliklə, bir platformada tamamilə etibarlı olan kod digər platformada pozuldu.

X86-a keçdikdən sonra performans demək olar ki, üç dəfə artdı, orta əməliyyatın işləmə müddəti 60 μs-ə qədər azaldı.

İndi sistem arxitekturasında hansı əsas dəyişikliklərin edildiyinə daha yaxından nəzər salaq.

Qaynar ehtiyat epik

Əmtəə serverlərinə keçərkən onların daha az etibarlı olduğunu bilirdik. Buna görə də, yeni bir arxitektura yaratarkən, bir və ya bir neçə qovşaqın uğursuzluq ehtimalını aprior qəbul etdik. Buna görə də, ehtiyat maşınlara çox tez keçə bilən isti gözləmə sistemi lazım idi.

Bundan əlavə, digər tələblər də var idi:

• Heç bir halda işlənmiş əməliyyatları itirməməlisiniz.
• Sistem infrastrukturumuz üçün tamamilə şəffaf olmalıdır.
• Müştərilər kəsilmiş əlaqələri görməməlidir.
• Rezervasyonlar əhəmiyyətli gecikmə yaratmamalıdır, çünki bu, mübadilə üçün kritik amildir.

İsti gözləmə sistemi yaratarkən, ikiqat uğursuzluq kimi ssenariləri nəzərə almadıq (məsələn, bir serverdə şəbəkə işləməyi dayandırdı və əsas server dondu); proqram təminatında səhvlərin olma ehtimalını nəzərə almadı, çünki onlar sınaq zamanı müəyyən edilir; və avadanlıqların düzgün işləməsini nəzərə almadı.

Nəticədə aşağıdakı sxemə gəldik:

• Əsas server birbaşa Gateway serverləri ilə qarşılıqlı əlaqədə idi.
• Əsas serverdə alınan bütün əməliyyatlar dərhal ayrıca kanal vasitəsilə ehtiyat serverə təkrarlanırdı. Hər hansı problem yaranarsa, arbitr (Qubernator) keçidi koordinasiya edirdi.

  

• Əsas server hər bir əməliyyatı emal etdi və ehtiyat serverdən təsdiq gözlədi. Gecikməni minimuma endirmək üçün ehtiyat serverdə əməliyyatın tamamlanmasını gözləməkdən yayındıq. Tranzaksiyanın şəbəkə üzərindən keçməsi üçün tələb olunan vaxt icra vaxtı ilə müqayisə oluna bildiyi üçün əlavə gecikmə əlavə edilmədi.
• Biz yalnız əvvəlki tranzaksiya üçün əsas və ehtiyat serverlərin emal statusunu yoxlaya bildik və cari əməliyyatın emal statusu naməlum idi. Biz hələ də tək yivli proseslərdən istifadə etdiyimiz üçün Yedəkləmədən cavab gözləmək bütün emal axınını ləngidərdi, ona görə də ağlabatan bir güzəştə getdik: əvvəlki əməliyyatın nəticəsini yoxladıq.

Sxem aşağıdakı kimi işləyirdi.

Tutaq ki, əsas server cavab verməyi dayandırır, lakin Şlüzlər əlaqə saxlamağa davam edir. Ehtiyat serverdə fasilə yaranır, o, ona əsas server rolunu təyin edən Qubernatorla əlaqə saxlayır və bütün Şlüzlər yeni əsas serverə keçir.

Əsas server yenidən onlayn olarsa, o, həm də daxili fasiləyə səbəb olur, çünki müəyyən müddət ərzində Şlüzdən serverə zənglər olmayıb. Sonra o da Qubernatora üz tutur və onu sxemdən kənarlaşdırır. Nəticədə, birja ticarət dövrünün sonuna qədər bir serverlə işləyir. Server nasazlığı ehtimalı olduqca aşağı olduğundan, bu sxem olduqca məqbul hesab edildi, mürəkkəb məntiqi ehtiva etmədi və sınaqdan keçirilməsi asan idi.

Davam etmək.

Mənbə: www.habr.com