Mengapa perusahaan seperti MegaFon membutuhkan Tarantool dalam penagihannya? Dari luar nampaknya vendor biasanya datang, membawa semacam kotak besar, mencolokkan steker ke stopkontak - dan itulah tagihannya! Dulunya hal ini terjadi, tetapi sekarang sudah kuno, dan dinosaurus semacam itu telah punah atau sedang punah. Awalnya, penagihan adalah sistem penerbitan faktur - mesin penghitung atau kalkulator. Dalam telekomunikasi modern hal ini terjadi sistem otomasi untuk seluruh siklus hidup interaksi dengan pelanggan mulai dari penutupan kontrak hingga penghentian, termasuk penagihan waktu nyata, penerimaan pembayaran, dan banyak lagi. Penagihan di perusahaan telekomunikasi seperti robot tempur - besar, kuat, dan sarat dengan senjata.
Apa hubungannya Tarantool dengan itu? Mereka akan membicarakannya Oleg Ivlev и Andrey Knyazev. Oleg adalah kepala arsitek perusahaan dengan pengalaman luas bekerja di perusahaan asing, Andrey adalah direktur sistem bisnis. Dari transkrip laporan mereka Anda akan mempelajari mengapa R&D diperlukan di perusahaan, apa itu Tarantool, bagaimana kebuntuan penskalaan vertikal dan globalisasi menjadi prasyarat munculnya database ini di perusahaan, tentang tantangan teknologi, transformasi arsitektur, dan bagaimana technostack MegaFon mirip dengan Netflix , Google dan Amazon.
Proyek "Penagihan Terpadu"
Proyek yang dimaksud disebut “Penagihan Terpadu”. Di sinilah Tarantool menunjukkan kualitas terbaiknya.
Pertumbuhan produktivitas peralatan Hi-End tidak sejalan dengan pertumbuhan basis pelanggan dan pertumbuhan jumlah layanan; pertumbuhan lebih lanjut dalam jumlah pelanggan dan layanan diperkirakan disebabkan oleh fitur M2M, IoT, dan cabang. terhadap penurunan waktu pemasaran. Perusahaan memutuskan untuk membuat sistem bisnis terpadu dengan arsitektur modular kelas dunia yang unik, dibandingkan dengan 8 sistem penagihan berbeda yang ada saat ini.
MegaFon adalah delapan perusahaan dalam satu. Pada tahun 2009, reorganisasi selesai: cabang di seluruh Rusia bergabung menjadi satu perusahaan, MegaFon OJSC (sekarang PJSC). Dengan demikian, perusahaan memiliki 8 sistem penagihan dengan solusi “khusus”, fitur cabang, dan struktur organisasi, TI, dan pemasaran yang berbeda.
Semuanya baik-baik saja sampai kami harus meluncurkan satu produk federal yang umum. Banyak kesulitan yang muncul di sini: bagi sebagian orang, tarif dibulatkan ke atas, bagi sebagian lainnya dibulatkan ke bawah, dan bagi sebagian lainnya, berdasarkan mean aritmatika. Ada ribuan momen seperti itu.
Terlepas dari kenyataan bahwa hanya ada satu versi sistem penagihan, satu pemasok, pengaturannya sangat berbeda sehingga butuh waktu lama untuk menyatukannya. Kami mencoba mengurangi jumlah mereka, dan menemukan masalah kedua yang umum dialami banyak perusahaan.
Penskalaan vertikal. Bahkan perangkat keras paling keren saat itu pun tidak memenuhi kebutuhan. Kami menggunakan peralatan Hewlett-Packard dari lini Superdome Hi-End, tetapi tidak memenuhi kebutuhan bahkan di dua cabang. Saya menginginkan penskalaan horizontal tanpa biaya operasional dan investasi modal yang besar.
Ekspektasi pertumbuhan jumlah pelanggan dan layanan. Konsultan telah lama membawa cerita tentang IoT dan M2M ke dunia telekomunikasi: akan tiba saatnya setiap telepon dan setrika akan memiliki satu kartu SIM, dan dua di lemari es. Saat ini kami memiliki satu pelanggan, tetapi dalam waktu dekat akan ada lebih banyak lagi.
Tantangan teknologi
Keempat alasan inilah yang memotivasi kami untuk melakukan perubahan serius. Ada pilihan antara mengupgrade sistem dan mendesain dari awal. Kami berpikir lama, mengambil keputusan serius, memainkan tender. Hasilnya, kami memutuskan untuk mendesain sejak awal, dan menghadapi tantangan menarik – tantangan teknologi.
Skalabilitas
Kalau sebelumnya, katakanlah, katakanlah 8 billing untuk 15 juta pelanggan, dan sekarang seharusnya berhasil 100 juta pelanggan dan banyak lagi - bebannya jauh lebih tinggi.
Skala kami telah menjadi sebanding dengan pemain Internet besar seperti Mail.ru atau Netflix.
Namun langkah lebih lanjut untuk meningkatkan beban dan basis pelanggan telah memberikan tantangan serius bagi kami.
Geografi negara kita yang luas
Antara Kaliningrad dan Vladivostok 7500 km dan 10 zona waktu. Kecepatan cahaya terbatas dan pada jarak seperti itu, penundaannya sudah signifikan. 150 ms pada saluran optik modern yang paling keren terlalu banyak untuk penagihan real-time, terutama seperti yang terjadi sekarang di telekomunikasi di Rusia. Selain itu, Anda perlu memperbarui dalam satu hari kerja, dan dengan zona waktu berbeda, hal ini menjadi masalah.
Kami tidak hanya menyediakan layanan dengan biaya berlangganan, kami memiliki tarif, paket, dan berbagai pengubah yang rumit. Kita tidak hanya perlu mengizinkan atau menolak pelanggan untuk berbicara, tetapi juga memberinya kuota tertentu - menghitung panggilan dan tindakan secara real time sehingga dia tidak menyadarinya.
toleransi kesalahan
Ini adalah sisi lain dari sentralisasi.
Jika kami mengumpulkan semua pelanggan dalam satu sistem, maka kejadian darurat dan bencana apa pun akan menjadi bencana bagi bisnis. Oleh karena itu, kami merancang sistem sedemikian rupa untuk menghilangkan dampak kecelakaan pada seluruh basis pelanggan.
Hal ini sekali lagi merupakan konsekuensi dari penolakan untuk melakukan skala vertikal. Saat kami melakukan penskalaan secara horizontal, kami meningkatkan jumlah server dari ratusan menjadi ribuan. Mereka perlu dikelola dan dipertukarkan, secara otomatis mencadangkan infrastruktur TI dan memulihkan sistem terdistribusi.
Kami menghadapi tantangan yang sangat menarik. Kami merancang sistemnya, dan pada saat itu kami mencoba menemukan praktik terbaik global untuk memeriksa seberapa tren kami, seberapa banyak kami mengikuti teknologi canggih.
Pengalaman dunia
Anehnya, kami tidak menemukan satu pun referensi di bidang telekomunikasi global.
Eropa telah tertinggal dalam hal jumlah pelanggan dan skala, Amerika Serikat dalam hal tarif yang tetap. Kami melihat beberapa di Cina, dan menemukan beberapa di India dan menyewa spesialis dari Vodafone India.
Untuk menganalisis arsitektur, kami membentuk Tim Impian yang dipimpin oleh IBM - arsitek dari berbagai bidang. Orang-orang ini dapat menilai secara memadai apa yang kami lakukan dan membawa pengetahuan tertentu ke dalam arsitektur kami.
Skala
Beberapa angka untuk ilustrasi.
Kami merancang sistem untuk 80 juta pelanggan dengan cadangan satu miliar. Inilah cara kami menghilangkan ambang batas di masa depan. Hal ini bukan karena kita akan mengambil alih Tiongkok, namun karena gencarnya IoT dan M2M.
300 juta dokumen diproses secara real time. Meskipun kami memiliki 80 juta pelanggan, kami bekerja dengan klien potensial dan mereka yang telah meninggalkan kami jika kami perlu menagih piutang. Oleh karena itu, volume sebenarnya jauh lebih besar.
2 miliar transaksi Saldo berubah setiap hari - ini adalah pembayaran, tagihan, panggilan, dan acara lainnya. Data sebesar 200 TB sedang berubah secara aktif, ubah sedikit lebih lambat 8 PB data, dan ini bukan arsip, melainkan data langsung dalam satu penagihan. Skala berdasarkan pusat data - 5 ribu server di 14 situs.
Tumpukan teknologi
Saat kami merencanakan arsitektur dan mulai merakit sistem, kami mengimpor teknologi yang paling menarik dan canggih. Hasilnya adalah tumpukan teknologi yang familier bagi setiap pemain Internet dan perusahaan yang membuat sistem dengan beban tinggi.
Tumpukannya mirip dengan tumpukan pemain besar lainnya: Netflix, Twitter, Viber. Terdiri dari 6 komponen, namun kami ingin mempersingkat dan menyatukannya.
Fleksibilitas itu baik, tetapi dalam perusahaan besar tidak ada jalan tanpa unifikasi.
Kami tidak akan mengubah Oracle yang sama ke Tarantool. Dalam realitas perusahaan besar, ini adalah utopia, atau perang salib selama 5-10 tahun dengan hasil yang tidak jelas. Namun Cassandra dan Couchbase dapat dengan mudah digantikan dengan Tarantool, dan itulah yang kami perjuangkan.
Mengapa Tarantool?
Ada 4 kriteria sederhana mengapa kami memilih database ini.
Mempercepat. Kami melakukan uji beban pada sistem industri MegaFon. Tarantool menang - ini menunjukkan performa terbaik.
Ini tidak berarti bahwa sistem lain tidak memenuhi kebutuhan MegaFon. Solusi memori saat ini sangat produktif sehingga cadangan perusahaan lebih dari cukup. Namun kami tertarik untuk berurusan dengan seorang pemimpin, dan bukan dengan seseorang yang tertinggal, termasuk dalam uji beban.
Tarantool memenuhi kebutuhan perusahaan bahkan dalam jangka panjang.
biaya TCO. Dukungan untuk Couchbase pada volume MegaFon menghabiskan banyak uang, tetapi dengan Tarantool situasinya jauh lebih menyenangkan, dan fungsinya serupa.
Fitur bagus lainnya yang sedikit memengaruhi pilihan kami adalah Tarantool bekerja lebih baik dengan memori dibandingkan database lain. Dia menunjukkan efisiensi maksimum.
Keandalan. MegaFon berinvestasi pada keandalan, mungkin lebih dari siapa pun. Jadi ketika kami melihat Tarantool, kami menyadari bahwa kami harus membuatnya memenuhi persyaratan kami.
Kami menginvestasikan waktu dan keuangan kami, dan bersama Mail.ru kami membuat versi perusahaan, yang sekarang digunakan di beberapa perusahaan lain.
Perusahaan Tarantool benar-benar memuaskan kami dalam hal keamanan, keandalan, dan logging.
persekutuan
Yang paling penting bagi saya adalah kontak langsung dengan pengembang. Inilah yang disuap oleh orang-orang dari Tarantool.
Jika Anda mendatangi seorang pemain, terutama yang bekerja dengan klien jangkar, dan mengatakan bahwa Anda memerlukan database untuk dapat melakukan ini, ini dan ini, dia biasanya menjawab:
- Oke, letakkan persyaratan di bagian paling bawah tumpukan itu - suatu hari nanti, kita mungkin akan memenuhinya.
Banyak yang memiliki peta jalan untuk 2-3 tahun ke depan, dan hampir tidak mungkin untuk berintegrasi di sana, namun pengembang Tarantool memikat dengan keterbukaan mereka, dan tidak hanya dari MegaFon, dan menyesuaikan sistem mereka dengan pelanggan. Itu keren dan kami sangat menyukainya.
Dimana kami menggunakan Tarantool
Kami menggunakan Tarantool di beberapa elemen. Yang pertama ada di pilot, yang kami buat pada sistem direktori alamat. Pada suatu waktu saya ingin sistemnya mirip dengan Yandex.Maps dan Google Maps, tetapi ternyata sedikit berbeda.
Misalnya, katalog alamat di antarmuka penjualan. Di Oracle, mencari alamat yang diinginkan membutuhkan waktu 12-13 detik. - angka yang tidak nyaman. Saat kami beralih ke Tarantool, mengganti Oracle dengan database lain di konsol, dan melakukan pencarian yang sama, kami mendapatkan peningkatan 200x! Kota muncul setelah huruf ketiga. Sekarang kami mengadaptasi antarmuka sehingga ini terjadi setelah yang pertama. Namun, kecepatan responsnya sangat berbeda - milidetik, bukan detik.
Aplikasi kedua adalah tema trendi yang disebut IT dua kecepatan. Sebab, konsultan dari berbagai penjuru mengatakan korporasi harus berangkat ke sana.
Ada lapisan infrastruktur, di atasnya ada domain, misalnya sistem penagihan seperti telekomunikasi, sistem perusahaan, pelaporan perusahaan. Inilah inti yang tidak perlu disentuh. Tentu saja hal ini mungkin terjadi, namun secara paranoid menjamin kualitas, karena hal ini mendatangkan uang bagi perusahaan.
Berikutnya adalah lapisan layanan mikro - yang membedakan operator atau pemain lainnya. Layanan mikro dapat dengan cepat dibuat berdasarkan cache tertentu, membawa data dari domain berbeda ke sana. Di Sini lapangan untuk percobaan — jika sesuatu tidak berhasil, saya menutup satu layanan mikro dan membuka layanan lainnya. Hal ini benar-benar memberikan peningkatan waktu pemasaran dan meningkatkan keandalan serta kecepatan perusahaan.
Layanan mikro mungkin merupakan peran utama Tarantool di MegaFon.
Dimana kami berencana menggunakan Tarantool
Jika kita membandingkan keberhasilan proyek penagihan kami dengan program transformasi di Deutsche Telekom, Svyazcom, Vodafone India, ternyata proyek ini sangat dinamis dan kreatif. Dalam proses implementasi proyek ini, tidak hanya MegaFon dan strukturnya yang diubah, tetapi juga perusahaan Tarantool muncul di Mail.ru, dan vendor kami Nexign (sebelumnya Peter-Service) - BSS Box (solusi penagihan kotak).
Ini, dalam arti tertentu, merupakan proyek bersejarah bagi pasar Rusia. Hal ini dapat dibandingkan dengan apa yang dijelaskan dalam buku “The Mythical Man-Month” oleh Frederick Brooks. Kemudian, pada tahun 60an, IBM mempekerjakan 360 orang untuk mengembangkan sistem operasi OS/5 baru untuk mainframe. Kami memiliki lebih sedikit - 000, tetapi kami memiliki rompi, dan dengan mempertimbangkan penggunaan sumber terbuka dan pendekatan baru, kami bekerja lebih produktif.
Di bawah ini adalah domain penagihan atau, lebih luas lagi, sistem bisnis. Orang-orang dari perusahaan mengetahui CRM dengan sangat baik. Setiap orang seharusnya sudah memiliki sistem lain: Open API, API Gateway.
API terbuka
Mari kita lihat kembali angka-angkanya dan cara kerja Open API saat ini. Muatannya adalah 10 transaksi per detik. Karena kami berencana untuk secara aktif mengembangkan lapisan layanan mikro dan membangun API publik MegaFon, kami mengharapkan pertumbuhan yang lebih besar di masa depan pada bagian ini. Pasti akan ada 100 transaksi.
Saya tidak tahu apakah kita bisa membandingkannya dengan Mail.ru di SSO - sepertinya ada 1 transaksi per detik. Solusi mereka sangat menarik bagi kami dan kami berencana untuk mengadopsi pengalaman mereka - misalnya, membuat cadangan SSO yang berfungsi menggunakan Tarantool. Sekarang pengembang dari Mail.ru melakukan ini untuk kami.
CRM
CRM sama dengan 80 juta pelanggan yang ingin kami tingkatkan menjadi satu miliar, karena sudah ada 300 juta dokumen yang mencakup riwayat tiga tahun. Kami sangat menantikan layanan baru dan di sini titik pertumbuhannya adalah layanan yang terhubung. Ini adalah bola yang akan berkembang, karena akan ada lebih banyak layanan. Oleh karena itu, kita memerlukan sebuah cerita, kita tidak ingin tersandung pada hal ini.
Penagihan sendiri dalam hal penerbitan invoice, pengerjaan piutang pelanggan diubah menjadi domain terpisah. Untuk meningkatkan kinerja, pola arsitektur arsitektur domain terapan.
Sistem dibagi menjadi beberapa domain, beban didistribusikan dan toleransi kesalahan dipastikan. Selain itu, kami bekerja dengan arsitektur terdistribusi.
Yang lainnya adalah solusi tingkat perusahaan. Dalam penyimpanan panggilan - 2 miliar per hari,60 miliar per bulan. Terkadang Anda harus menghitungnya dalam sebulan, dan itu lebih baik dengan cepat. Pemantauan keuangan - ini persis sama dengan 300 juta yang terus bertambah dan bertambah: pelanggan sering kali berpindah antar operator, meningkatkan bagian ini.
Komponen telekomunikasi yang paling banyak dalam komunikasi seluler adalah penagihan daring. Ini adalah sistem yang memungkinkan Anda menelepon atau tidak menelepon, membuat keputusan secara real time. Di sini bebannya adalah 30 transaksi per detik, tetapi dengan mempertimbangkan pertumbuhan transfer data, kami merencanakannya 250 transaksi, dan oleh karena itu kami sangat tertarik dengan Tarantool.
Gambar sebelumnya adalah domain dimana kita akan menggunakan Tarantool. CRM sendiri tentu saja lebih luas dan kami akan menggunakannya pada intinya sendiri.
Perkiraan angka TTX kami sebesar 100 juta pelanggan membingungkan saya sebagai seorang arsitek - bagaimana jika 101 juta? Apakah Anda harus mengulangi semuanya lagi? Untuk mencegah hal ini terjadi, kami menggunakan cache, sekaligus meningkatkan aksesibilitas.
Secara umum, ada dua pendekatan dalam menggunakan Tarantool. Pertama - membangun semua cache di tingkat layanan mikro. Sejauh yang saya pahami, VimpelCom mengikuti jalur ini, membuat cache klien.
Kami tidak terlalu bergantung pada vendor, kami mengubah inti BSS, jadi kami memiliki satu file klien yang siap digunakan. Tapi kami ingin memperluasnya. Oleh karena itu, kami mengambil pendekatan yang sedikit berbeda - membuat cache di dalam sistem.
Dengan cara ini sinkronisasi menjadi lebih sedikit - satu sistem bertanggung jawab atas cache dan sumber master utama.
Metode ini cocok dengan pendekatan Tarantool dengan kerangka transaksional, ketika hanya bagian yang berhubungan dengan pembaruan, yaitu perubahan data, yang diperbarui. Segala sesuatu yang lain dapat disimpan di tempat lain. Tidak ada data lake yang besar, cache global yang tidak dikelola. Cache dirancang untuk sistem, atau untuk produk, atau untuk klien, atau untuk mempermudah pemeliharaan. Ketika pelanggan menelepon dan kecewa dengan kualitas layanan Anda, Anda ingin memberikan layanan berkualitas.
RTO dan RPO
Ada dua istilah dalam TI - RTO и RPO.
Tujuan waktu pemulihan adalah waktu yang diperlukan untuk memulihkan layanan setelah kegagalan. RTO = 0 berarti meskipun ada yang gagal, layanan tetap berfungsi.
Tujuan titik pemulihan - ini adalah waktu pemulihan data, berapa banyak data yang bisa hilang dalam jangka waktu tertentu. RPO = 0 berarti kita tidak kehilangan data.
Tugas Tarantool
Mari kita coba selesaikan masalah Tarantool.
Diberikan: sekumpulan aplikasi yang dipahami semua orang, misalnya di Amazon atau di tempat lain. wajib sehingga keranjang belanja bekerja 24 jam 7 hari seminggu, atau 99,99% waktunya. Pesanan yang datang kepada kita harus tetap teratur, karena kita tidak bisa sembarangan menghidupkan atau mematikan koneksi pelanggan – semuanya harus benar-benar konsisten. Langganan sebelumnya mempengaruhi langganan berikutnya, jadi datanya penting - tidak ada yang hilang.
keputusan. Anda dapat mencoba menyelesaikannya secara langsung dan bertanya kepada pengembang database, tetapi masalahnya tidak dapat diselesaikan secara matematis. Anda dapat mengingat teorema, hukum kekekalan, fisika kuantum, tetapi alasannya - hal ini tidak dapat diselesaikan di tingkat DB.
Pendekatan arsitektur lama yang baik berhasil di sini - Anda perlu mengetahui area subjek dengan baik dan menggunakannya untuk memecahkan teka-teki ini.
Solusi kami: membuat registri aplikasi terdistribusi di Tarantool - cluster yang terdistribusi secara geografis. Dalam diagram, ini adalah tiga pusat pemrosesan data yang berbeda - dua sebelum Ural, satu di luar Ural, dan kami mendistribusikan semua permintaan di antara pusat-pusat ini.
Netflix, yang kini dianggap sebagai salah satu pemimpin di bidang TI, hanya memiliki satu pusat data hingga tahun 2012. Menjelang Natal Katolik, 24 Desember, pusat data ini mati. Pengguna di Kanada dan Amerika dibiarkan tanpa film favorit mereka, sangat kecewa dan menulis tentang hal itu di jejaring sosial. Netflix kini memiliki tiga pusat data di pantai barat-timur dan satu di Eropa Barat.
Kami awalnya membangun solusi terdistribusi secara geografis - toleransi kesalahan penting bagi kami.
Jadi kita punya cluster, tapi bagaimana dengan RPO = 0 dan RTO = 0? Solusinya sederhana, tergantung subjeknya.
Apa yang penting dalam aplikasi? Dua Bagian: Melempar Keranjang UNTUK membuat keputusan pembelian, dan SETELAH. Bagian DO di telekomunikasi biasa disebut penangkapan pesanan или negosiasi pesanan. Di telekomunikasi, ini bisa jauh lebih sulit daripada di toko online, karena di sana klien harus dilayani, ditawarkan 5 pilihan, dan ini semua terjadi untuk beberapa waktu, tetapi keranjangnya terisi. Pada saat ini kegagalan mungkin saja terjadi, namun tidak menakutkan, karena terjadi secara interaktif di bawah pengawasan manusia.
Jika pusat data Moskow tiba-tiba mati, maka dengan beralih otomatis ke pusat data lain, kami akan terus bekerja. Secara teoritis, satu produk mungkin hilang di keranjang, tetapi Anda melihatnya, tambahkan ke keranjang lagi dan terus bekerja. Dalam hal ini RTO = 0.
Pada saat yang sama, ada opsi kedua: ketika kita mengklik “kirim”, kita ingin datanya tidak hilang. Mulai saat ini, otomatisasi mulai bekerja - ini adalah RPO = 0. Dengan menggunakan dua pola berbeda ini, dalam satu kasus ini bisa berupa cluster yang terdistribusi secara geografis dengan satu master yang dapat dialihkan, dalam kasus lain semacam catatan kuorum. Polanya mungkin berbeda, tapi kami memecahkan masalahnya.
Selanjutnya, dengan memiliki registri aplikasi yang terdistribusi, kami juga dapat menskalakan semuanya - memiliki banyak operator dan pelaksana yang mengakses registri ini.
Cassandra dan Tarantool bersama
Ada kasus lain - "pameran saldo". Berikut adalah kasus menarik dari penggunaan bersama Cassandra dan Tarantool.
Kami menggunakan Cassandra karena 2 miliar panggilan per hari bukanlah batasnya, dan akan ada lebih banyak lagi. Pemasar suka mewarnai lalu lintas berdasarkan sumber; misalnya, semakin banyak detail yang muncul di jejaring sosial. Itu semua menambah cerita.
Cassandra memungkinkan Anda menskalakan secara horizontal ke ukuran apa pun.
Kami merasa nyaman dengan Cassandra, tetapi ada satu masalah - ia tidak pandai membaca. Semuanya baik-baik saja dalam rekaman, 30 per detik tidak menjadi masalah - masalah membaca.
Oleh karena itu, topik dengan cache muncul, dan pada saat yang sama kami memecahkan masalah berikut: ada kasus tradisional lama ketika peralatan dari peralihan dari penagihan online masuk ke file yang kami muat ke Cassandra. Kami berjuang dengan masalah pengunduhan file-file ini yang dapat diandalkan, bahkan menggunakan saran dari manajer transfer file IBM - ada solusi yang mengelola transfer file secara efisien, menggunakan protokol UDP, misalnya, daripada TCP. Ini bagus, tapi ini masih beberapa menit, dan kami belum memuat semuanya, operator di pusat panggilan tidak dapat menjawab klien apa yang terjadi dengan saldonya - kami harus menunggu.
Untuk mencegah hal ini terjadi, kami kami menggunakan cadangan fungsional paralel. Saat kami mengirim acara melalui Kafka ke Tarantool, menghitung ulang agregat secara real time, misalnya untuk hari ini, kami mendapatkan saldo kas, yang bisa transfer saldo dengan kecepatan berapa pun, misalnya 100 ribu transaksi per detik dan 2 detik yang sama.
Tujuannya, setelah melakukan panggilan, dalam waktu 2 detik di akun pribadi Anda tidak hanya akan ada saldo yang diubah, tetapi juga informasi mengapa berubah.
Kesimpulan
Ini adalah contoh penggunaan Tarantool. Kami sangat menyukai keterbukaan Mail.ru dan kesediaannya untuk mempertimbangkan berbagai kasus.
Sudah sulit bagi konsultan dari BCG atau McKinsey, Accenture atau IBM untuk mengejutkan kami dengan sesuatu yang baru - sebagian besar dari apa yang mereka tawarkan, sudah kami lakukan, telah lakukan, atau rencanakan untuk kami lakukan. Saya pikir Tarantool akan mengambil tempat yang tepat dalam tumpukan teknologi kami dan akan menggantikan banyak teknologi yang ada. Kami sedang dalam fase aktif pengembangan proyek ini.
Laporan Oleg dan Andrey adalah salah satu yang terbaik di Konferensi Tarantool tahun lalu, dan pada 17 Juni Oleg Ivlev akan berbicara di dengan laporan . Alexander Deulin juga akan memberikan presentasi dari MegaFon . Mari kita cari tahu apa yang berubah, rencana apa yang telah dilaksanakan. Bergabunglah - konferensi ini gratis, yang perlu Anda lakukan hanyalah . semua dan program konferensi telah dibentuk: kasus baru, pengalaman baru dalam menggunakan Tarantool, arsitektur, perusahaan, tutorial, dan layanan mikro.
Sumber: www.habr.com