Évolusi arsitektur sistem perdagangan lan ngresiki Moscow Exchange. Bagean 1

Halo kabeh! Jenengku Sergey Kostanbaev, ing Exchange aku ngembangake inti sistem dagang.

Nalika film-film Hollywood nuduhake Bursa Saham New York, mesthi katon kaya mangkene: akeh wong, kabeh padha bengok-bengok, waving kertas, kekacauan lengkap kedadeyan. Iki ora tau kedadeyan ing Moscow Exchange, amarga dagang wis ditindakake kanthi elektronik wiwit wiwitan lan adhedhasar rong platform utama - Spectra (pasar forex) lan ASTS (pasar valuta asing, saham lan dhuwit). Lan dina iki aku arep ngomong babagan evolusi arsitektur sistem perdagangan lan ngresiki ASTS, babagan macem-macem solusi lan temuan. Critane bakal dawa, mula aku kudu dibagi dadi rong bagean.

Kita minangka salah siji saka sawetara ijol-ijolan ing donya sing dagang aset kabeh kelas lan nyedhiyakake layanan ijol-ijolan sing lengkap. Contone, taun kepungkur kita peringkat nomer loro ing donya babagan volume dagang obligasi, posisi kaping 25 ing antarane kabeh bursa saham, posisi kaping 13 ing kapitalisasi antarane bursa umum.

Kanggo peserta dagang profesional, paramèter kayata wektu nanggepi, stabilitas distribusi wektu (jitter) lan linuwih saka kompleks kabeh kritis. Saiki kita proses puluhan yuta transaksi saben dina. Pangolahan saben transaksi dening kernel sistem mbutuhake puluhan mikrodetik. Mesthine, operator seluler ing Eve Taun Anyar utawa mesin telusur dhewe duwe beban kerja sing luwih dhuwur tinimbang kita, nanging ing babagan beban kerja, ditambah karo karakteristik sing kasebut ing ndhuwur, sawetara bisa mbandhingake karo kita, kayane aku. Ing wektu sing padha, penting kanggo kita manawa sistem kasebut ora alon-alon, bisa digunakake kanthi stabil, lan kabeh pangguna padha.

Sajarah sethitik

Ing taun 1994, sistem ASTS Australia diluncurake ing Moskow Interbank Currency Exchange (MICEX), lan wiwit wektu iku sejarah dagang elektronik Rusia bisa diitung. Ing taun 1998, arsitektur ijol-ijolan dimodernisasi kanggo ngenalake perdagangan Internet. Wiwit kuwi, kacepetan implementasine solusi anyar lan owah-owahan arsitektur ing kabeh sistem lan subsistem mung entuk momentum.

Ing taun-taun kasebut, sistem ijol-ijolan makarya ing hardware dhuwur - server HP Superdome 9000 sing bisa dipercaya (dibangun ing PA-RISIKO), sing pancen kabeh diduplikasi: subsistem input / output, jaringan, RAM (nyatane, ana RAID array RAM), prosesor (hot-swappable). Sampeyan bisa ngganti komponen server apa wae tanpa mandheg mesin. Kita ngandelake piranti kasebut lan dianggep meh ora aman. Sistem operasi kasebut minangka sistem HP UX sing kaya Unix.

Nanging wiwit udakara 2010, ana fenomena sing diarani perdagangan frekuensi dhuwur (HFT), utawa dagang frekuensi dhuwur - mung diucapake, robot bursa saham. Ing mung 2,5 taun, beban ing server kita wis tambah 140 kaping.

Ora bisa nahan beban kasebut kanthi arsitektur lan peralatan lawas. Iku perlu kanggo piye wae adaptasi.

Начало

Panjaluk menyang sistem ijol-ijolan bisa dipérang dadi rong jinis:

• Transaksi. Yen sampeyan pengin tuku dolar, saham utawa liya-liyane, sampeyan ngirim transaksi menyang sistem dagang lan nampa respon babagan sukses.
• Panjaluk informasi. Yen sampeyan pengin ngerteni rega saiki, deleng buku pesenan utawa indeks, banjur kirim panjalukan informasi.

Secara skematis, inti sistem bisa dipérang dadi telung tingkat:

