Évolusi arsitéktur dagang jeung sistem clearing tina Moscow Exchange. Bagian 1

Halo sadayana! Nami abdi Sergey Kostanbaev, di Bursa Abdi ngembangkeun inti sistem dagang.

Nalika pilem Hollywood nunjukkeun Bursa Saham New York, sigana sapertos kieu: balaréa jalma-jalma, sadayana ngagorowok, ngalambai kertas, huru-hara lengkep. Ieu henteu kantos kajantenan di dieu di Bursa Moskow, sabab dagang parantos dilakukeun sacara éléktronik ti mimiti sareng didasarkeun kana dua platform utama - Spectra (pasar forex) sareng ASTS (pasar asing, saham sareng pasar uang). Sareng ayeuna kuring hoyong ngobrol ngeunaan évolusi arsitéktur perdagangan ASTS sareng sistem ngabersihan, ngeunaan rupa-rupa solusi sareng papanggihan. Carita bakal panjang, jadi kuring kungsi megatkeun eta jadi dua bagian.

Kami salah sahiji ti saeutik bursa di dunya nu trades aset sadaya kelas jeung nyadiakeun rentang pinuh ku jasa bursa. Contona, taun ka tukang urang rengking kadua di dunya dina hal volume dagang beungkeut, tempat 25th diantara sakabeh bursa saham, tempat 13th di kapitalisasi diantara séntral umum.

Pikeun pamilon dagang profésional, parameter sapertos waktos respon, stabilitas sebaran waktos (jitter) jeung reliabilitas sakabéh kompléks anu kritis. Urang ayeuna ngolah puluhan juta transaksi per poé. Ngolah unggal transaksi ku kernel sistem butuh puluhan microseconds. Tangtosna, operator sélulér dina Hawa Taun Anyar atanapi mesin pencari sorangan ngagaduhan beban kerja anu langkung luhur tibatan urang, tapi tina segi beban kerja, ditambah ku ciri anu disebatkeun di luhur, sababaraha anu tiasa dibandingkeun sareng urang, sigana kuring. Dina waktos anu sami, penting pikeun urang yén sistemna henteu ngalambatkeun sadetik, jalanna leres-leres stabil, sareng sadaya pangguna dina suku anu sami.

Sajarah saeutik

Dina 1994, sistem ASTS Australia diluncurkeun dina Moscow Interbank Currency Exchange (MICEX), sareng ti saprak éta sajarah Rusia perdagangan éléktronik tiasa diitung. Dina 1998, arsitéktur bursa dimodernisasi pikeun ngawanohkeun dagang Internét. Ti saprak éta, laju palaksanaan solusi anyar sareng parobahan arsitéktur dina sadaya sistem sareng subsistem parantos kéngingkeun moméntum.

Dina taun-taun éta, sistem bursa dianggo dina hardware hi-end - server HP Superdome 9000 anu tiasa dipercaya (diwangun dina PA-RISIKO), anu leres pisan sadayana diduplikasi: subsistem input / output, jaringan, RAM (kanyataanna, aya RAID RAM), prosesor (panas-swappable). Ieu mungkin pikeun ngarobah sagala komponén server tanpa stopping mesin. Kami ngandelkeun alat-alat ieu sareng nganggap éta ampir gagal-aman. Sistem operasi éta sistem HP UX kawas Unix.

Tapi saprak ngeunaan 2010, fenomena geus mecenghul disebut dagang frékuénsi luhur (HFT), atawa dagang frékuénsi luhur - saukur nempatkeun, robot bursa saham. Dina ngan 2,5 taun, beban dina server kami geus ngaronjat 140 kali.

Teu mungkin pikeun nahan beban sapertos sareng arsitéktur sareng alat-alat kuno. Ieu diperlukeun pikeun kumaha bae adaptasi.

ngamimitian

Requests kana sistem bursa bisa dibagi jadi dua jenis:

• Transaksi. Upami anjeun hoyong mésér dollar, biasa atawa hal sejenna, Anjeun ngirim transaksi ka sistem perdagangan sarta nampa respon ngeunaan kasuksésan.
• pamundut informasi. Upami anjeun hoyong terang harga ayeuna, tingali buku pesenan atanapi indeks, teras kirimkeun pamundut inpormasi.

Sacara skematis, inti sistem tiasa dibagi kana tilu tingkat:

