Naha korporasi sapertos MegaFon peryogi Tarantool dina tagihan? Ti luar sigana nu ngajual biasana datang, brings sababaraha jenis kotak badag, plugs colokan kana stop kontak nu - sarta éta tagihan! Ieu sakali kasus, tapi ayeuna geus kolot, sarta dinosaurus misalna geus punah atawa geus punah. Mimitina, tagihan mangrupikeun sistem pikeun ngaluarkeun invoice - mesin cacah atanapi kalkulator. Dina telekomunikasi modern ieu sistem automation pikeun sakabéh siklus kahirupan interaksi jeung palanggan ti kacindekan tina kontrak nepi ka terminasi, kaasup tagihan real-time, ditampa pamayaran sareng seueur deui. Tagihan di perusahaan telekomunikasi sapertos robot tempur - ageung, kuat sareng pinuh ku senjata.
Naon hubunganana Tarantool sareng éta? Aranjeunna bakal ngobrol ngeunaan éta Oleg Ivlev и Andrey Knyazev. Oleg teh lulugu arsiték pausahaan kalawan pangalaman éksténsif digawé di pausahaan asing, Andrey diréktur sistem bisnis. Tina transkrip laporan maranéhanana dina anjeun bakal diajar naha R&D diperlukeun dina korporasi, naon Tarantool, kumaha impasse tina skala vertikal jeung globalisasi jadi prerequisites pikeun penampilan database ieu di pausahaan, ngeunaan tantangan téhnologis, transformasi arsitéktur, jeung kumaha technostack MegaFon sarua jeung Netflix. , Google jeung Amazon.
Proyék "Tagihan Ngahijikeun Tagihan"
Proyék anu dimaksud disebut "Tagihan Ngahijikeun". Ieu di dieu yén Tarantool némbongkeun kualitas pangalusna na.
Tumuwuhna produktivitas alat Hi-End henteu saluyu sareng kamekaran dasar palanggan sareng paningkatan jumlah jasa; pertumbuhan salajengna dina jumlah palanggan sareng jasa diperkirakeun kusabab M2M, IoT, sareng fitur cabang anu dipimpin. ka deterioration dina time-to-pasar. Pausahaan mutuskeun pikeun nyieun sistem bisnis ngahiji jeung arsitéktur modular kelas dunya unik, tinimbang 8 sistem tagihan béda ayeuna.
MegaFon mangrupikeun dalapan perusahaan dina hiji. Dina 2009, reorganisasi ieu réngsé: cabang sakuliah Rusia dihijikeun kana hiji parusahaan, MegaFon OJSC (ayeuna PJSC). Ku kituna, parusahaan boga 8 sistem tagihan kalawan solusi "adat" sorangan, fitur cabang jeung struktur organisasi béda, IT jeung pamasaran.
Sagalana henteu kunanaon dugi ka urang kedah ngaluncurkeun hiji produk féderal umum. Di dieu loba kasusah timbul: pikeun sababaraha tariffs rounded up, keur batur rounded handap, sarta batur - dumasar kana mean arithmetic. Aya rébuan moments sapertos.
Najan kanyataan yén aya ngan hiji versi sistem tagihan, hiji supplier, setélan diverged pisan nu butuh waktu lila pikeun nunda babarengan. Urang diusahakeun ngurangan jumlah maranéhanana, sarta datang di sakuliah masalah kadua anu akrab jeung loba korporasi.
Skala nangtung. Malahan hardware anu paling keren dina waktos éta henteu nyumponan kabutuhan. Kami nganggo alat Hewlett-Packard tina garis Superdome Hi-End, tapi henteu nyumponan kabutuhan bahkan dua cabang. Abdi hoyong skala horizontal tanpa biaya operasi ageung sareng investasi modal.
Harepan kanaékan jumlah palanggan sareng jasa. Konsultan parantos lami nyangking carita ngeunaan IoT sareng M2M ka dunya telekomunikasi: waktosna bakal sumping nalika unggal telepon sareng beusi gaduh kartu SIM, sareng dua dina kulkas. Dinten ieu kami gaduh hiji sajumlah palanggan, tapi dina mangsa nu bakal datang bakal aya loba deui.
tantangan téhnologis
Opat alesan ieu ngamotivasi urang pikeun nyieun parobahan serius. Aya pilihan antara ningkatkeun sistem sareng ngarancang ti mimiti. Urang mikir pikeun lila, nyieun kaputusan serius, maén tenders. Hasilna, urang mutuskeun mendesain ti pisan awal, sarta nyandak kana tantangan metot - tantangan téhnologis.
Skalabilitas
Lamun éta saméméh, hayu urang nyebutkeun, hayu urang nyebutkeun 8 tagihan pikeun 15 juta palanggan, tur ayeuna kudu digawé 100 juta palanggan sareng seueur deui - beban mangrupa urutan gedena luhur.
Kami geus jadi comparable dina skala pikeun pamaén Internet badag kawas Mail.ru atawa Netflix.
Tapi gerakan salajengna pikeun ningkatkeun beban sareng dasar palanggan parantos netepkeun tantangan anu serius pikeun urang.
Géografi nagara urang lega
Antara Kaliningrad jeung Vladivostok 7500 km sareng 10 zona waktos. Laju cahayana terbatas sareng dina jarak sapertos kitu telatna parantos signifikan. 150 mdet dina saluran optik modern coolest teuing pikeun tagihan real-time, utamana sabab ayeuna di telekomunikasi di Rusia. Salaku tambahan, anjeun kedah ngapdet dina hiji dinten bisnis, sareng kalayan zona waktos anu béda ieu mangrupikeun masalah.
Kami henteu ngan ukur nyayogikeun jasa pikeun biaya langganan, kami gaduh tarif kompleks, bungkusan, sareng sagala rupa modifier. Urang kedah henteu ngan ukur ngawenangkeun atanapi nampik palanggan ngobrol, tapi masihan anjeunna kuota anu tangtu - ngitung telepon sareng tindakan sacara real waktos supados anjeunna henteu perhatikeun.
toleransi kasalahan
Ieu sisi séjén sentralisasi.
Upami urang ngumpulkeun sadaya palanggan dina hiji sistem, maka naon waé kajadian darurat sareng bencana mangrupikeun musibah pikeun bisnis. Ku alatan éta, urang mendesain sistem ku cara pikeun ngaleungitkeun dampak kacilakaan dina sakabéh basa palanggan.
Ieu deui konsékuansi tina panolakan skala vertikal. Nalika urang diskalakeun sacara horisontal, kami ningkatkeun jumlah server tina ratusan dugi ka rébuan. Éta kedah diurus sareng ditukeurkeun, otomatis nyadangkeun infrastruktur IT sareng malikkeun sistem anu disebarkeun.
Kami nyanghareupan tantangan anu pikaresepeun sapertos kitu. Kami ngararancang sistem éta, sareng dina waktos éta kami nyobian milarian prakték pangsaéna global pikeun mariksa kumaha tren kami, sabaraha urang nuturkeun téknologi canggih.
Pangalaman dunya
Ahéng, kami henteu mendakan rujukan tunggal dina telekomunikasi global.
Éropa geus fallen jauh dina watesan jumlah palanggan jeung skala, AS - dina watesan flatness tina tariffs na. Urang nempo sababaraha di Cina, sarta kapanggih sababaraha di India jeung hired spesialis ti Vodafone India.
Pikeun nganalisis arsitéktur, kami ngarakit Tim Impian anu dipimpin ku IBM - arsiték tina widang anu béda. Jalma-jalma ieu cekap tiasa meunteun naon anu urang lakukeun sareng nyangking pangaweruh anu tangtu kana arsitéktur urang.
Skala
Sababaraha angka pikeun ilustrasi.
Urang ngarancang sistem pikeun 80 juta palanggan sareng cadangan samilyar. Ieu kumaha urang nyabut ambang hareup. Ieu sanés kusabab urang badé ngarebut China, tapi kusabab serangan IoT sareng M2M.
300 juta dokumén diolah sacara real waktos. Sanaos urang gaduh 80 juta palanggan, kami damel sareng klien poténsial sareng anu parantos ninggalkeun kami upami urang kedah ngumpulkeun piutang. Ku alatan éta, volume sabenerna noticeably leuwih badag.
2 milyar transaksi Kasaimbangan robih unggal dinten - ieu mangrupikeun pamayaran, biaya, telepon sareng acara anu sanés. 200 TB data aktip ngarobah, robah saeutik laun 8 PB data, sareng ieu sanés arsip, tapi data langsung dina tagihan tunggal. Skala dumasar pusat data - 5 sarébu server dina 14 situs.
Téknologi tumpukan
Nalika kami ngarencanakeun arsitéktur sareng mimiti ngumpul sistem, kami ngimpor téknologi anu paling pikaresepeun sareng canggih. Hasilna nyaéta tumpukan téknologi anu akrab pikeun pamaén Internét sareng perusahaan anu ngadamel sistem beban tinggi.
Tumpukanna sami sareng tumpukan pamaén utama anu sanés: Netflix, Twitter, Viber. Ieu diwangun ku 6 komponén, tapi urang hoyong pondok tur ngahijikeun eta.
Kalenturan saé, tapi dina korporasi ageung teu aya jalan tanpa ngahijikeun.
Kami moal ngarobih Oracle anu sami sareng Tarantool. Dina realitas perusahaan ageung, ieu mangrupikeun utopia, atanapi perang salib salami 5-10 taun kalayan hasil anu teu jelas. Tapi Cassandra sareng Couchbase tiasa digentos ku Tarantool, sareng éta anu urang narékahan.
Naha Tarantool?
Aya 4 kriteria basajan naha urang milih database ieu.
kagancangan. Kami ngalaksanakeun tés beban dina sistem industri MegaFon. Tarantool meunang - éta nunjukkeun prestasi anu pangsaéna.
Ieu sanés hartosna yén sistem sanés henteu nyumponan kabutuhan MegaFon. Solusi mémori ayeuna janten produktif sahingga cadangan perusahaan langkung ti cukup. Tapi urang kabetot dina kaayaan pamimpin, teu jeung batur anu katinggaleun balik, kaasup dina test beban.
Tarantool nyertakeun kabutuhan perusahaan bahkan dina jangka panjang.
biaya TCO. Rojongan pikeun Couchbase on MegaFon jilid waragad jumlahna astronomi duit, tapi kalawan Tarantool kaayaan téh leuwih pikaresepeun, sarta sipatna sarupa dina fungsionalitas.
Fitur anu sanés anu rada dipangaruhan ku pilihan urang nyaéta Tarantool tiasa dianggo langkung saé kalayan mémori tibatan pangkalan data sanés. Anjeunna nembongkeun efisiensi maksimum.
réliabilitas. MegaFon investasi di reliabiliti, meureun leuwih ti saha wae. Janten nalika urang ningal Tarantool, urang sadar yén urang kedah nyumponan sarat urang.
Kami investasi waktos sareng kauangan, sareng sareng Mail.ru kami nyiptakeun versi perusahaan, anu ayeuna dianggo di sababaraha perusahaan sanés.
Tarantool-perusahaan lengkep wareg kami dina hal kaamanan, reliabilitas, sareng logging.
Mitra
Anu paling penting pikeun kuring nyaéta kontak langsung jeung pamekar. Ieu persis naon nu guys ti Tarantool disogok kalawan.
Lamun datang ka pamaén, utamana hiji anu gawéna kalayan klien jangkar, sarta nyebutkeun yén anjeun peryogi database pikeun bisa ngalakukeun ieu, ieu sareng ieu, anjeunna biasana ngajawab:
- Oké, nempatkeun sarat di handap tumpukan éta - someday, urang meureun bakal meunang ka aranjeunna.
Loba boga roadmap pikeun salajengna 2-3 taun, sarta ampir teu mungkin keur ngahijikeun aya, tapi pamekar Tarantool captivate kalawan openness maranéhna, teu ngan ti MegaFon, sarta adaptasi sistem maranéhna pikeun nasabah. Éta saé sareng urang resep pisan.
Dimana kami nganggo Tarantool
Kami nganggo Tarantool dina sababaraha elemen. Anu kahiji aya dina pilot, nu urang dijieun dina sistem diréktori alamat. Dina hiji waktos abdi hoyong janten sistem anu sami sareng Yandex.Maps sareng Google Maps, tapi tétéla rada béda.
Contona, katalog alamat dina panganteur jualan. Dina Oracle, milarian alamat anu dipikahoyong butuh 12-13 detik. - angka uncomfortable. Nalika urang pindah ka Tarantool, ngaganti Oracle kalawan database sejen dina konsol nu, sarta nedunan pilarian sarua, urang meunang speedup 200x! Kota pop up sanggeus hurup katilu. Ayeuna urang adaptasi antarmuka supados ieu kajantenan saatos anu munggaran. Sanajan kitu, laju respon sagemblengna béda - milliseconds tinimbang detik.
Aplikasi kadua nyaéta téma trendi disebut IT dua-speed. Ieu kusabab konsultan ti unggal sudut nyebutkeun yen korporasi kudu indit ka dinya.
Aya lapisan infrastruktur, di luhurna aya domain, contona, sistem tagihan sapertos telekomunikasi, sistem perusahaan, pelaporan perusahaan. Ieu inti anu henteu kedah dirampa. Éta, tangtosna, mungkin, tapi paranoidly mastikeun kualitas, sabab brings duit korporasi.
Salajengna asalna lapisan microservices - naon differentiates operator atawa pamuter séjén. Microservices bisa gancang dijieun dumasar kana caches tangtu, bringing data ti domain béda dinya. Ieuh widang pikeun percobaan - upami aya anu henteu hasil, kuring nutup hiji microservice sareng muka anu sanés. Ieu nyayogikeun waktos-ka-pasar anu leres-leres sareng ningkatkeun réliabilitas sareng kagancangan perusahaan.
Microservices meureun peran utama Tarantool di MegaFon.
Dimana urang rencanana ngagunakeun Tarantool
Upami urang ngabandingkeun proyék tagihan anu suksés sareng program transformasi di Deutsche Telekom, Svyazcom, Vodafone India, éta heran dinamis sareng kreatif. Dina prosés palaksanaan proyék ieu, teu ngan MegaFon jeung struktur na anu robah, tapi ogé Tarantool-perusahaan mucunghul di Mail.ru, sarta Nexign ngajual urang (baheulana Peter-Service) - BSS Box (solusi tagihan boxed).
Ieu, dina rasa, proyék bersejarah pikeun pasar Rusia. Ieu bisa dibandingkeun naon digambarkeun dina buku "The Mythical Man-Bulan" ku Frederick Brooks. Lajeng, dina 60s, IBM hired 360 urang pikeun ngembangkeun OS / 5 sistem operasi anyar pikeun mainframes. Urang gaduh kirang - 000, tapi milik urang aya dina kutang, sarta nyokot kana akun pamakéan open source sarta pendekatan anyar, urang dianggo leuwih produktif.
Di handap ieu mangrupakeun domain tina tagihan atawa, leuwih lega diomongkeun, sistem bisnis. Jalma ti perusahaan terang pisan CRM. Sadayana kedah gaduh sistem anu sanés: Open API, API Gateway.
Buka API
Hayu urang tingali deui nomer sareng kumaha Open API ayeuna jalanna. Saratna nyaéta 10 transaksi per detik. Kusabab urang rencanana aktip ngamekarkeun lapisan microservices sarta ngawangun MegaFon API publik, urang ngaharepkeun tumuwuhna gede di mangsa nu bakal datang dina bagian ieu. Pasti bakal aya 100 transaksi.
Kuring henteu terang upami urang tiasa ngabandingkeun sareng Mail.ru di SSO - lalaki sigana gaduh 1 transaksi per detik. Solusina pisan pikaresepeun pikeun kami sareng kami ngarencanakeun pikeun ngadopsi pangalamanana - contona, ngadamel cadangan SSO fungsional nganggo Tarantool. Ayeuna pamekar ti Mail.ru ngalakukeun ieu pikeun urang.
CRM
CRM sami sareng 80 juta palanggan anu urang badé ningkat kana samilyar, sabab parantos aya 300 juta dokumén anu kalebet sajarah tilu taun. Kami bener-bener ngarepkeun jasa anyar sareng di dieu titik tumuwuh nyaéta jasa disambungkeun. Ieu bal anu bakal tumuwuh, sabab bakal aya beuki loba jasa. Sasuai, urang peryogi carita; urang henteu hoyong titajong kana ieu.
Tagihan sorangan dina hal ngaluarkeun invoices, gawé bareng rekening customer receivable robah jadi domain misah. Pikeun ngaronjatkeun kinerja, pola arsitéktur domain dilarapkeun.
Sistem dibagi kana domain, beban disebarkeun sareng kasabaran sesar dipastikeun. Salaku tambahan, urang damel sareng arsitéktur anu disebarkeun.
Sagalana sejenna nyaeta solusi tingkat perusahaan. Dina panyimpenan telepon - 2 milyar per poé, 60 milyar pér bulan. Kadang-kadang anjeun kedah ngitung aranjeunna dina sabulan, sareng éta langkung saé gancang. Ngawaskeun kauangan - ieu persis sarua 300 juta nu terus tumuwuh sarta tumuwuh: palanggan mindeng ngajalankeun antara operator, ngaronjatkeun bagian ieu.
Komponén telekomunikasi paling komunikasi mobile nyaéta tagihan online. Ieu mangrupikeun sistem anu ngamungkinkeun anjeun nyauran atanapi henteu nelepon, nyandak kaputusan sacara real waktos. Di dieu bebanna nyaéta 30 transaksi per detik, tapi kalayan tumut kana kamekaran transfer data, kami ngarencanakeun 250 transaksi, sarta ku kituna kami pisan museurkeun Tarantool.
Gambar saméméhna nyaéta domain dimana urang badé nganggo Tarantool. CRM sorangan, tangtosna, langkung lega sareng urang badé nganggo éta dina inti sorangan.
Angka TTX perkiraan kami tina 100 juta palanggan ngabingungkeun kuring salaku arsiték - kumaha upami 101 juta? Naha anjeun kedah ngulang sadayana deui? Pikeun nyegah ieu kajadian, kami nganggo cache, dina waktos anu sami ningkatkeun aksés.
Sacara umum, aya dua pendekatan pikeun ngagunakeun Tarantool. kahiji- ngawangun sadaya cache dina tingkat microservice. Sajauh kuring ngartos, VimpelCom nuturkeun jalur ieu, nyiptakeun cache klien.
Kami kirang gumantung kana padagang, kami ngarobih inti BSS, janten kami gaduh file klien tunggal tina kotak. Tapi urang rék dilegakeun eta. Ku alatan éta, urang nyandak pendekatan anu rada béda - nyieun caches jero sistem.
Ku cara kieu aya kirang sinkronisasi - hiji sistem jawab duanana cache sarta sumber master utama.
Metoda fits ogé kalawan pendekatan Tarantool kalawan rorongkong transactional, lamun ukur bagian anu patali jeung apdet, nyaeta, parobahan data, diropéa. Sagalana sejenna bisa disimpen di tempat sejenna. Teu aya danau data anu ageung, cache global anu teu diurus. Caches dirancang pikeun sistem, atawa pikeun produk, atawa pikeun klien, atawa sangkan hirup leuwih gampang pikeun pangropéa. Nalika palanggan nelepon sareng kesel ngeunaan kualitas palayanan anjeun, anjeun badé nyayogikeun jasa anu berkualitas.
RTO sareng RPO
Aya dua istilah dina IT - OTR и RPO.
Tujuan waktos recovery nyaéta waktu nu diperlukeun pikeun mulangkeun jasa sanggeus gagal. RTO = 0 hartina sanajan hal gagal, jasa terus jalan.
Tujuan titik recovery - Ieu mangrupikeun waktos pamulihan data, sabaraha data anu urang tiasa leungit dina sababaraha waktos. RPO = 0 hartina urang teu kaleungitan data.
Tugas Tarantool
Hayu urang cobaan pikeun ngajawab masalah pikeun Tarantool.
Dipasihan: karinjang aplikasi nu everyone understands, contona, dina Amazon atawa tempat sejenna. diperlukeun supados karanjang balanja tiasa dianggo 24 jam 7 dinten saminggu, atanapi 99,99% waktos. Pesenan anu sumping ka kami kedah tetep teratur, sabab kami henteu tiasa sacara acak ngaktipkeun atanapi mareuman sambungan palanggan - sadayana kedah konsisten. Langganan saméméhna mangaruhan anu salajengna, janten data penting - teu aya anu leungit.
kaputusan. Anjeun tiasa nyobian ngabéréskeun éta langsung sareng naroskeun ka pamekar database, tapi masalahna henteu tiasa direngsekeun sacara matematis. Anjeun tiasa apal téoréma, hukum konservasi, fisika kuantum, tapi naha - teu bisa direngsekeun dina tingkat DB.
Pendekatan arsitéktur kuno anu saé dianggo di dieu - anjeun kedah terang daérah subjek sareng dianggo pikeun ngajawab teka-teki ieu.
Solusi kami: nyiptakeun pendaptaran aplikasi anu disebarkeun dina Tarantool - klaster anu disebarkeun geo. Dina diagram, ieu tilu puseur ngolah data béda - dua saméméh Urals, hiji saluareun Urals, sarta kami ngadistribusikaeun sagala requests diantara puseur ieu.
Netflix, anu ayeuna dianggap salah sahiji pamimpin IT, ngan ukur gaduh hiji pusat data dugi ka 2012. Dina wengi Natal Katolik, 24 Désémber, pusat data ieu turun. Pamaké di Kanada sareng Amérika Serikat ditinggalkeun tanpa pilem karesepna, kesel pisan sareng nyerat ngeunaan éta dina jaringan sosial. Netflix ayeuna gaduh tilu pusat data di basisir kulon-wétan sareng hiji di Éropa kulon.
Kami mimitina ngawangun solusi anu disebarkeun geo - kasabaran kasalahan penting pikeun kami.
Janten urang gaduh klaster, tapi kumaha upami RPO = 0 sareng RTO = 0? Solusina basajan, gumantung kana subjekna.
Naon anu penting dina aplikasi? Dua Bagian: Karanjang Ngalungkeun ka nyieun kaputusan beuli, jeung LEPAS. Bagian DO dina telekomunikasi biasana disebut ngarebut pesenan atawa rundingan pesenan. Dina telekomunikasi, ieu tiasa langkung hese tibatan di toko online, sabab aya klien kedah dilayanan, ditawarkeun 5 pilihan, sareng ieu sadayana kajantenan, tapi karinjangna dieusi. Dina momen ieu, hiji kagagalan mungkin, tapi teu pikasieuneun, sabab lumangsung interactively dina pangawasan manusa.
Lamun puseur data Moscow dumadakan gagal, lajeng ku otomatis pindah ka puseur data sejen, urang bakal neruskeun jalan. Téoritis, hiji produk bisa leungit dina karanjang, tapi nu katingali eta, tambahkeun ka karanjang deui jeung neruskeun gawé. Dina hal ieu RTO = 0.
Dina waktos anu sami, aya pilihan kadua: nalika urang ngaklik "kintunkeun", urang hoyong data henteu leungit. Ti moment ieu, automation mimiti jalan - ieu RPO = 0. Ngagunakeun dua pola béda ieu, dina hiji hal eta ngan saukur bisa jadi klaster geo-disebarkeun kalawan hiji master switchable, dina hal séjén sababaraha jenis catetan quorum. Pola bisa rupa-rupa, tapi urang ngajawab masalah.
Salajengna, gaduh pendaptaran aplikasi anu disebarkeun, urang ogé tiasa skala sadayana - gaduh seueur dispatcher sareng pelaksana anu ngaksés pendaptaran ieu.
Cassandra sareng Tarantool babarengan
Aya deui kasus - "pameran kasaimbangan". Ieu mangrupikeun kasus anu pikaresepeun ngeunaan panggunaan gabungan Cassandra sareng Tarantool.
Kami nganggo Cassandra sabab 2 milyar telepon per dinten sanés watesna, sareng bakal aya deui. Pamasar resep ngawarnaan lalu lintas ku sumber; langkung seueur detil muncul dina jaringan sosial, contona. Éta sadayana nambihan carita.
Cassandra ngamungkinkeun anjeun pikeun skala horisontal kana ukuran naon waé.
Kami ngarasa nyaman sareng Cassandra, tapi aya hiji masalah - éta henteu saé maca. Sadayana OK dina rekaman, 30 per detik henteu masalah - masalah maca.
Ku alatan éta, hiji topik kalawan cache némbongan, sarta dina waktos anu sareng urang direngsekeun masalah di handap ieu: aya hiji pasualan tradisional heubeul nalika alat-alat ti switch tina tagihan online asup kana file nu urang beban kana Cassandra. Kami bajoang sareng masalah undeuran file anu dipercaya, bahkan nganggo naséhat transfer file manajer IBM - aya solusi anu ngatur transfer file sacara éfisién, nganggo protokol UDP, contona, tinimbang TCP. Ieu alus, tapi éta kénéh sababaraha menit, sarta kami geus teu dieusian sadayana, operator di puseur panggero teu bisa ngajawab klien naon anu lumangsung dina kasaimbangan - urang kudu antosan.
Pikeun nyegah ieu kajadian, urang kami nganggo cadangan fungsional paralel. Nalika urang ngirim hiji acara via Kafka ka Tarantool, recalculating aggregates sacara real waktu, contona, pikeun kiwari, urang meunang kasaimbangan tunai, anu tiasa nransfer kasaimbangan dina laju naon waé, contona, 100 rébu transaksi per detik sareng anu sami 2 detik.
Tujuanana nyaéta yén saatos nelepon, dina 2 detik dina akun pribadi anjeun moal ngan ukur kasaimbangan anu dirobih, tapi inpormasi ngeunaan naha éta robih.
kacindekan
Ieu mangrupikeun conto ngagunakeun Tarantool. Kami resep pisan kana katerbukaan Mail.ru sareng kahayangna pikeun nganggap kasus anu béda.
Geus hésé pikeun konsultan ti BCG atanapi McKinsey, Accenture atanapi IBM kaget urang ku hal anyar - loba naon maranéhna nawiskeun, urang boh geus ngalakukeun, geus dipigawé, atawa rencana pikeun ngalakukeun. Kuring nyangka yén Tarantool bakal nyandak tempat anu leres dina tumpukan téknologi urang sareng bakal ngagentos seueur téknologi anu tos aya. Kami dina fase aktip ngembangkeun proyék ieu.
Laporan Oleg sareng Andrey mangrupikeun salah sahiji anu pangsaéna dina Konperénsi Tarantool taun ka tukang, sareng dina 17 Juni Oleg Ivlev bakal nyarios di kalawan laporan . Alexander Deulin ogé bakal masihan presentasi ti MegaFon . Hayu urang manggihan naon geus robah, naon rencana geus dilaksanakeun. Miluan - konperénsi éta gratis, anu anjeun kedah laksanakeun nyaéta ... Sadayana jeung program konferensi geus kabentuk: kasus anyar, pangalaman anyar dina ngagunakeun Tarantool, arsitéktur, perusahaan, tutorials na microservices.
sumber: www.habr.com