• Tingkat klien, ing ngendi makelar lan klien bisa digunakake. Kabeh padha sesambungan karo server akses.
• Server gateway minangka server caching sing ngolah kabeh panjalukan informasi sacara lokal. Apa sampeyan pengin ngerti rega saham Sberbank saiki didagang? Panjaluk kasebut menyang server akses.
• Nanging yen sampeyan pengin tuku saham, panjaluk kasebut menyang server pusat (Mesin Perdagangan). Ana siji server kasebut kanggo saben jinis pasar, dheweke duwe peran penting, yaiku kanggo wong-wong mau sing nggawe sistem iki.

Inti saka sistem dagang yaiku database ing memori sing cerdas ing ngendi kabeh transaksi minangka transaksi ijol-ijolan. Basis kasebut ditulis ing C, siji-sijine dependensi eksternal yaiku perpustakaan libc lan ora ana alokasi memori dinamis. Kanggo nyuda wektu pangolahan, sistem diwiwiti kanthi susunan susunan statis lan relokasi data statis: pisanan, kabeh data kanggo dina saiki dimuat ing memori, lan ora ana akses disk maneh, kabeh karya mung ditindakake ing memori. Nalika sistem diwiwiti, kabeh data referensi wis diurutake, mula telusuran bisa dianggo kanthi efisien lan butuh wektu sethithik sajrone runtime. Kabeh tabel digawe karo dhaptar intrusive lan wit kanggo struktur data dinamis supaya padha ora mbutuhake alokasi memori nalika runtime.

Ayo goleki kanthi ringkes sejarah pangembangan sistem perdagangan lan kliring kita.
Versi pisanan saka arsitektur sistem dagang lan ngresiki dibangun ing apa sing disebut interaksi Unix: memori sing dienggo bareng, semaphore lan antrian digunakake, lan saben proses dumadi saka benang siji. Pendekatan iki nyebar ing awal taun 1990-an.

Versi pisanan sistem kasebut ngemot rong tingkat Gateway lan server tengah sistem dagang. Alur kerja kaya iki:

• Klien ngirim panjalukan, sing tekan Gateway. Iku mriksa validitas format (nanging ora data dhewe) lan nolak transaksi salah.
• Yen panjalukan informasi wis dikirim, dileksanakake sacara lokal; yen kita ngomong babagan transaksi, banjur dialihake menyang server tengah.
• Mesin dagang banjur ngolah transaksi kasebut, ngowahi memori lokal, lan ngirim respon kanggo transaksi lan transaksi kasebut dhewe kanggo replikasi nggunakake mesin replikasi sing kapisah.
• Gateway nampa respon saka simpul tengah lan nerusake menyang klien.
• Sawise sawetara wektu, Gateway nampa transaksi liwat mekanisme replikasi, lan wektu iki dieksekusi sacara lokal, ngganti struktur data supaya panjalukan informasi sabanjure nampilake data paling anyar.

Nyatane, iki nggambarake model replikasi sing Gateway rampung replikasi tumindak sing ditindakake ing sistem dagang. Saluran replikasi sing kapisah mesthekake yen transaksi ditindakake kanthi urutan sing padha ing sawetara simpul akses.

Wiwit kode kasebut nganggo benang tunggal, skema klasik kanthi garpu proses digunakake kanggo nglayani akeh klien. Nanging, iku larang banget kanggo garpu kabeh database, supaya pangolahan layanan entheng digunakake sing ngumpulake paket saka sesi TCP lan ditransfer menyang siji antrian (SystemV Message Queue). Gateway lan Trade Engine mung makarya karo antrian iki, njupuk transaksi saka kono kanggo eksekusi. Sampeyan ora bisa ngirim respon maneh, amarga ora jelas proses layanan sing kudu diwaca. Dadi, kita nggunakake trik: saben proses bercabang nggawe antrian respon kanggo awake dhewe, lan nalika ana panjaluk teka ing antrian sing mlebu, tag kanggo antrian respon langsung ditambahake.

Terus-terusan nyalin data saka antrian menyang antrian nggawe masalah, utamane khas kanggo panjaluk informasi. Mulane, kita nggunakake trik liyane: saliyane antrian respon, saben proses uga nggawe memori bareng (SystemV Shared Memory). Paket kasebut dhewe diselehake ing kono, lan mung ana tag sing disimpen ing antrian, supaya bisa nemokake paket asli. Iki mbantu kanggo nyimpen data ing cache prosesor.

SystemV IPC kalebu utilitas kanggo ndeleng kahanan antrian, memori, lan obyek semafor. Iki digunakake kanthi aktif kanggo ngerti apa sing kedadeyan ing sistem ing wektu tartamtu, ing ngendi paket akumulasi, apa sing diblokir, lsp.