• Tingkat klien, dimana calo sareng klien damel. Éta sadayana berinteraksi sareng server aksés.
• Server gateway mangrupikeun server cache anu sacara lokal ngolah sadaya pamundut inpormasi. Naha anjeun hoyong terang naon harga saham Sberbank ayeuna didagangkeun? Paménta angkat ka server aksés.
• Tapi upami anjeun hoyong mésér saham, teras pamenta angkat ka server sentral (Mesin Dagang). Aya hiji server misalna pikeun tiap jenis pasar, maranéhna maénkeun peran vital, éta pikeun aranjeunna urang dijieun sistem ieu.

Inti sistem perdagangan nyaéta database pinter dina mémori dimana sadaya transaksi mangrupikeun transaksi bursa. Dasarna ditulis dina C, hiji-hijina katergantungan éksternal nyaéta perpustakaan libc sareng teu aya alokasi mémori dinamis pisan. Pikeun ngirangan waktos ngolah, sistem dimimitian ku susunan statik sareng relokasi data statik: kahiji, sadaya data kanggo dinten ayeuna dimuat kana mémori, sareng henteu aya aksés disk salajengna, sadaya padamelan dilaksanakeun ukur dina mémori. Nalika sistem dimimitian, sadaya data rujukan parantos diurutkeun, ku kituna pamilarian tiasa dianggo pisan éfisién sareng sakedik waktos dina runtime. Kabéh tabel dijieun kalawan daptar intrusive jeung tangkal pikeun struktur data dinamis ambéh maranéhanana teu merlukeun alokasi memori dina runtime.

Hayu urang sakeudeung balik kana sajarah ngembangkeun sistem dagang jeung clearing urang.
Versi kahiji tina dagang jeung sistem clearing arsitéktur diwangun dina disebut interaksi Unix: memori dibagikeun, semaphores na antrian dipaké, sarta unggal prosés diwangun ku hiji thread tunggal. Pendekatan ieu nyebar di awal taun 1990-an.

Versi munggaran sistem ngandung dua tingkat Gateway sarta server sentral tina sistem dagang. Aliran kerja sapertos kieu:

• Klién ngirimkeun pamundut, anu ngahontal Gateway. Éta pariksa validitas formatna (tapi sanés datana nyalira) sareng nolak transaksi anu salah.
• Upami pamundut inpormasi parantos dikirim, éta dilaksanakeun sacara lokal; lamun urang keur diajak ngobrol ngeunaan transaksi, mangka dialihkeun ka server sentral.
• Mesin dagang lajeng ngolah urus, modifies memori lokal, sarta ngirimkeun respon kana urus jeung urus sorangan pikeun réplikasi maké mesin réplikasi misah.
• Gateway nampi réspon ti titik sentral sareng diteruskeun ka klien.
• Saatos sababaraha waktos, Gateway nampi transaksi ngaliwatan mékanisme réplikasi, sareng waktos ieu ngalaksanakeunana sacara lokal, ngarobih struktur datana supados pamundut inpormasi salajengna nampilkeun data panganyarna.

Kanyataanna, eta ngajelaskeun model réplikasi nu Gateway lengkep replicated lampah dipigawé dina sistem dagang. Saluran réplikasi anu misah mastikeun yén transaksi dilaksanakeun dina urutan anu sami dina sababaraha titik aksés.

Kusabab kode éta single-threaded, skéma Palasik kalawan garpu prosés dipaké pikeun ngalayanan loba klien. Sanajan kitu, éta pisan mahal pikeun garpu sakabéh database, jadi dipaké prosés jasa lightweight anu ngumpulkeun pakét ti sesi TCP sarta mindahkeun kana hiji antrian (SystemV Message Queue). Gateway sareng Trade Engine ngan ukur damel sareng antrian ieu, nyandak transaksi ti dinya pikeun dieksekusi. Éta henteu deui tiasa ngirim réspon kana éta, sabab henteu écés prosés jasa mana anu kedah dibaca. Ku kituna kami resorted ka trik a: unggal prosés forked dijieun antrian respon pikeun sorangan, sarta lamun pamundut sumping kana antrian asup, tag pikeun antrian respon ieu geuwat ditambahkeun kana eta.

Terus nyalin jumlah badag data ti antrian ka antrian dijieun masalah, utamana has pikeun requests informasi. Kituna, kami dipaké trik sejen: salian antrian respon, unggal prosés ogé dijieun memori dibagikeun (SystemV Shared Mémori). Bungkusan sorangan disimpen di jerona, sareng ngan ukur tag anu disimpen dina antrian, anu ngamungkinkeun anjeun mendakan bungkusan aslina. Ieu mantuan pikeun nyimpen data dina cache processor.

SystemV IPC ngawengku utilitas pikeun nempo kaayaan antrian, memori, jeung objék semafor. Kami aktip ngagunakeun ieu pikeun ngartos naon anu lumangsung dina sistem dina waktos anu khusus, dimana pakét akumulasi, naon anu diblokir, jsb.

