Moskva birjasining savdo-kliring tizimi arxitekturasining evolyutsiyasi. 1-qism

Hammaga salom! Mening ismim Sergey Kostanbaev, birjada men savdo tizimining asosiy qismini ishlab chiqyapman.

Gollivud filmlari Nyu-York fond birjasini namoyish qilganda, u har doim shunday ko'rinadi: olomon, hamma nimadir deb qichqiradi, qog'ozlarni silkitadi, to'liq tartibsizlik sodir bo'ladi. Bu erda Moskva birjasida hech qachon sodir bo'lmagan, chunki savdo boshidanoq elektron shaklda olib borilgan va ikkita asosiy platformaga asoslangan - Spectra (forex bozori) va ASTS (valyuta, fond va pul bozori). Va bugun men ASTS savdo va kliring tizimining arxitekturasi evolyutsiyasi, turli yechimlar va topilmalar haqida gapirmoqchiman. Hikoya uzoq bo'ladi, shuning uchun uni ikki qismga bo'lish kerak edi.

Biz dunyodagi barcha toifadagi aktivlarni sotadigan va birja xizmatlarining to'liq spektrini taqdim etadigan kam sonli birjalardanmiz. Masalan, o‘tgan yili obligatsiyalar savdosi hajmi bo‘yicha dunyoda ikkinchi, barcha birjalar orasida 25-o‘rin, kapitallashuv bo‘yicha ommaviy birjalar orasida 13-o‘rinni egalladik.

Professional savdo ishtirokchilari uchun javob vaqti, vaqt taqsimotining barqarorligi (jitter) va butun kompleksning ishonchliligi kabi parametrlar juda muhimdir. Hozir biz kuniga o'n millionlab tranzaktsiyalarni qayta ishlaymiz. Tizim yadrosi tomonidan har bir tranzaksiyani qayta ishlash o'nlab mikrosoniyalarni oladi. Albatta, yangi yil arafasida uyali aloqa operatorlari yoki qidiruv tizimlarining o‘zi biznikidan ko‘ra ko‘proq ish yukiga ega, ammo ish yuki bo‘yicha yuqorida tilga olingan xususiyatlar bilan bir qatorda biz bilan solishtiradiganlar kamdek tuyuladi. Shu bilan birga, biz uchun tizimning bir soniya sekinlashmasligi, mutlaqo barqaror ishlashi va barcha foydalanuvchilar teng sharoitda bo'lishi muhimdir.

Bir oz tarix

1994 yilda Moskva banklararo valyuta birjasida (MICEX) avstraliyalik ASTS tizimi ishga tushirildi va shu paytdan boshlab Rossiyaning elektron savdo tarixini hisoblash mumkin. 1998-yilda birja arxitekturasi internet-savdoni joriy qilish uchun modernizatsiya qilindi. O'shandan beri barcha tizimlar va quyi tizimlarda yangi echimlar va me'moriy o'zgarishlarni amalga oshirish tezligi tobora kuchayib bormoqda.

O'sha yillarda ayirboshlash tizimi yuqori darajadagi uskunada - o'ta ishonchli HP Superdome 9000 serverlarida (qurilma asosida qurilgan) ishlagan. PA-RISC), bunda mutlaqo hamma narsa takrorlangan: kiritish/chiqarish quyi tizimlari, tarmoq, RAM (aslida RAID RAM massivi mavjud edi), protsessorlar (hot-swappable). Mashinani to'xtatmasdan istalgan server komponentini o'zgartirish mumkin edi. Biz ushbu qurilmalarga tayandik va ularni deyarli ishlamay qolishi mumkin deb hisobladik. Operatsion tizim Unix-ga o'xshash HP UX tizimi edi.

Ammo taxminan 2010 yildan beri yuqori chastotali savdo (HFT) yoki yuqori chastotali savdo - oddiy qilib aytganda, birja robotlari deb ataladigan hodisa paydo bo'ldi. Atigi 2,5 yil ichida serverlarimiz yuklanishi 140 barobar oshdi.

Eski arxitektura va jihozlar bilan bunday yukga bardosh berishning iloji yo'q edi. Qandaydir tarzda moslashish kerak edi.

start

Ayirboshlash tizimiga bo'lgan so'rovlarni ikki turga bo'lish mumkin:

