Ieu tuluyan tina carita panjang ngeunaan jalur thorny urang pikeun nyieun kuat, sistem beban tinggi nu ensures operasi Bursa. Bagian kahiji di dieu:
Kasalahan misterius
Saatos sababaraha tés, sistem perdagangan sareng clearing anu diropéa dioperasikeun, sareng urang mendakan bug anu tiasa nyerat carita detektif-mistis.
Teu lila sanggeus launching dina server utama, salah sahiji transaksi ieu diolah kalawan kasalahan. Sanajan kitu, sagalana éta rupa dina server cadangan. Tétéla yén operasi matematik basajan tina ngitung éksponén dina server utama masihan hasil négatip tina argumen nyata! Urang neraskeun panalungtikan urang, sarta dina SSE2 ngadaptar kami kapanggih béda dina hiji bit, nu jawab rounding nalika gawé bareng angka floating titik.
Kami nyerat utilitas tés saderhana pikeun ngitung éksponén kalayan set bit rounding. Tétéla yén dina versi RedHat Linux anu kami anggo, aya bug dina damel sareng fungsi matematika nalika bit nasibna diselapkeun. Kami ngalaporkeun ieu ka RedHat, saatos sababaraha waktos kami nampi patch ti aranjeunna sareng ngagulung. Kasalahan henteu deui kajantenan, tapi éta henteu écés dimana bit ieu asalna? fungsi éta jawab eta fesetround ti basa C. Urang taliti dianalisis kode urang dina pilarian tina kasalahan sakuduna dituju: urang dipariksa sagala kaayaan mungkin; melong sagala fungsi nu dipaké rounding; diusahakeun baranahan sési gagal; dipaké compiler béda jeung pilihan béda; Analisis statik sareng dinamis digunakeun.
Anu ngabalukarkeun kasalahan teu bisa kapanggih.
Teras aranjeunna mimiti mariksa hardware: aranjeunna ngalaksanakeun uji beban prosesor; dipariksa RAM; Kami malah ngajalankeun tés pikeun skenario anu teu mungkin tina kasalahan multi-bit dina hiji sél. Teu hasil.
Tungtungna, urang netep dina téori tina dunya fisika énergi tinggi: sababaraha partikel énergi tinggi flew kana puseur data urang, nojos témbok kasus, pencét processor sarta ngabalukarkeun kancing pemicu nempel dina éta pisan bit. Téori absurd ieu disebut "neutrino". Upami anjeun jauh tina fisika partikel: neutrino ampir henteu berinteraksi sareng dunya luar, sareng pastina henteu tiasa mangaruhan operasi prosesor.
Kusabab teu mungkin pikeun manggihan anu ngabalukarkeun gagalna, "nyinggung" server dihapus tina operasi ngan bisi.
Saatos sababaraha waktos, urang mimiti ningkatkeun sistem cadangan panas: urang ngenalkeun anu disebut "cadangan haneut" (haneut) - réplika asinkron. Aranjeunna nampi aliran transaksi nu bisa lokasina di puseur data béda, tapi warms teu aktip berinteraksi sareng server séjén.
Naha ieu dilakukeun? Lamun server cadangan gagal, teras haneut dihijikeun ka server utama jadi cadangan anyar. Nyaéta, saatos gagal, sistem henteu tetep sareng hiji server utama dugi ka ahir sési dagang.
Sarta lamun versi anyar tina sistem ieu diuji sarta nempatkeun kana operasi, kasalahan rounding bit lumangsung deui. Leuwih ti éta, kalawan ngaronjatna jumlah server haneut, kasalahan mimiti muncul leuwih sering. Dina waktos anu sami, padagang teu aya anu nunjukkeun, sabab henteu aya bukti anu konkrit.
Salila analisa kaayaan salajengna, timbul téori yén masalahna tiasa aya hubunganana sareng OS. Urang nulis program basajan nu nelepon hiji fungsi dina loop sajajalan fesetround, inget kaayaan ayeuna jeung pariksa deui ngaliwatan sare, sarta ieu dipigawé dina loba threads competing. Saatos milih parameter pikeun bobo sareng jumlah utas, urang mimitian sacara konsistén ngahasilkeun kagagalan bit saatos sakitar 5 menit ngajalankeun utiliti. Nanging, dukungan Red Hat henteu tiasa ngahasilkeun deui. Nguji server kami anu sanés nunjukkeun yén ngan ukur anu gaduh prosesor anu tangtu anu rentan kana kasalahan. Dina waktos anu sami, gentos ka kernel énggal ngarengsekeun masalah. Tungtungna, urang ngan saukur ngagentos OS, sareng panyababna bug tetep teu jelas.
Sarta ujug-ujug taun ka tukang artikel diterbitkeun dina Habré "" Kaayaan anu dijelaskeun dina éta sami pisan sareng urang, tapi panulis nyandak panyilidikan langkung jauh sareng teraskeun téori yén kasalahan éta aya dina microcode. Sareng nalika kernel Linux diénggalan, produsén ogé ngapdet microcode.
Ngembangkeun salajengna sistem
Sanajan urang meunang leupas tina kasalahan, carita ieu kapaksa urang nimbangkeun balik arsitéktur sistem. Barina ogé, urang teu ditangtayungan tina pengulangan bug misalna.
Prinsip-prinsip ieu janten dasar pikeun perbaikan salajengna pikeun sistem réservasi:
- Anjeun teu tiasa percanten ka saha. Server bisa jadi teu fungsi leres.
- Réservasi mayoritas.
- Mastikeun konsensus. Salaku tambahan logis pikeun mayoritas reservasi.
- Gagal ganda mungkin.
- Vitalitas. Skéma sayaga panas anyar kedahna henteu langkung parah tibatan anu sateuacana. Dagang kedah diteruskeun tanpa gangguan dugi ka server anu terakhir.
- Paningkatan saeutik dina latency. Sagala downtime merlukeun karugian finansial badag.
- Interaksi jaringan minimal pikeun ngajaga latency sakedik-gancang.
- Milih server master anyar dina sababaraha detik.
Henteu aya solusi anu aya di pasar anu cocog sareng kami, sareng protokol Raft masih aya dina infancy na, janten kami nyiptakeun solusi sorangan.
Jaringan
Salian sistem reservasi, urang mimiti modernisasi interaksi jaringan. Subsistem I / O diwangun ku seueur prosés, anu ngagaduhan dampak anu paling parah dina jitter sareng latency. Kalayan ratusan prosés anu nanganan sambungan TCP, kami kapaksa terus-terusan ngalih antara aranjeunna, sareng dina skala microsecond ieu mangrupikeun operasi anu nyéépkeun waktos. Tapi bagian awon éta nalika prosés narima pakét pikeun ngolah, dikirim ka hiji antrian SystemV lajeng ngantosan hiji acara ti antrian SystemV sejen. Sanajan kitu, lamun aya angka nu gede ngarupakeun titik, datangna pakét TCP anyar dina hiji prosés jeung resi data dina antrian di sejen ngagambarkeun dua acara competing pikeun OS. Dina hal ieu, lamun euweuh prosesor fisik sadia pikeun duanana tugas, hiji bakal diolah, sarta kadua bakal ditempatkeun dina antrian ngantosan. Teu mungkin keur prediksi balukarna.
Dina kaayaan sapertos kitu, kontrol prioritas prosés dinamis tiasa dianggo, tapi ieu bakal meryogikeun panggunaan telepon sistem anu intensif sumberdaya. Hasilna, urang switched ka hiji thread maké epoll Palasik, ieu greatly ngaronjat laju jeung ngurangan waktu processing urus. Kami ogé ngaleungitkeun prosés komunikasi sareng komunikasi jaringan anu misah ngaliwatan SystemV, sacara signifikan ngirangan jumlah telepon sistem sareng mimiti ngadalikeun prioritas operasi. Dina subsistem I / O nyalira, éta mungkin ngahemat ngeunaan 8-17 microseconds, gumantung kana skenario. Skéma single-threaded ieu geus dipaké unchanged saprak lajeng; hiji thread epoll kalawan margin cukup pikeun layanan sadaya sambungan.
Ngolah Transaksi
Beban tumuwuh dina sistem kami diperlukeun ningkatkeun ampir sakabéh komponén na. Tapi, hanjakalna, stagnation dina tumuwuhna speeds jam processor dina taun panganyarna geus euweuh ngamungkinkeun pikeun skala prosés sirah-on. Ku alatan éta, urang mutuskeun pikeun ngabagi prosés Mesin kana tilu tingkatan, anu pangsibukna nyaéta sistem pamariksaan résiko, anu ngaevaluasi kasadiaan dana dina rekening sareng nyiptakeun transaksi sorangan. Tapi duit bisa jadi dina currencies béda, sarta ieu diperlukeun pikeun angka kaluar dina dasar naon ngolah requests kudu dibagi.
Solusi logis nyaéta ngabagi ku mata uang: hiji server dagang dina dolar, anu sanés dina pon, sareng sapertilu dina euro. Tapi upami, kalayan skéma sapertos kitu, dua transaksi dikirim kanggo mésér mata uang anu béda, maka masalah desynchronization dompét bakal timbul. Tapi singkronisasi sesah sareng mahal. Ku alatan éta, bakal bener mun beling misah ku dompét jeung misah ku instrumen. Ku jalan kitu, paling bursa Western teu boga tugas mariksa resiko sakumaha acutely sakumaha urang ngalakukeun, jadi paling sering ieu dipigawé offline. Urang kedah ngalaksanakeun verifikasi online.
Hayu urang ngajelaskeun ku conto. Saurang padagang hoyong mésér $ 30, sareng pamenta nuju ka validasi urus: urang pariksa naha padagang ieu diidinan pikeun modeu dagang ieu sareng naha anjeunna ngagaduhan hak anu diperyogikeun. Lamun sagalana aya dina urutan, pamundut mana anu ka sistem verifikasi resiko, i.e. pikeun mariksa kacukupan dana pikeun nyimpulkeun transaksi. Aya catetan anu jumlah diperlukeun ayeuna diblokir. Pamundut ieu lajeng diteruskeun ka sistem dagang, nu approves atanapi disapproves urus. Hayu urang nyebutkeun urus geus disatujuan - lajeng sistem verifikasi résiko nandaan yén duit geus unblocked, sarta rubles robah jadi dollar.
Sacara umum, sistem pamariksaan résiko ngandung algoritma anu rumit sareng ngalaksanakeun jumlah itungan anu intensif sumberdaya, sareng henteu ngan saukur mariksa "kasaimbangan akun", sabab sigana sigana di glance kahiji.
Nalika urang mimiti ngabagi prosés Mesin kana tingkat, urang mendakan masalah: kode anu sayogi dina waktos éta aktip ngagunakeun data anu sami dina tahap validasi sareng verifikasi, anu peryogi nyerat ulang sadayana dasar kode. Hasilna, kami nginjeum téknik pikeun ngolah paréntah tina prosesor modern: masing-masing dibagi kana tahap-tahap leutik sareng sababaraha tindakan dilaksanakeun paralel dina hiji siklus.
Saatos adaptasi leutik kode, urang nyiptakeun pipa pikeun ngolah transaksi paralel, dimana transaksi dibagi kana 4 tahapan pipa: interaksi jaringan, validasi, palaksanaan sareng publikasi hasilna.
Hayu urang nempo hiji conto. Simkuring gaduh dua sistem processing, serial na paralel. Transaksi munggaran sumping sareng dikirim pikeun validasi dina duanana sistem. Transaksi kadua langsung sumping: dina sistem paralel langsung dicandak ka tempat damel, sareng dina sistem sekuensial disimpen dina antrian ngantosan transaksi munggaran ngalangkungan tahap ngolah ayeuna. Hartina, kauntungan utama ngolah pipa nyaéta urang ngolah antrian transaksi langkung gancang.
Ieu kumaha urang sumping sareng sistem ASTS +.
Leres, henteu sadayana lancar sareng conveyor ogé. Anggap urang gaduh transaksi anu mangaruhan susunan data dina transaksi tatangga; ieu mangrupikeun kaayaan umum pikeun bursa. Transaksi sapertos kitu henteu tiasa dilaksanakeun dina pipa sabab tiasa mangaruhan batur. Kaayaan ieu disebut bahya data, sareng transaksi sapertos kitu diolah nyalira: nalika transaksi "gancang" dina antrian béak, pipa eureun, sistem ngolah transaksi "laun", teras ngamimitian pipa deui. Untungna, proporsi transaksi misalna dina aliran sakabéh pisan leutik, jadi pipa eureun jadi jarang nu teu mangaruhan kinerja sakabéh.
Teras we mimiti ngajawab masalah nyingkronkeun tilu threads palaksanaan. Hasilna nyaéta sistem dumasar kana panyangga cingcin sareng sél ukuran tetep. Dina sistem ieu, sagalana tunduk kana speed processing; data teu disalin.
- Sadaya pakét jaringan anu asup asup kana tahap alokasi.
- Urang nempatkeun aranjeunna dina Asép Sunandar Sunarya tur cirian aranjeunna sadia pikeun tahap #1.
- Transaksi kadua parantos sumping, éta sayogi deui pikeun tahap No.
- Utas pamrosésan anu munggaran ningali transaksi anu sayogi, ngolahna, sareng ngalihkeunana kana tahap salajengna tina benang ngolah kadua.
- Lajeng ngolah transaksi munggaran tur bandéra sél pakait
deleted- ayeuna tos sayogi kanggo dianggo énggal.
Sakabéh antrian diolah ku cara ieu.
Ngolah unggal tahapan nyandak unit atanapi puluhan microseconds. Sareng upami urang nganggo skéma sinkronisasi OS standar, maka urang bakal kaleungitan langkung waktos dina sinkronisasi sorangan. Éta sababna urang mimiti nganggo spinlock. Sanajan kitu, ieu téh formulir pisan goréng dina sistem real-time, sarta RedHat mastikeun teu nyarankeun ngalakukeun ieu, sangkan nerapkeun spinlock pikeun 100 mdet, lajeng pindah ka modeu semaphore pikeun ngaleungitkeun kamungkinan deadlock a.
Hasilna, urang ngahontal kinerja ngeunaan 8 juta transaksi per detik. Sareng sacara harfiah dua bulan saatosna ngeunaan LMAX Disruptor kami nempo pedaran sirkuit jeung pungsi sarua.
Ayeuna tiasa aya sababaraha utas palaksanaan dina hiji tahap. Sadaya transaksi diolah hiji-hiji, dina urutan anu ditampi. Hasilna, kinerja puncak ngaronjat tina 18 rébu ka 50 rébu transaksi per detik.
Sistem manajemén résiko bursa
Teu aya watesna pikeun kasampurnaan, sareng teu lami urang mimiti modernisasi deui: dina kerangka ASTS +, urang mimiti mindahkeun manajemén résiko sareng sistem operasi pakampungan kana komponén otonom. Kami ngembangkeun arsitéktur modern anu fleksibel sareng modél résiko hirarkis énggal, sareng nyobian nganggo kelas dimana waé fixed_point tibatan double.
Tapi masalah langsung timbul: kumaha nyingkronkeun sadaya logika bisnis anu parantos dianggo mangtaun-taun sareng mindahkeun kana sistem énggal? Hasilna, versi mimiti prototipe tina sistem anyar kapaksa ditinggalkeun. Versi kadua, anu ayeuna damel di produksi, dumasar kana kode anu sami, anu dianggo dina bagian dagang sareng résiko. Salila pangwangunan, hal anu paling hese dilakukeun nyaéta git merge antara dua vérsi. Babaturan urang Evgeniy Mazurenok ngalaksanakeun operasi ieu unggal minggu sareng unggal waktos anjeunna dilaknat pikeun waktos anu lami pisan.
Nalika milih sistem anyar, urang langsung kedah ngajawab masalah interaksi. Lamun milih beus data, ieu diperlukeun pikeun mastikeun jitter stabil sarta latency minimal. Jaringan InfiniBand RDMA paling cocog pikeun ieu: waktos ngolah rata-rata 4 kali langkung handap tina jaringan 10 G Ethernet. Tapi anu leres-leres narik kami nyaéta bédana persentil - 99 sareng 99,9.
Tangtosna, InfiniBand gaduh tantangan na. Firstly, a API béda - ibverbs tinimbang sockets. Kadua, ampir teu aya solusi olahtalatah open source anu lega. Kami nyobian ngadamel prototipe sorangan, tapi tétéla hésé pisan, janten kami milih solusi komérsial - Confinity Low Latency Messaging (baheulana IBM MQ LLM).
Teras tugas ngabagi sistem résiko anu leres timbul. Upami anjeun ngan saukur nyabut Mesin Risk sareng henteu nyiptakeun titik perantara, maka transaksi tina dua sumber tiasa dicampur.
Anu disebut solusi Ultra Low Latency gaduh mode nyusun ulang: transaksi tina dua sumber tiasa diatur dina urutan anu diperyogikeun nalika nampi; ieu dilaksanakeun nganggo saluran anu misah pikeun tukeur inpormasi ngeunaan pesenan. Tapi kami henteu acan nganggo mode ieu: éta nyusahkeun sadayana prosés, sareng dina sababaraha solusi henteu dirojong pisan. Salaku tambahan, unggal transaksi kedah ditugaskeun cap waktu anu saluyu, sareng dina skéma kami mékanisme ieu hésé pisan dilaksanakeun kalayan leres. Kituna, urang ngagunakeun skéma Palasik kalawan calo pesen, nyaeta, kalawan dispatcher nu distributes pesen antara Risk Engine.
Masalah kadua ieu patali jeung aksés klien: lamun aya sababaraha Risk Gateways, klien kudu nyambung ka unggal sahijina, sarta ieu bakal merlukeun parobahan lapisan klien. Kami hoyong ngajauhan ieu dina tahap ieu, ku kituna desain Risk Gateway ayeuna ngolah sadaya aliran data. Ieu greatly ngawatesan throughput maksimum, tapi greatly simplifies integrasi sistem.
Duplikasi
Sistim urang teu kudu boga hiji titik gagal, nyaeta, sakabeh komponen kudu duplikat, kaasup calo pesen. Urang direngsekeun masalah ieu ngagunakeun sistem CLLM: ngandung hiji klaster RCMS nu dua dispatchers tiasa dianggo dina modeu master-budak, sarta lamun salah sahiji gagal, sistem otomatis pindah ka séjén.
Gawe sareng pusat data cadangan
InfiniBand dioptimalkeun pikeun operasi salaku jaringan lokal, nyaeta, pikeun nyambungkeun alat rak-Gunung, sarta jaringan InfiniBand teu bisa diteundeun antara dua puseur data sebaran géografis. Kituna, urang dilaksanakeun sasak / dispatcher, nu nyambung ka gudang pesen via jaringan Ethernet biasa na relays sadayana transaksi ka jaringan IB kadua. Nalika urang kedah migrasi ti pusat data, urang tiasa milih pusat data mana pikeun dianggo ayeuna.
hasil
Sadayana di luhur henteu dilakukeun sakaligus; butuh sababaraha iterasi pikeun ngembangkeun arsitéktur énggal. Kami nyiptakeun prototipe dina sabulan, tapi peryogi langkung ti dua taun kanggo ngagentos kana kaayaan kerja. Kami nyobian ngahontal kompromi pangsaéna antara ningkatkeun waktos pamrosésan transaksi sareng ningkatkeun réliabilitas sistem.
Kusabab sistemna parantos diropéa pisan, kami ngalaksanakeun pamulihan data tina dua sumber anu mandiri. Upami toko pesen henteu jalanna leres kusabab sababaraha alesan, anjeun tiasa nyandak log transaksi tina sumber kadua - tina Mesin Risk. Prinsip ieu dititénan sapanjang sistem.
Diantara hal séjén, kami bisa ngawétkeun API klien ku kituna teu calo atanapi saha wae merlukeun rework signifikan pikeun arsitektur anyar. Urang kungsi ngarobah sababaraha interfaces, tapi aya teu kudu nyieun parobahan signifikan kana model operasi.
Kami nyauran versi ayeuna tina platform kami Rebus - salaku singketan pikeun dua inovasi anu paling katingali dina arsitéktur, Risk Engine sareng BUS.
Dina awalna, urang hayang allocate ngan bagian clearing, tapi hasilna mangrupa sistem disebarkeun badag. Klién ayeuna tiasa berinteraksi sareng Trade Gateway, Clearing Gateway, atanapi duanana.
Anu kami tungtungna ngahontal:
Ngurangan tingkat latency. Kalayan volume leutik transaksi, sistem jalanna sami sareng versi sateuacana, tapi dina waktos anu sami tiasa tahan beban anu langkung ageung.
Kinerja puncak ningkat tina 50 rébu ka 180 rébu transaksi per detik. Paningkatan salajengna dihambat ku hiji-hijina aliran pesenan anu cocog.
Aya dua cara pikeun perbaikan salajengna: parallelizing cocog jeung ngarobah cara gawéna kalayan Gateway. Ayeuna sadaya Gateways beroperasi dumasar kana skéma réplikasi, anu, dina beban sapertos kitu, teu tiasa dianggo sacara normal.
Tungtungna, abdi tiasa masihan sababaraha saran ka jalma anu finalizing sistem perusahaan:
- Janten disiapkeun pikeun awon sepanjang waktos. Masalah sok timbul teu disangka-sangka.
- Ieu biasana teu mungkin mun gancang nyieun deui arsitéktur. Utamana upami anjeun kedah ngahontal réliabilitas maksimal dina sababaraha indikator. Langkung seueur titik, langkung seueur sumber daya anu diperyogikeun pikeun ngadukung.
- Sadaya solusi adat sareng proprietary ngabutuhkeun sumber daya tambahan pikeun panalungtikan, dukungan sareng pangropéa.
- Entong ngabéréskeun masalah réliabilitas sistem sareng pamulihan saatos gagal; pertimbangkeun dina tahap desain awal.
sumber: www.habr.com