Modernisasi munggaran

Munggaran sadaya, urang meunang leupas tina single-prosés Gateway. Kelemahan anu penting nyaéta yén éta tiasa ngadamel hiji transaksi réplikasi atanapi hiji pamundut inpormasi ti klien. Sareng nalika beban naék, Gateway bakal langkung lami pikeun ngolah pamundut sareng moal tiasa ngolah aliran réplikasi. Salaku tambahan, upami klien ngirim transaksi, anjeun ngan ukur kedah pariksa validitasna sareng teraskeun deui. Kituna, urang ngaganti prosés gateway tunggal kalawan sababaraha komponén nu bisa dijalankeun dina paralel: informasi multi-threaded jeung prosés urus ngajalankeun bebas saling dina aréa memori dibagikeun maké RW ngonci. Sareng dina waktos anu sami kami ngenalkeun prosés pangiriman sareng réplikasi.

Dampak Dagang Frékuénsi Luhur

Versi arsitéktur di luhur aya dugi ka 2010. Samentara éta, kami henteu deui wareg jeung kinerja server HP Superdome. Salaku tambahan, arsitéktur PA-RISC ampir maot; padagang henteu nawiskeun apdet anu signifikan. Hasilna, urang mimiti mindahkeun tina HP UX / PA RISC kana Linux / x86. Transisi dimimitian ku adaptasi server aksés.

Naha urang kudu ngarobah arsitektur deui? Kanyataan yén dagang frékuénsi luhur geus nyata robah profil beban dina inti sistem.

Anggap urang gaduh transaksi leutik anu nyababkeun parobahan harga anu signifikan - aya anu mésér satengah miliar dolar. Saatos sababaraha milidetik, sadaya pamilon pasar perhatikeun ieu sareng mimiti ngalakukeun koreksi. Alami, requests baris nepi dina antrian badag, nu sistem bakal butuh lila pikeun mupus.

Dina interval 50 ms ieu, laju rata-rata sakitar 16 rébu transaksi per detik. Upami urang ngirangan jandela ka 20 mdet, urang nampi laju rata-rata 90 rébu transaksi per detik, sareng 200 rébu transaksi di puncakna. Dina basa sejen, beban teu konstan, kalawan bursts dadakan. Jeung antrian requests kudu salawasna diolah gancang.

Tapi naha aya antrian pisan? Janten, dina conto urang, seueur pangguna ningali parobahan harga sareng ngirim transaksi sasuai. Aranjeunna datang ka gateway, eta serializes aranjeunna, susunan urutan tangtu sarta ngirimkeun aranjeunna ka jaringan. Router ngacak pakét sareng teraskeun. Saha pakét anu sumping heula, éta transaksi "menang". Hasilna, klien bursa mimiti aya bewara yen lamun urus sarua ieu dikirimkeun ti sababaraha Gateways, Chances ngolah gancang na ngaronjat. Moal lami deui, robot bursa mimiti bombarding Gateway kalawan requests, sarta hiji longsoran transaksi timbul.

Babak évolusi anyar

Saatos nguji éksténsif jeung panalungtikan, urang pindah ka kernel sistem operasi real-time. Pikeun ieu kami milih RedHat Enterprise MRG Linux, dimana MRG nangtung pikeun olahtalatah sacara real-time grid. Kauntungannana patches real-time nyaeta aranjeunna ngaoptimalkeun sistem pikeun palaksanaan panggancangna mungkin: kabéh prosés dijejeran dina antrian FIFO, cores bisa diisolasi, euweuh ejections, sadaya transaksi diolah dina urutan ketat.

Beureum - gawé bareng antrian dina kernel biasa, héjo - gawe dina kernel real-time.

Tapi ngahontal latency low dina server biasa teu jadi gampang:

• Modeu SMI, anu dina arsitéktur x86 mangrupikeun dasar pikeun damel sareng périferal penting, ngaganggu pisan. Ngolah sagala jinis acara hardware sareng manajemén komponén sareng alat dilakukeun ku firmware dina anu disebut mode SMI transparan, dimana sistem operasi henteu ningali naon anu dilakukeun ku firmware. Sakumaha aturan, sadaya padagang utama nawiskeun ekstensi khusus pikeun server firmware anu ngamungkinkeun ngirangan jumlah ngolah SMI.
• Sakuduna euweuh kontrol dinamis tina frékuénsi processor, ieu ngakibatkeun downtime tambahan.
• Nalika log sistem file disiram, prosés-prosés tangtu lumangsung dina kernel anu nyababkeun telat anu teu kaduga.
• Anjeun kedah nengetan hal sapertos CPU Affinity, Interrupt Afinity, NUMA.