• Bitimlar. Agar siz dollar, aktsiya yoki boshqa narsalarni sotib olishni istasangiz, siz savdo tizimiga tranzaksiya yuborasiz va muvaffaqiyat haqida javob olasiz.
• Axborot so'rovlari. Agar siz joriy narxni bilmoqchi bo'lsangiz, buyurtmalar kitobini yoki indekslarini ko'ring, so'ngra ma'lumot so'rovlarini yuboring.

Sxematik jihatdan tizimning yadrosini uch darajaga bo'lish mumkin:

• Brokerlar va mijozlar ishlaydigan mijoz darajasi. Ularning barchasi kirish serverlari bilan o'zaro ishlaydi.
• Gateway serverlari barcha ma'lumotlar so'rovlarini mahalliy ravishda qayta ishlaydigan serverlarni keshlashdir. Sberbank aktsiyalari hozirda qanday narxda sotilayotganini bilmoqchimisiz? So'rov kirish serveriga o'tadi.
• Ammo agar siz aktsiyalarni sotib olishni istasangiz, u holda so'rov markaziy serverga (Trade Engine) o'tadi. Bozorning har bir turi uchun bitta shunday server mavjud, ular muhim rol o'ynaydi, biz ular uchun ushbu tizimni yaratdik.

Savdo tizimining yadrosi aqlli xotiradagi ma'lumotlar bazasi bo'lib, unda barcha operatsiyalar birja operatsiyalari hisoblanadi. Baza C tilida yozilgan, faqat tashqi bog'liqliklar libc kutubxonasi edi va umuman dinamik xotira taqsimoti yo'q edi. Qayta ishlash vaqtini qisqartirish uchun tizim statik massivlar to'plamidan va ma'lumotlarni statik ko'chirishdan boshlanadi: birinchidan, joriy kun uchun barcha ma'lumotlar xotiraga yuklanadi va diskdan keyingi kirish amalga oshirilmaydi, barcha ishlar faqat xotirada amalga oshiriladi. Tizim ishga tushganda, barcha ma'lumotnoma ma'lumotlari allaqachon tartiblangan, shuning uchun qidiruv juda samarali ishlaydi va ish vaqtida kam vaqt talab etadi. Barcha jadvallar dinamik ma'lumotlar tuzilmalari uchun intruziv ro'yxatlar va daraxtlardan iborat bo'lib, ular ish vaqtida xotirani ajratishni talab qilmaydi.

Keling, savdo va kliring tizimimizning rivojlanish tarixiga qisqacha to'xtalib o'tamiz.
Savdo va kliring tizimi arxitekturasining birinchi versiyasi Unix deb ataladigan o'zaro ta'sir asosida qurilgan: umumiy xotira, semaforlar va navbatlar ishlatilgan va har bir jarayon bitta ipdan iborat edi. Bu yondashuv 1990-yillarning boshlarida keng tarqalgan edi.

Tizimning birinchi versiyasida ikki darajadagi Gateway va savdo tizimining markaziy serveri mavjud edi. Ish jarayoni quyidagicha edi:

• Mijoz so'rov yuboradi, u Gatewayga etib boradi. U formatning haqiqiyligini tekshiradi (lekin ma'lumotlarning o'zi emas) va noto'g'ri operatsiyalarni rad etadi.
• Agar ma'lumot so'rovi yuborilgan bo'lsa, u mahalliy ravishda amalga oshiriladi; agar biz tranzaktsiya haqida gapiradigan bo'lsak, u markaziy serverga yo'naltiriladi.
• Keyin savdo mexanizmi tranzaktsiyani qayta ishlaydi, mahalliy xotirani o'zgartiradi va alohida replikatsiya mexanizmidan foydalangan holda takrorlash uchun tranzaktsiyaga va tranzaktsiyaning o'ziga javob yuboradi.
• Gateway markaziy tugundan javob oladi va uni mijozga yuboradi.
• Bir muncha vaqt o'tgach, Gateway replikatsiya mexanizmi orqali tranzaktsiyani qabul qiladi va bu safar u ma'lumotlar tuzilmalarini o'zgartirib, keyingi ma'lumotlar so'rovlarida eng so'nggi ma'lumotlarni ko'rsatadigan tarzda uni amalga oshiradi.

Aslida, u Gateway savdo tizimida amalga oshirilgan harakatlarni to'liq takrorlagan replikatsiya modelini tasvirlaydi. Alohida replikatsiya kanali tranzaktsiyalarning bir nechta kirish tugunlarida bir xil tartibda bajarilishini ta'minladi.

