Mengapakah syarikat seperti MegaFon memerlukan Tarantool dalam pengebilan? Dari luar nampaknya vendor biasanya datang, membawa beberapa jenis kotak besar, palamkan palam ke soket - dan itu adalah pengebilan! Ini pernah berlaku, tetapi kini ia kuno, dan dinosaur seperti itu telah pun pupus atau semakin pupus. Pada mulanya, pengebilan ialah sistem untuk mengeluarkan invois - mesin pengira atau kalkulator. Dalam telekom moden ini sistem automasi untuk keseluruhan kitaran hayat interaksi dengan pelanggan dari penutupan kontrak hingga penamatan, termasuk pengebilan masa nyata, penerimaan pembayaran dan banyak lagi. Pengebilan dalam syarikat telekomunikasi adalah seperti robot tempur - besar, berkuasa dan sarat dengan senjata.
Apakah kaitan Tarantool dengannya? Mereka akan bercakap mengenainya Oleg Ivlev ΠΈ Andrey Knyazev. Oleg ialah ketua arkitek syarikat itu dengan pengalaman luas bekerja di syarikat asing, Andrey ialah pengarah sistem perniagaan. Daripada transkrip laporan mereka pada anda akan belajar mengapa R&D diperlukan dalam syarikat, apa itu Tarantool, bagaimana kebuntuan penskalaan menegak dan globalisasi menjadi prasyarat untuk kemunculan pangkalan data ini dalam syarikat, tentang cabaran teknologi, transformasi seni bina dan bagaimana technostack MegaFon serupa dengan Netflix , Google dan Amazon.
Projek "Pengebilan Bersatu"
Projek yang dimaksudkan dipanggil "Pengebilan Bersatu". Di sinilah Tarantool menunjukkan kualiti terbaiknya.
Pertumbuhan produktiviti peralatan Hi-End tidak sejajar dengan pertumbuhan asas pelanggan dan pertumbuhan bilangan perkhidmatan; pertumbuhan selanjutnya dalam bilangan pelanggan dan perkhidmatan dijangka disebabkan oleh M2M, IoT, dan ciri cawangan yang diterajui. kepada kemerosotan dalam masa ke pasaran. Syarikat itu memutuskan untuk mencipta sistem perniagaan bersatu dengan seni bina modular bertaraf dunia yang unik, bukannya 8 sistem pengebilan berbeza semasa.
MegaFon ialah lapan syarikat dalam satu. Pada tahun 2009, penyusunan semula telah selesai: cawangan di seluruh Rusia bergabung menjadi satu syarikat, MegaFon OJSC (kini PJSC). Oleh itu, syarikat itu mempunyai 8 sistem pengebilan dengan penyelesaian "tersuai" mereka sendiri, ciri cawangan dan struktur organisasi yang berbeza, IT dan pemasaran.
Semuanya baik-baik saja sehingga kami terpaksa melancarkan satu produk persekutuan biasa. Di sini banyak kesukaran timbul: bagi sesetengah orang, tarif dibundarkan ke atas, untuk yang lain dibundarkan ke bawah, dan untuk yang lain - berdasarkan min aritmetik. Terdapat beribu-ribu detik seperti itu.
Walaupun pada hakikatnya terdapat hanya satu versi sistem pengebilan, satu pembekal, tetapan menyimpang begitu banyak sehingga mengambil masa yang lama untuk disatukan. Kami cuba mengurangkan bilangan mereka, dan menemui masalah kedua yang biasa kepada banyak syarikat.
Penskalaan menegak. Malah perkakasan yang paling hebat pada masa itu tidak memenuhi keperluan. Kami menggunakan peralatan Hewlett-Packard daripada barisan Superdome Hi-End, tetapi ia tidak memenuhi keperluan walaupun dua cawangan. Saya mahukan skala mendatar tanpa kos operasi dan pelaburan modal yang besar.
Jangkaan pertumbuhan bilangan pelanggan dan perkhidmatan. Perunding telah lama membawa cerita tentang IoT dan M2M kepada dunia telekomunikasi: masanya akan tiba apabila setiap telefon dan seterika akan mempunyai kad SIM, dan dua di dalam peti sejuk. Hari ini kami mempunyai satu bilangan pelanggan, tetapi dalam masa terdekat akan ada lebih ramai lagi.
Cabaran teknologi
Empat sebab ini mendorong kami untuk membuat perubahan yang serius. Terdapat pilihan antara menaik taraf sistem dan mereka bentuk dari awal. Kami berfikir untuk masa yang lama, membuat keputusan yang serius, bermain tender. Akibatnya, kami memutuskan untuk mereka bentuk dari awal lagi, dan mengambil cabaran yang menarik - cabaran teknologi.
Kebolehskalaan
Jika sebelum ini, katakan, katakan 8 bil untuk 15 juta pelanggan, dan kini ia sepatutnya berjaya 100 juta pelanggan dan banyak lagi - beban adalah susunan magnitud yang lebih tinggi.
Kami telah menjadi setanding dalam skala dengan pemain Internet yang besar seperti Mail.ru atau Netflix.
Tetapi pergerakan selanjutnya untuk meningkatkan beban dan pangkalan pelanggan telah menetapkan cabaran yang serius untuk kami.
Geografi negara kita yang luas
Antara Kaliningrad dan Vladivostok 7500 km dan 10 zon waktu. Kelajuan cahaya adalah terhad dan pada jarak sedemikian kelewatan sudah ketara. 150 ms pada saluran optik moden yang paling hebat adalah terlalu banyak untuk pengebilan masa nyata, terutamanya kerana ia kini dalam telekom di Rusia. Selain itu, anda perlu mengemas kini dalam satu hari perniagaan, dan dengan zon waktu yang berbeza ini menjadi masalah.
Kami bukan sahaja menyediakan perkhidmatan untuk yuran langganan, kami mempunyai tarif, pakej dan pelbagai pengubah suai yang kompleks. Kita perlu bukan sahaja membenarkan atau menafikan pelanggan bercakap, tetapi memberinya kuota tertentu - mengira panggilan dan tindakan dalam masa nyata supaya dia tidak menyedarinya.
toleransi kesalahan
Ini adalah sisi lain pemusatan.
Jika kami mengumpul semua pelanggan dalam satu sistem, maka sebarang peristiwa kecemasan dan bencana adalah bencana untuk perniagaan. Oleh itu, kami mereka bentuk sistem sedemikian rupa untuk menghapuskan kesan kemalangan ke atas keseluruhan pangkalan pelanggan.
Ini sekali lagi akibat daripada keengganan untuk skala menegak. Apabila kami menskala secara mendatar, kami meningkatkan bilangan pelayan daripada ratusan kepada ribuan. Mereka perlu diurus dan boleh ditukar ganti, menyandarkan infrastruktur IT secara automatik dan memulihkan sistem yang diedarkan.
Kami menghadapi cabaran yang begitu menarik. Kami mereka bentuk sistem, dan pada masa itu kami cuba mencari amalan terbaik global untuk menyemak sejauh mana arah aliran kami, sejauh mana kami mengikuti teknologi termaju.
Pengalaman dunia
Anehnya, kami tidak menemui satu pun rujukan dalam telekom global.
Eropah telah jatuh dari segi bilangan pelanggan dan skala, Amerika Syarikat - dari segi kerataan tarifnya. Kami melihat beberapa di China, dan menemui beberapa di India dan mengupah pakar dari Vodafone India.
Untuk menganalisis seni bina, kami mengumpulkan Pasukan Impian yang diketuai oleh IBM - arkitek dari pelbagai bidang. Orang-orang ini boleh menilai dengan secukupnya apa yang kami lakukan dan membawa pengetahuan tertentu kepada seni bina kami.
Skala
Beberapa nombor untuk ilustrasi.
Kami mereka bentuk sistem untuk 80 juta pelanggan dengan rizab satu bilion. Beginilah cara kami mengalih keluar ambang masa hadapan. Ini bukan kerana kita akan mengambil alih China, tetapi kerana serangan IoT dan M2M.
300 juta dokumen diproses dalam masa nyata. Walaupun kami mempunyai 80 juta pelanggan, kami bekerjasama dengan bakal pelanggan dan mereka yang telah meninggalkan kami jika kami perlu mengutip belum terima. Oleh itu, volum sebenar adalah lebih besar.
2 bilion transaksi Baki berubah setiap hari - ini adalah pembayaran, caj, panggilan dan acara lain. 200 TB data sedang berubah secara aktif, tukar lambat sikit 8 PB data, dan ini bukan arkib, tetapi data langsung dalam satu pengebilan. Skala mengikut pusat data - 5 ribu pelayan di 14 tapak.
Timbunan teknologi
Apabila kami merancang seni bina dan mula memasang sistem, kami mengimport teknologi yang paling menarik dan canggih. Hasilnya ialah timbunan teknologi yang biasa kepada mana-mana pemain Internet dan syarikat yang membuat sistem beban tinggi.
Timbunan adalah serupa dengan timbunan pemain utama lain: Netflix, Twitter, Viber. Ia terdiri daripada 6 komponen, tetapi kami ingin memendekkan dan menyatukannya.
Fleksibiliti adalah baik, tetapi dalam syarikat besar tidak ada cara tanpa penyatuan.
Kami tidak akan menukar Oracle yang sama kepada Tarantool. Dalam realiti syarikat besar, ini adalah utopia, atau perang salib selama 5-10 tahun dengan hasil yang tidak jelas. Tetapi Cassandra dan Couchbase boleh digantikan dengan Tarantool dengan mudah, dan itulah yang kami perjuangkan.
Mengapa Tarantool?
Terdapat 4 kriteria mudah mengapa kami memilih pangkalan data ini.
Kelajuan. Kami menjalankan ujian beban pada sistem perindustrian MegaFon. Tarantool menang - ia menunjukkan prestasi terbaik.
Ini bukan untuk mengatakan bahawa sistem lain tidak memenuhi keperluan MegaFon. Penyelesaian memori semasa sangat produktif sehingga rizab syarikat adalah lebih daripada mencukupi. Tetapi kami berminat untuk berurusan dengan pemimpin, dan bukan dengan seseorang yang ketinggalan, termasuk dalam ujian beban.
Tarantool meliputi keperluan syarikat walaupun dalam jangka panjang.
kos TCO. Sokongan untuk Couchbase pada jilid MegaFon menelan belanja yang besar, tetapi dengan Tarantool keadaannya lebih menyenangkan, dan fungsinya serupa.
Satu lagi ciri bagus yang sedikit mempengaruhi pilihan kami ialah Tarantool berfungsi lebih baik dengan memori daripada pangkalan data lain. Dia menunjukkan kecekapan maksimum.
Kebolehpercayaan. MegaFon melabur dalam kebolehpercayaan, mungkin lebih daripada orang lain. Oleh itu, apabila kami melihat Tarantool, kami menyedari bahawa kami perlu memenuhi keperluan kami.
Kami melaburkan masa dan kewangan kami, dan bersama-sama dengan Mail.ru kami mencipta versi perusahaan, yang kini digunakan dalam beberapa syarikat lain.
Tarantool-enterprise memuaskan hati kami sepenuhnya dari segi keselamatan, kebolehpercayaan dan pembalakan.
Perkongsian
Perkara yang paling penting bagi saya ialah hubungan terus dengan pemaju. Inilah sebenarnya yang disogok oleh lelaki dari Tarantool.
Jika anda datang kepada pemain, terutamanya yang bekerja dengan pelanggan utama, dan mengatakan bahawa anda memerlukan pangkalan data untuk dapat melakukan ini, ini dan ini, dia biasanya menjawab:
- Baiklah, letakkan keperluan di bahagian bawah longgokan itu - suatu hari nanti, kita mungkin akan mencapainya.
Ramai yang mempunyai pelan hala tuju untuk 2-3 tahun akan datang, dan hampir mustahil untuk disepadukan di sana, tetapi pemaju Tarantool menawan hati dengan keterbukaan mereka, dan bukan sahaja dari MegaFon, dan menyesuaikan sistem mereka kepada pelanggan. Ia hebat dan kami sangat menyukainya.
Tempat kami menggunakan Tarantool
Kami menggunakan Tarantool dalam beberapa elemen. Yang pertama adalah dalam juruterbang, yang kami buat pada sistem direktori alamat. Pada satu masa saya mahu ia menjadi sistem yang serupa dengan Yandex.Maps dan Peta Google, tetapi ternyata berbeza sedikit.
Contohnya, katalog alamat dalam antara muka jualan. Pada Oracle, mencari alamat yang dikehendaki mengambil masa 12-13 saat. - nombor yang tidak selesa. Apabila kami bertukar kepada Tarantool, gantikan Oracle dengan pangkalan data lain dalam konsol, dan melakukan carian yang sama, kami mendapat kelajuan 200x! Bandar ini muncul selepas huruf ketiga. Kini kami menyesuaikan antara muka supaya ini berlaku selepas yang pertama. Walau bagaimanapun, kelajuan tindak balas adalah berbeza sama sekali - milisaat dan bukannya saat.
Aplikasi kedua ialah tema bergaya yang dipanggil IT dua kelajuan. Ini kerana perunding dari setiap sudut mengatakan bahawa syarikat harus pergi ke sana.
Terdapat lapisan infrastruktur, di atasnya terdapat domain, contohnya, sistem pengebilan seperti telekom, sistem korporat, pelaporan korporat. Inilah inti yang tidak perlu disentuh. Itu, tentu saja, adalah mungkin, tetapi secara paranoid memastikan kualiti, kerana ia membawa wang kepada perbadanan.
Seterusnya ialah lapisan perkhidmatan mikro - yang membezakan pengendali atau pemain lain. Perkhidmatan mikro boleh dibuat dengan cepat berdasarkan cache tertentu, membawa data dari domain berbeza ke sana. Di sini medan untuk eksperimen β jika sesuatu tidak berjaya, saya menutup satu perkhidmatan mikro dan membuka satu lagi. Ini memberikan masa ke pasaran yang benar-benar meningkat dan meningkatkan kebolehpercayaan dan kelajuan syarikat.
Perkhidmatan mikro mungkin merupakan peranan utama Tarantool di MegaFon.
Di mana kami merancang untuk menggunakan Tarantool
Jika kami membandingkan projek pengebilan kami yang berjaya dengan program transformasi di Deutsche Telekom, Svyazcom, Vodafone India, ia amat dinamik dan kreatif. Dalam proses melaksanakan projek ini, bukan sahaja MegaFon dan strukturnya telah diubah, tetapi juga Tarantool-enterprise muncul di Mail.ru, dan vendor kami Nexign (dahulunya Peter-Service) - BSS Box (penyelesaian bil berkotak).
Ini, dalam erti kata lain, projek bersejarah untuk pasaran Rusia. Ia boleh dibandingkan dengan apa yang diterangkan dalam buku "The Mythical Man-Month" oleh Frederick Brooks. Kemudian, pada tahun 60-an, IBM mengupah 360 orang untuk membangunkan sistem pengendalian OS/5 baharu untuk kerangka utama. Kami mempunyai kurang - 000, tetapi milik kami adalah hak, dan mengambil kira penggunaan sumber terbuka dan pendekatan baharu, kami bekerja dengan lebih produktif.
Di bawah ialah domain pengebilan atau, secara lebih luas, sistem perniagaan. Orang dari perusahaan tahu CRM dengan baik. Setiap orang sepatutnya sudah mempunyai sistem lain: Open API, API Gateway.
Terbuka API
Mari lihat nombor sekali lagi dan cara API Terbuka berfungsi pada masa ini. Bebannya ialah 10 transaksi sesaat. Memandangkan kami merancang untuk membangunkan lapisan perkhidmatan mikro secara aktif dan membina API awam MegaFon, kami menjangkakan pertumbuhan yang lebih besar pada masa hadapan dalam bahagian ini. Pasti akan ada 100 transaksi.
Saya tidak tahu sama ada kita boleh membandingkan dengan Mail.ru dalam SSO - lelaki itu nampaknya mempunyai 1 transaksi sesaat. Penyelesaian mereka amat menarik kepada kami dan kami merancang untuk menerima pakai pengalaman mereka - contohnya, membuat sandaran SSO berfungsi menggunakan Tarantool. Sekarang pembangun dari Mail.ru melakukan ini untuk kami.
CRM
CRM adalah 80 juta pelanggan yang sama yang kami mahu tingkatkan kepada satu bilion, kerana sudah ada 300 juta dokumen yang merangkumi sejarah tiga tahun. Kami sangat menantikan perkhidmatan baharu dan di sini titik pertumbuhan ialah perkhidmatan bersambung. Ini adalah bola yang akan berkembang, kerana akan ada lebih banyak perkhidmatan. Oleh itu, kami memerlukan cerita; kami tidak mahu tersandung mengenai perkara ini.
Mengebil sendiri dari segi mengeluarkan invois, bekerja dengan akaun belum terima pelanggan diubah menjadi domain yang berasingan. Untuk meningkatkan prestasi, corak seni bina seni bina domain yang digunakan.
Sistem ini dibahagikan kepada domain, beban diagihkan dan toleransi kesalahan dipastikan. Selain itu, kami bekerja dengan seni bina teragih.
Segala-galanya ialah penyelesaian peringkat perusahaan. Dalam storan panggilan - 2 bilion sehari, 60 bilion sebulan. Kadangkala anda perlu mengiranya dalam sebulan, dan ia lebih baik dengan cepat. Pemantauan kewangan - ini adalah sama 300 juta yang sentiasa berkembang dan berkembang: pelanggan sering berjalan antara operator, meningkatkan bahagian ini.
Komponen telekom komunikasi mudah alih yang paling banyak ialah pengebilan dalam talian. Ini ialah sistem yang membolehkan anda membuat panggilan atau tidak memanggil, membuat keputusan dalam masa nyata. Di sini bebannya ialah 30 transaksi sesaat, tetapi dengan mengambil kira pertumbuhan dalam pemindahan data, kami merancang 250 transaksi, dan oleh itu kami sangat berminat dengan Tarantool.
Gambar sebelumnya ialah domain di mana kita akan menggunakan Tarantool. CRM sendiri, sudah tentu, lebih luas dan kami akan menggunakannya dalam teras itu sendiri.
Angka anggaran TTX kami sebanyak 100 juta pelanggan mengelirukan saya sebagai seorang arkitek - bagaimana jika 101 juta? Adakah anda perlu membuat semula semuanya? Untuk mengelakkan perkara ini berlaku, kami menggunakan cache, pada masa yang sama meningkatkan kebolehaksesan.
Secara umum, terdapat dua pendekatan untuk menggunakan Tarantool. pertama - bina semua cache pada tahap perkhidmatan mikro. Setakat yang saya faham, VimpelCom mengikuti laluan ini, mencipta cache pelanggan.
Kami kurang bergantung kepada vendor, kami menukar teras BSS, jadi kami mempunyai satu fail pelanggan di luar kotak. Tetapi kami mahu mengembangkannya. Oleh itu, kami mengambil pendekatan yang sedikit berbeza - buat cache di dalam sistem.
Dengan cara ini terdapat kurang penyegerakan - satu sistem bertanggungjawab untuk kedua-dua cache dan sumber induk utama.
Kaedah ini sesuai dengan pendekatan Tarantool dengan rangka transaksi, apabila hanya bahagian yang berkaitan dengan kemas kini, iaitu, perubahan data, dikemas kini. Semua yang lain boleh disimpan di tempat lain. Tiada tasik data yang besar, cache global yang tidak terurus. Cache direka bentuk untuk sistem, atau untuk produk, atau untuk pelanggan, atau untuk menjadikan kehidupan lebih mudah untuk penyelenggaraan. Apabila pelanggan menelefon dan kecewa dengan kualiti perkhidmatan anda, anda ingin memberikan perkhidmatan yang berkualiti.
RTO dan RPO
Terdapat dua istilah dalam IT - RTO ΠΈ RPO.
Objektif masa pemulihan ialah masa yang diperlukan untuk memulihkan perkhidmatan selepas kegagalan. RTO = 0 bermakna walaupun sesuatu gagal, perkhidmatan itu terus berfungsi.
Objektif titik pemulihan - ini ialah masa pemulihan data, berapa banyak data yang boleh hilang dalam tempoh masa tertentu. RPO = 0 bermakna kami tidak kehilangan data.
Tugas Tarantool
Mari cuba selesaikan masalah untuk Tarantool.
Diberi: sekumpulan aplikasi yang semua orang faham, contohnya, di Amazon atau di tempat lain. Diperlukan supaya troli beli-belah berfungsi 24 jam 7 hari seminggu, atau 99,99% sepanjang masa. Pesanan yang datang kepada kami mesti kekal teratur, kerana kami tidak boleh menghidupkan atau mematikan sambungan pelanggan secara rawak - semuanya mestilah konsisten. Langganan sebelumnya mempengaruhi langganan seterusnya, jadi data adalah penting - tiada apa yang harus hilang.
keputusan. Anda boleh cuba menyelesaikannya secara langsung dan bertanya kepada pembangun pangkalan data, tetapi masalahnya tidak dapat diselesaikan secara matematik. Anda boleh ingat teorem, undang-undang pemuliharaan, fizik kuantum, tetapi mengapa - ia tidak boleh diselesaikan di peringkat DB.
Pendekatan seni bina lama yang baik berfungsi di sini - anda perlu mengetahui bidang subjek dengan baik dan menggunakannya untuk menyelesaikan teka-teki ini.
Penyelesaian kami: mencipta pendaftaran aplikasi teragih pada Tarantool - kluster teragih geo. Dalam rajah, ini adalah tiga pusat pemprosesan data yang berbeza - dua sebelum Ural, satu di luar Ural, dan kami mengedarkan semua permintaan antara pusat ini.
Netflix, yang kini dianggap sebagai salah satu peneraju dalam IT, hanya mempunyai satu pusat data sehingga 2012. Menjelang Krismas Katolik, 24 Disember, pusat data ini rosak. Pengguna di Kanada dan Amerika Syarikat ditinggalkan tanpa filem kegemaran mereka, sangat kecewa dan menulis mengenainya di rangkaian sosial. Netflix kini mempunyai tiga pusat data di pantai barat-timur dan satu di Eropah barat.
Kami pada mulanya membina penyelesaian teragih geo - toleransi kesalahan adalah penting bagi kami.
Jadi kita mempunyai kluster, tetapi bagaimana pula dengan RPO = 0 dan RTO = 0? Penyelesaiannya mudah, bergantung pada subjek.
Apakah yang penting dalam aplikasi? Dua Bahagian: Baling Bakul KEPADA membuat keputusan pembelian, dan SELEPAS. Bahagian DO dalam telekom biasanya dipanggil menangkap pesanan atau rundingan pesanan. Dalam telekomunikasi, ini boleh menjadi lebih sukar daripada di kedai dalam talian, kerana di sana pelanggan mesti dilayan, ditawarkan 5 pilihan, dan ini semua berlaku untuk beberapa waktu, tetapi bakul dipenuhi. Pada masa ini, kegagalan adalah mungkin, tetapi ia tidak menakutkan, kerana ia berlaku secara interaktif di bawah pengawasan manusia.
Jika pusat data Moscow tiba-tiba gagal, maka dengan beralih secara automatik ke pusat data lain, kami akan terus bekerja. Secara teorinya, satu produk mungkin hilang dalam troli, tetapi anda melihatnya, tambah pada troli semula dan teruskan bekerja. Dalam kes ini RTO = 0.
Pada masa yang sama, terdapat pilihan kedua: apabila kami mengklik "serahkan", kami mahu data tidak hilang. Mulai saat ini, automasi mula berfungsi - ini ialah RPO = 0. Menggunakan kedua-dua corak berbeza ini, dalam satu kes ia boleh menjadi kluster teragih geo dengan satu induk boleh tukar, dalam kes lain sejenis rekod kuorum. Corak mungkin berbeza, tetapi kami menyelesaikan masalah.
Selanjutnya, mempunyai pendaftaran aplikasi yang diedarkan, kami juga boleh menskalakan semuanya - mempunyai ramai penghantar dan pelaksana yang mengakses pendaftaran ini.
Cassandra dan Tarantool bersama-sama
Terdapat satu lagi kes - "pameran baki". Berikut adalah kes menarik penggunaan bersama Cassandra dan Tarantool.
Kami menggunakan Cassandra kerana 2 bilion panggilan setiap hari bukanlah had, dan akan ada lebih banyak lagi. Pemasar suka mewarnakan trafik mengikut sumber; semakin banyak butiran muncul di rangkaian sosial, contohnya. Semuanya menambah cerita.
Cassandra membolehkan anda membuat skala secara mendatar kepada sebarang saiz.
Kami berasa selesa dengan Cassandra, tetapi ia mempunyai satu masalah - ia tidak pandai membaca. Semuanya OK pada rakaman, 30 sesaat tidak menjadi masalah - masalah membaca.
Oleh itu, topik dengan cache muncul, dan pada masa yang sama kami menyelesaikan masalah berikut: terdapat kes tradisional lama apabila peralatan daripada suis daripada pengebilan dalam talian masuk ke dalam fail yang kami muatkan ke Cassandra. Kami bergelut dengan masalah muat turun fail yang boleh dipercayai, walaupun menggunakan nasihat pemindahan fail pengurus IBM - terdapat penyelesaian yang menguruskan pemindahan fail dengan cekap, menggunakan protokol UDP, contohnya, dan bukannya TCP. Ini bagus, tetapi masih beberapa minit, dan kami belum memuatkan semuanya lagi, pengendali di pusat panggilan tidak dapat menjawab pelanggan apa yang berlaku kepada bakinya - kami perlu menunggu.
Untuk mengelakkan perkara ini berlaku, kami kami menggunakan rizab fungsi selari. Apabila kami menghantar acara melalui Kafka ke Tarantool, mengira semula agregat dalam masa nyata, contohnya, untuk hari ini, kami mendapat baki tunai, yang boleh memindahkan baki pada sebarang kelajuan, contohnya, 100 ribu transaksi sesaat dan 2 saat yang sama.
Matlamatnya ialah selepas membuat panggilan, dalam masa 2 saat dalam akaun peribadi anda akan terdapat bukan sahaja baki yang ditukar, tetapi maklumat tentang sebab ia berubah.
Kesimpulan
Ini adalah contoh penggunaan Tarantool. Kami sangat menyukai keterbukaan Mail.ru dan kesediaan mereka untuk mempertimbangkan kes yang berbeza.
Sudah sukar untuk perunding dari BCG atau McKinsey, Accenture atau IBM untuk mengejutkan kami dengan sesuatu yang baharu - kebanyakan daripada apa yang mereka tawarkan, sama ada kami sudah lakukan, telah lakukan atau sedang merancang untuk melakukannya. Saya fikir Tarantool akan mengambil tempat yang sepatutnya dalam timbunan teknologi kami dan akan menggantikan banyak teknologi sedia ada. Kami sedang dalam fasa aktif pembangunan projek ini.
Laporan oleh Oleg dan Andrey adalah salah satu yang terbaik di Persidangan Tarantool tahun lepas, dan pada 17 Jun Oleg Ivlev akan bercakap di dengan laporan . Alexander Deulin juga akan memberikan persembahan daripada MegaFon . Mari kita ketahui apa yang telah berubah, apakah rancangan yang telah dilaksanakan. Sertai - persidangan adalah percuma, anda hanya perlu lakukan . Semua dan program persidangan telah dibentuk: kes baharu, pengalaman baharu dalam menggunakan Tarantool, seni bina, perusahaan, tutorial dan perkhidmatan mikro.
Sumber: www.habr.com