Kuring kedah nyebatkeun yén topik nyetél hardware sareng kernel Linux pikeun pamrosésan sacara real-time pantes janten tulisan anu misah. Urang nyéépkeun seueur waktos ékspérimén sareng nalungtik sateuacan urang ngahontal hasil anu saé.

Nalika pindah ti server PA-RISC ka x86, urang praktis teu kudu ngarobah kodeu sistem teuing, urang ngan diadaptasi jeung reconfigured eta. Dina waktos anu sami, kami ngalereskeun sababaraha bug. Contona, konsékuansi tina kanyataan yén pa RISC éta sistem endian Big, sarta x86 éta sistem Little endian, gancang surfaced: Contona, data ieu salah maca. Bug trickier éta pamakéan pa RISC konsisten konsisten (Sequentially konsisten) aksés memori, sedengkeun x86 tiasa nyusun ulang operasi bacaan, ku kituna kode anu leres-leres valid dina hiji platform janten rusak dina platform anu sanés.

Saatos ngalih ka x86, kinerja ningkat ampir tilu kali lipat, rata-rata waktos ngolah transaksi turun ka 60 μs.

Hayu urang tingali langkung caket kana parobahan konci naon anu parantos dilakukeun kana arsitéktur sistem.

epik cadangan panas

Nalika ngalih ka server komoditi, kami sadar yén aranjeunna kirang dipercaya. Ku alatan éta, nalika nyieun arsitéktur anyar, urang a priori nganggap kamungkinan gagalna hiji atawa leuwih titik. Ku alatan éta, sistem sayaga panas diperlukeun anu bisa gancang pindah ka mesin cadangan.

Sajaba ti éta, aya sarat séjén:

• Dina kaayaan naon waé anjeun kedah kaleungitan transaksi anu diprosés.
• Sistemna kedah transparan pisan pikeun infrastruktur urang.
• Klién teu kedah ningali sambungan anu turun.
• Reservations teu kudu ngenalkeun reureuh signifikan sabab ieu faktor kritis pikeun bursa.

Nalika nyiptakeun sistem sayaga anu panas, urang henteu nganggap skenario sapertos gagal ganda (contona, jaringan dina hiji server lirén damel sareng server utama beku); henteu nganggap kamungkinan kasalahan dina parangkat lunak sabab diidentifikasi nalika tés; tur teu nganggap operasi lepat tina hardware.

Hasilna, urang sumping ka skéma handap:

• Server utama berinteraksi langsung sareng server Gateway.
• Sadaya transaksi anu ditampi dina server utama langsung direplikasi ka server cadangan via saluran anu misah. Arbiter (Gubernur) koordinasi switching lamun aya masalah timbul.

  

• Server utama ngolah unggal transaksi sareng ngantosan konfirmasi ti server cadangan. Pikeun ngajaga latency ka minimum, kami ngahindarkeun ngantosan urus réngsé dina server cadangan. Kusabab waktu nu diperlukeun pikeun urus ngarambat sakuliah jaringan éta comparable jeung waktu palaksanaan, euweuh latency tambahan ditambahkeun.
• Urang ukur bisa pariksa status processing tina server utama jeung cadangan pikeun urus saméméhna, sarta status processing tina transaksi ayeuna éta kanyahoan. Kusabab kami masih ngagunakeun prosés single-threaded, ngantosan respon ti Cadangan bakal ngalambatkeun turun sakabéh aliran processing, sangkan nyieun kompromi lumrah: urang pariksa hasil tina transaksi saméméhna.

skéma digawé saperti kieu.

Hayu urang nyebutkeun server utama eureun ngabales, tapi Gateways terus komunikasi. A timeout lumangsung dina server cadangan, eta ngahubungan Gubernur, anu napelkeun eta peran server utama, sarta sakabeh Gateways pindah ka server utama anyar.

Lamun server utama datang deui online, eta oge micu hiji timeout internal, sabab geus euweuh nelepon ka server ti Gateway pikeun waktu nu tangtu. Lajeng anjeunna ogé tos ka Gubernur, sarta anjeunna ngaluarkeun anjeunna ti skéma. Hasilna, bursa dianggo sareng hiji server dugi ka ahir jaman dagang. Kusabab kamungkinan gagalna server rada handap, skéma ieu dianggap cukup ditarima; teu ngandung logika kompléks sarta gampang pikeun nguji.

Terus dituluykeun.

sumber: www.habr.com