Nganyari pisanan

Kaping pisanan, kita nyingkirake Gateway siji-proses. Kelemahane sing signifikan yaiku bisa nangani siji transaksi replikasi utawa siji panjaluk informasi saka klien. Lan nalika beban mundhak, Gateway bakal njupuk maneh kanggo proses panjalukan lan ora bakal bisa kanggo proses aliran réplikasi. Kajaba iku, yen klien ngirim transaksi, sampeyan mung kudu mriksa kesahihan lan nerusake luwih lanjut. Mulane, kita diganti siji proses Gateway karo sawetara komponen sing bisa mlaku ing podo karo: informasi multi-Utas lan pangolahan transaksi mlaku independen saben liyane ing wilayah memori sambungan nggunakake RW ngunci. Lan ing wektu sing padha, kita ngenalake proses pengiriman lan replikasi.

Dampak Dagang Frekuensi Dhuwur

Versi arsitektur ing ndhuwur ana nganti 2010. Kangge, kita padha ora wareg maneh karo kinerja server HP Superdome. Kajaba iku, arsitektur PA-RISC meh mati; vendor ora menehi nganyari sing signifikan. Akibaté, kita wiwit pindhah saka HP UX / PA RISC kanggo Linux / x86. Transisi diwiwiti kanthi adaptasi server akses.

Napa kita kudu ngganti arsitektur maneh? Kasunyatane yaiku dagang frekuensi dhuwur wis ngganti profil beban ing inti sistem.

Ayo kita duwe transaksi cilik sing nyebabake owah-owahan rega sing signifikan - ana sing tuku setengah milyar dolar. Sawise sawetara milliseconds, kabeh peserta pasar sok dong mirsani iki lan wiwit nggawe koreksi. Alamiah, panjalukan baris ing antrian ageng, kang sistem bakal njupuk dangu kanggo mbusak.

Ing interval 50 ms iki, kacepetan rata-rata kira-kira 16 ewu transaksi per detik. Yen kita nyuda jendhela dadi 20 ms, kita entuk kacepetan rata-rata 90 ewu transaksi per detik, kanthi 200 ewu transaksi ing puncak. Ing tembung liya, beban kasebut ora tetep, kanthi bledosan dadakan. Lan antrian panjaluk kudu diproses kanthi cepet.

Nanging kok ana antrian kabeh? Dadi, ing conto kita, akeh pangguna sing ngerteni owah-owahan rega lan ngirim transaksi sing cocog. Padha teka Gateway, serializes wong, mranata urutan tartamtu lan dikirim menyang jaringan. Router ngacak paket lan nerusake. Sing paket teka pisanan, sing transaksi "menang". Akibaté, ijol-ijolan klien wiwit sok dong mirsani yen transaksi padha dikirim saka sawetara Gateways, banjur kemungkinan Processing cepet tambah. Ora suwe, robot ijol-ijolan wiwit mbombardir Gateway kanthi panjaluk, lan ana longsoran transaksi.

A babak anyar évolusi

Sawise tes lan riset ekstensif, kita ngalih menyang kernel sistem operasi wektu nyata. Iki kita milih RedHat Enterprise MRG Linux, ngendi MRG stands kanggo olahpesen nyata-wektu kothak. Kauntungan saka patch wektu nyata yaiku ngoptimalake sistem kanggo eksekusi paling cepet: kabeh proses diantrekake ing antrian FIFO, inti bisa diisolasi, ora ana ejections, kabeh transaksi diproses kanthi urutan sing ketat.

Abang - nggarap antrian ing kernel biasa, ijo - digunakake ing kernel wektu nyata.

Nanging entuk latensi sing sithik ing server biasa ora gampang:

• Mode SMI, sing ing arsitektur x86 minangka basis kanggo nggarap periferal penting, ngganggu banget. Ngolah kabeh jinis acara hardware lan manajemen komponen lan piranti ditindakake dening perangkat kukuh ing mode SMI sing disebut transparan, ing ngendi sistem operasi ora weruh apa sing ditindakake perangkat kukuh. Minangka aturan, kabeh vendor utama nawakake ekstensi khusus kanggo server perangkat kukuh sing ngidini nyuda jumlah pangolahan SMI.
• Mesthine ora ana kontrol dinamis frekuensi prosesor, iki ndadékaké downtime tambahan.
• Nalika log sistem file disiram, proses tartamtu dumadi ing kernel sing nyebabake keterlambatan sing ora bisa ditebak.
• Sampeyan kudu nggatekake perkara kaya CPU Affinity, Interrupt afinity, NUMA.