Kod bitta ipli bo'lganligi sababli, ko'plab mijozlarga xizmat ko'rsatish uchun texnologik vilkalar bilan klassik sxema ishlatilgan. Biroq, butun ma'lumotlar bazasini ajratish juda qimmatga tushdi, shuning uchun TCP seanslaridan paketlarni to'playdigan va ularni bitta navbatga (SystemV Message Queue) o'tkazadigan engil xizmat jarayonlari ishlatilgan. Gateway va Trade Engine faqat shu navbat bilan ishlagan va u yerdan tranzaktsiyalarni bajarish uchun olgan. Unga javob yuborishning iloji bo'lmadi, chunki qaysi xizmat jarayoni uni o'qishi kerakligi aniq emas edi. Shunday qilib, biz hiyla-nayrangga murojaat qildik: har bir fork-protsess o'zi uchun javob navbatini yaratdi va so'rov kiruvchi navbatga kelganda, darhol unga javob navbati uchun teg qo'shildi.

Doimiy ravishda katta hajmdagi ma'lumotlarni navbatdan navbatga nusxalash, ayniqsa, ma'lumot so'rovlari uchun odatiy muammolarni yaratdi. Shuning uchun biz yana bir hiyla ishlatdik: javob navbatiga qo'shimcha ravishda har bir jarayon umumiy xotira (SystemV Shared Memory) ham yaratdi. Unga paketlarning o'zi joylashtirildi va navbatda faqat teg saqlangan bo'lib, u asl paketni topishga imkon berdi. Bu protsessor keshida ma'lumotlarni saqlashga yordam berdi.

SystemV IPC navbat, xotira va semafor ob'ektlari holatini ko'rish uchun yordamchi dasturlarni o'z ichiga oladi. Biz bundan ma'lum bir vaqtda tizimda nima sodir bo'layotganini, paketlar qaerda to'planganini, nima bloklanganligini va hokazolarni tushunish uchun faol foydalandik.

Birinchi modernizatsiyalar

Avvalo, biz bitta jarayonli Gatewaydan xalos bo'ldik. Uning muhim kamchiligi shundaki, u bitta replikatsiya operatsiyasini yoki mijozdan bitta ma'lumot so'rovini bajarishi mumkin edi. Va yuk ortib borayotganligi sababli, Gateway so'rovlarni qayta ishlash uchun ko'proq vaqt talab etadi va replikatsiya oqimini qayta ishlay olmaydi. Bundan tashqari, agar mijoz tranzaktsiyani yuborgan bo'lsa, unda siz faqat uning haqiqiyligini tekshirishingiz va uni keyingi yo'naltirishingiz kerak. Shuning uchun biz yagona Gateway jarayonini parallel ravishda ishlashi mumkin bo'lgan bir nechta komponentlar bilan almashtirdik: RW blokirovkasi yordamida umumiy xotira maydonida bir-biridan mustaqil ravishda ishlaydigan ko'p tarmoqli ma'lumotlar va tranzaksiya jarayonlari. Va shu bilan birga biz jo'natish va replikatsiya jarayonlarini joriy qildik.

Yuqori chastotali savdoning ta'siri

Arxitekturaning yuqoridagi versiyasi 2010 yilgacha mavjud edi. Shu bilan birga, biz endi HP Superdome serverlarining ishlashidan qoniqmadik. Bundan tashqari, PA-RISC arxitekturasi deyarli o'lik edi; sotuvchi hech qanday muhim yangilanishlarni taklif qilmadi. Natijada biz HP UX/PA RISC-dan Linux/x86-ga o'tishni boshladik. O'tish kirish serverlarini moslashtirish bilan boshlandi.

Nega biz yana arxitekturani o'zgartirishga majbur bo'ldik? Gap shundaki, yuqori chastotali savdo tizim yadrosidagi yuklanish profilini sezilarli darajada o'zgartirdi.

Aytaylik, bizda narxning sezilarli o'zgarishiga sabab bo'lgan kichik bitim bo'ldi - kimdir yarim milliard dollar sotib oldi. Bir necha millisekunddan keyin barcha bozor ishtirokchilari buni payqashadi va tuzatish kiritishni boshlaydilar. Tabiiyki, so'rovlar katta navbatga to'g'ri keladi, bu tizimni tozalash uchun uzoq vaqt kerak bo'ladi.

Ushbu 50 ms oraliqda o'rtacha tezlik sekundiga taxminan 16 ming tranzaksiyani tashkil qiladi. Agar oynani 20 ms ga kamaytirsak, biz sekundiga o'rtacha 90 ming tranzaksiyani olamiz, eng yuqori nuqtada 200 ming tranzaksiya. Boshqacha qilib aytganda, yuk doimiy emas, to'satdan portlashlar bilan. Va so'rovlar navbati har doim tez qayta ishlanishi kerak.

Lekin nima uchun umuman navbat bor? Shunday qilib, bizning misolimizda ko'plab foydalanuvchilar narx o'zgarishini payqashdi va shunga mos ravishda tranzaktsiyalarni jo'natishdi. Ular Gateway-ga kelishadi, u ularni ketma-ketlashtiradi, ma'lum bir tartibni o'rnatadi va ularni tarmoqqa yuboradi. Routerlar paketlarni aralashtirib yuboradilar va ularni uzatadilar. Kimning paketi birinchi bo'lib kelgan bo'lsa, bu tranzaksiya "yutdi". Natijada, birja mijozlari, agar bir xil tranzaktsiya bir nechta shlyuzlardan yuborilgan bo'lsa, uni tezda qayta ishlash imkoniyatlari ortib borayotganini payqashdi. Ko'p o'tmay, birja robotlari Gatewayni so'rovlar bilan bombardimon qila boshladilar va tranzaktsiyalar ko'chkisi paydo bo'ldi.

Evolyutsiyaning yangi bosqichi

Keng ko'lamli sinov va tadqiqotlardan so'ng biz real vaqtda operatsion tizim yadrosiga o'tdik. Buning uchun biz RedHat Enterprise MRG Linux-ni tanladik, bu erda MRG real vaqtda xabar almashish tarmog'ini anglatadi. Haqiqiy vaqt rejimidagi yamoqlarning afzalligi shundaki, ular tizimni iloji boricha tezroq bajarish uchun optimallashtiradi: barcha jarayonlar FIFO navbatiga joylashtirilgan, yadrolarni ajratib olish mumkin, chiqarib tashlashlar yo'q, barcha tranzaktsiyalar qat'iy ketma-ketlikda qayta ishlanadi.

Qizil - oddiy yadroda navbat bilan ishlash, yashil - real vaqt yadrosida ishlash.

Ammo oddiy serverlarda past kechikishga erishish unchalik oson emas:

• X86 arxitekturasida muhim tashqi qurilmalar bilan ishlash uchun asos bo'lgan SMI rejimi katta xalaqit beradi. Har qanday apparat hodisalarini qayta ishlash va komponentlar va qurilmalarni boshqarish proshivka tomonidan shaffof SMI deb ataladigan rejimda amalga oshiriladi, bunda operatsion tizim proshivka nima qilayotganini umuman ko'rmaydi. Qoida tariqasida, barcha yirik sotuvchilar SMI ishlov berish hajmini kamaytirishga imkon beruvchi proshivka serverlari uchun maxsus kengaytmalarni taklif qilishadi.
• Protsessor chastotasining dinamik nazorati bo'lmasligi kerak, bu qo'shimcha ishlamay qolishga olib keladi.
• Fayl tizimi jurnali tozalanganda, yadroda oldindan aytib bo'lmaydigan kechikishlarni keltirib chiqaradigan ba'zi jarayonlar sodir bo'ladi.
• CPU yaqinligi, Interrupt yaqinligi, NUMA kabi narsalarga e'tibor berishingiz kerak.

Aytishim kerakki, real vaqtda ishlov berish uchun Linux apparati va yadrosini o'rnatish mavzusi alohida maqolaga loyiqdir. Biz yaxshi natijaga erishishimizdan oldin ko'p vaqtni tajriba va izlanishlarga sarfladik.

PA-RISC serverlaridan x86 ga o'tishda biz tizim kodini deyarli o'zgartirishimiz shart emas edi, biz uni moslashtirdik va qayta sozladik. Shu bilan birga, biz bir nechta xatolarni tuzatdik. Masalan, PA RISC Big endian tizimi, x86 esa Little endian tizimi bo'lishining oqibatlari tezda yuzaga chiqdi: masalan, ma'lumotlar noto'g'ri o'qilgan. Eng qiyin xato PA RISC foydalanadi izchil izchil (Ketma-ket izchil) xotiraga kirish, x86 esa o'qish operatsiyalarini qayta tartiblashi mumkin, shuning uchun bir platformada mutlaqo amal qilgan kod boshqa platformada buzildi.