Aku kudu ujar manawa topik nyiyapake hardware lan kernel Linux kanggo proses realtime pantes artikel sing kapisah. Kita nglampahi akeh wektu kanggo nyobi lan riset sadurunge entuk asil sing apik.

Nalika mindhah saka server PA-RISC kanggo x86, kita prakteke ora kudu ngganti kode sistem akeh, kita mung dicocogake lan reconfigured. Ing wektu sing padha, kita ndandani sawetara kewan omo. Contone, jalaran saka kasunyatan sing PA RISC ana sistem Big endian, lan x86 ana sistem Little endian, cepet surfaced: contone, data diwaca salah. Bug trickier sing nggunakake PA RISC konsisten konsisten (Sequentially konsisten) akses memori, dene x86 bisa ngatur maneh operasi maca, supaya kode sing pancen bener ing siji platform dadi rusak ing platform liyane.

Sawise ngalih menyang x86, kinerja mundhak meh telu, rata-rata wektu pangolahan transaksi mudhun kanggo 60 μs.

Saiki ayo dipikirake kanthi cetha apa owah-owahan utama sing wis digawe kanggo arsitektur sistem.

Epik cadangan panas

Nalika ngalih menyang server komoditas, kita padha weruh sing padha kurang dipercaya. Mulane, nalika nggawe arsitektur anyar, kita a priori nganggep kamungkinan Gagal siji utawa luwih simpul. Mulane, perlu sistem siyaga panas sing bisa cepet ngalih menyang mesin serep.

Kajaba iku, ana syarat liyane:

• Ing kahanan apa wae sampeyan kudu kelangan transaksi sing wis diproses.
• Sistem kasebut kudu transparan banget kanggo infrastruktur kita.
• Klien ngirim ora ndeleng sambungan dropped.
• Reservasi ngirim ora ngenalake wektu tundha sing signifikan amarga iki minangka faktor kritis kanggo ijol-ijolan.

Nalika nggawe sistem siyaga panas, kita ora nganggep skenario kaya kegagalan kaping pindho (contone, jaringan ing siji server mandheg lan server utama beku); ora nganggep kemungkinan kesalahan ing piranti lunak amarga diidentifikasi sajrone tes; lan ora nimbang operasi salah saka hardware.

Akibaté, kita teka ing skema ing ngisor iki:

• Server utama berinteraksi langsung karo server Gateway.
• Kabeh transaksi sing ditampa ing server utama langsung ditiru menyang server serep liwat saluran sing kapisah. Arbiter (Gubernur) koordinasi switching yen ana masalah.

  

• Server utama ngolah saben transaksi lan ngenteni konfirmasi saka server serep. Supaya latensi minimal, kita nyingkiri nunggu transaksi rampung ing server serep. Wiwit wektu sing dibutuhake kanggo transaksi ngliwati jaringan bisa dibandhingake karo wektu eksekusi, ora ana latensi tambahan sing ditambahake.
• Kita mung bisa mriksa status pangolahan server utama lan serep kanggo transaksi sadurunge, lan status pangolahan transaksi saiki ora dingerteni. Awit kita isih nggunakake pangolahan siji-Utas, nunggu respon saka Serep bakal kalem mudhun kabeh aliran Processing, supaya kita nggawe kompromi cukup: kita mriksa asil saka transaksi sadurungé.

Skema kasebut ditindakake kaya ing ngisor iki.

Ayo dadi server utama mandheg nanggapi, nanging Gateways terus komunikasi. A wektu entek ana ing server serep, iku kontak Gubernur, sing nemtokake peran saka server utama, lan kabeh Gateways ngalih menyang server utama anyar.

Yen server utama bali online, uga micu wektu entek internal, amarga wis ora ana telpon menyang server saka Gateway kanggo wektu tartamtu. Banjur dheweke uga bali menyang Gubernur, lan ora kalebu rencana kasebut. Akibaté, ijol-ijolan bisa digunakake karo siji server nganti pungkasan periode dagang. Amarga kemungkinan kegagalan server cukup sithik, skema iki dianggep cukup ditrima, ora ngemot logika rumit lan gampang dites.

Kanggo terus.

Source: www.habr.com