X86 ga o'tgandan so'ng, unumdorlik deyarli uch baravar oshdi, tranzaksiyani qayta ishlashning o'rtacha vaqti 60 ms ga kamaydi.

Keling, tizim arxitekturasiga qanday asosiy o'zgarishlar kiritilganligini batafsil ko'rib chiqaylik.

Issiq zaxira epik

Tovar serverlariga o'tayotganda, biz ular kamroq ishonchli ekanligini bilardik. Shuning uchun, yangi arxitekturani yaratishda biz bir yoki bir nechta tugunlarning ishdan chiqishi ehtimolini aprior deb hisobladik. Shuning uchun, zaxira mashinalariga juda tez o'tishi mumkin bo'lgan issiq kutish tizimi kerak edi.

Bundan tashqari, boshqa talablar ham bor edi:

• Hech qanday holatda siz qayta ishlangan tranzaktsiyalarni yo'qotmasligingiz kerak.
• Tizim bizning infratuzilmamiz uchun mutlaqo shaffof bo'lishi kerak.
• Mijozlar uzilgan ulanishlarni ko'rmasligi kerak.
• Rezervasyonlar sezilarli kechikishga olib kelmasligi kerak, chunki bu almashinuv uchun muhim omil.

Issiq kutish tizimini yaratishda biz ikki tomonlama nosozliklar kabi stsenariylarni hisobga olmadik (masalan, bitta serverdagi tarmoq ishlashni to'xtatdi va asosiy server muzlatib qo'ydi); dasturiy ta'minotdagi xatolar ehtimolini hisobga olmadi, chunki ular test paytida aniqlangan; va apparatning noto'g'ri ishlashini hisobga olmadi.

Natijada biz quyidagi sxemaga keldik:

• Asosiy server Gateway serverlari bilan bevosita o'zaro aloqada bo'ldi.
• Asosiy serverda qabul qilingan barcha tranzaktsiyalar bir zumda alohida kanal orqali zaxira serverga takrorlandi. Agar biron bir muammo yuzaga kelsa, hakam (gubernator) almashtirishni muvofiqlashtirdi.

  

• Asosiy server har bir tranzaksiyani qayta ishladi va zaxira serverdan tasdiqlashni kutdi. Kechikishni minimallashtirish uchun biz zaxira serverida tranzaksiya tugashini kutishdan qochdik. Tranzaktsiyaning tarmoq bo'ylab sayohat qilish vaqti bajarilish vaqti bilan taqqoslanganligi sababli, qo'shimcha kechikish qo'shilmagan.
• Biz faqat oldingi tranzaksiya uchun asosiy va zaxira serverlarning qayta ishlash holatini tekshirishimiz mumkin edi va joriy tranzaksiyaning qayta ishlash holati noma'lum edi. Biz hali ham bitta oqimli jarayonlardan foydalanganimiz sababli, Zaxiradan javob kutish butun ishlov berish jarayonini sekinlashtirgan bo'lar edi, shuning uchun biz oqilona murosaga keldik: biz oldingi tranzaksiya natijasini tekshirdik.

Sxema quyidagicha ishladi.

Aytaylik, asosiy server javob berishni to'xtatadi, lekin shlyuzlar aloqa qilishda davom etadi. Zaxira serverida vaqt tugashi sodir bo'ladi, u Gubernator bilan bog'lanadi, u unga asosiy server rolini tayinlaydi va barcha shlyuzlar yangi asosiy serverga o'tadi.

Agar asosiy server yana onlayn bo'lsa, u ichki vaqt tugashini ham keltirib chiqaradi, chunki ma'lum vaqt davomida Gatewaydan serverga qo'ng'iroqlar bo'lmagan. Keyin u ham hokimga murojaat qiladi va uni sxemadan chiqarib tashlaydi. Natijada, birja savdo davrining oxirigacha bitta server bilan ishlaydi. Serverning ishlamay qolish ehtimoli juda past bo'lganligi sababli, ushbu sxema juda maqbul deb topildi, unda murakkab mantiq yo'q edi va sinovdan o'tkazish oson edi.

Davomi bor.

Manba: www.habr.com