Kita semua suka cerita. Kami suka duduk di sekeliling api dan bercakap tentang kemenangan, pertempuran, atau pengalaman kerja kami yang lalu.
Hari ini adalah hari seperti itu. Dan walaupun anda tidak berada dalam kebakaran sekarang, kami mempunyai cerita untuk anda. Kisah bagaimana kami mula bekerja dengan storan pada Tarantool.
Pada suatu masa dahulu, syarikat kami mempunyai beberapa "monolit" dan satu "siling" untuk semua, yang mana monolit ini perlahan-lahan tetapi pasti menghampiri, mengehadkan penerbangan syarikat kami, pembangunan kami. Dan terdapat pemahaman yang jelas: suatu hari nanti kita akan memukul siling ini dengan kuat.
Ia kini menjadi ideologi lazim untuk memisahkan segala-galanya dan semua orang, daripada peralatan kepada logik perniagaan. Akibatnya, kami, sebagai contoh, mempunyai dua DC yang boleh dikatakan bebas di peringkat rangkaian. Dan kemudian semuanya berbeza sama sekali.
Hari ini, terdapat banyak alat dan alatan untuk membuat perubahan dalam bentuk CI/CD, K8S, dsb. Dalam masa "monolitik", kita tidak memerlukan begitu banyak perkataan asing. Ia cukup untuk membetulkan "storan" dalam pangkalan data.
Tetapi masa bergerak ke hadapan, dan bilangan permintaan bergerak ke hadapan bersama-sama dengannya, kadangkala merakam RPS di luar kemampuan kami. Dengan kemasukan negara-negara CIS ke dalam pasaran, beban pada pemproses pangkalan data monolit pertama tidak jatuh di bawah 90%, dan RPS kekal pada tahap 2400. Dan ini bukan sahaja pemilih kecil, tetapi pertanyaan besar dengan sekumpulan semakan dan JOIN yang boleh dijalankan hampir separuh daripada data dengan latar belakang IO yang besar.
Apabila jualan Black Friday sepenuhnya mula muncul di tempat kejadian - dan Wildberries adalah salah satu yang pertama mengadakannya di Rusia - keadaan menjadi benar-benar menyedihkan. Lagipun, beban pada hari-hari sedemikian meningkat tiga kali ganda.
Oh, "zaman monolitik" ini! Saya pasti anda pernah mengalami sesuatu yang serupa, dan anda masih tidak faham bagaimana ini boleh berlaku kepada anda.
Apa yang boleh anda lakukan - fesyen adalah wujud dalam teknologi. Kira-kira 5 tahun yang lalu, kami terpaksa memikirkan semula salah satu mod ini dalam bentuk tapak sedia ada pada pelayan .NET dan MS SQL, yang menyimpan semua logik tapak itu sendiri dengan teliti. Saya menyimpannya dengan berhati-hati sehingga menggergaji monolit sedemikian ternyata menjadi kesenangan yang panjang dan tidak mudah.
Penyimpangan kecil.
Pada pelbagai acara saya berkata: "jika anda tidak melihat monolit, maka anda tidak berkembang!" Saya berminat dengan pendapat anda tentang perkara ini, sila tulis di dalam komen.
Bunyi Guruh
Mari kita kembali ke "api unggun" kita. Untuk mengagihkan beban fungsi "monolitik", kami memutuskan untuk membahagikan sistem kepada perkhidmatan mikro berdasarkan teknologi sumber terbuka. Kerana, sekurang-kurangnya, mereka lebih murah untuk skala. Dan kami mempunyai pemahaman 100% bahawa kami perlu membuat skala (dan banyak). Lagipun, pada masa itu adalah mungkin untuk memasuki pasaran negara jiran, dan bilangan pendaftaran, serta bilangan pesanan, mula berkembang dengan lebih kuat.
Setelah menganalisis calon pertama untuk berlepas daripada monolit kepada perkhidmatan mikro, kami menyedari bahawa 80% daripada penulisan di dalamnya datang daripada sistem pejabat belakang, dan bacaan dari pejabat hadapan. Pertama sekali, ini melibatkan beberapa subsistem penting untuk kami - data pengguna dan sistem untuk mengira kos akhir barangan berdasarkan maklumat tentang diskaun dan kupon pelanggan tambahan.
Inden. Kini ia menakutkan untuk dibayangkan, tetapi sebagai tambahan kepada subsistem yang dinyatakan di atas, katalog produk, troli beli-belah pengguna, sistem carian produk, sistem penapisan untuk katalog produk dan pelbagai jenis sistem pengesyoran turut dialih keluar daripada monolit kami. Untuk operasi setiap daripada mereka, terdapat kelas berasingan sistem yang disesuaikan secara sempit, tetapi pada suatu masa dahulu mereka semua tinggal di satu "rumah".
Kami segera merancang untuk memindahkan data tentang pelanggan kami ke sistem sharded. Penyingkiran fungsi untuk mengira kos akhir barangan memerlukan skalabiliti yang baik untuk membaca, kerana ia menghasilkan beban RPS yang paling besar dan merupakan yang paling sukar untuk dilaksanakan untuk pangkalan data (banyak data terlibat dalam proses pengiraan).
Hasilnya, kami menghasilkan skim yang sesuai dengan Tarantool.
Pada masa itu, untuk pengendalian perkhidmatan mikro, skema untuk bekerja dengan beberapa pusat data pada mesin maya dan perkakasan telah dipilih. Seperti yang ditunjukkan dalam rajah, pilihan replikasi Tarantool telah digunakan dalam kedua-dua mod tuan-tuan dan tuan-hamba.
Seni bina. Pilihan 1. Perkhidmatan pengguna
Pada masa semasa, terdapat 24 serpihan, setiap satunya mempunyai 2 kejadian (satu untuk setiap DC), semuanya dalam mod induk-induk.
Di atas pangkalan data adalah aplikasi yang mengakses replika pangkalan data. Aplikasi berfungsi dengan Tarantool melalui perpustakaan tersuai kami, yang melaksanakan antara muka pemacu Tarantool Go. Dia melihat semua replika dan boleh bekerja dengan tuan untuk membaca dan menulis. Pada asasnya, ia melaksanakan model set replika, yang menambah logik untuk memilih replika, melakukan percubaan semula, pemutus litar dan had kadar.
Dalam kes ini, adalah mungkin untuk mengkonfigurasi dasar pemilihan replika dalam konteks serpihan. Contohnya, roundrobin.
Seni bina. Pilihan 2. Perkhidmatan untuk mengira kos akhir barang
Beberapa bulan yang lalu, kebanyakan permintaan untuk mengira kos akhir barang pergi ke perkhidmatan baru, yang, pada dasarnya, berfungsi tanpa pangkalan data, tetapi beberapa waktu lalu semuanya telah diproses 100% oleh perkhidmatan dengan Tarantool di bawah tudung.
Pangkalan data perkhidmatan terdiri daripada 4 induk di mana penyegerak mengumpul data, dan setiap induk replikasi ini mengedarkan data kepada replika baca sahaja. Setiap tuan mempunyai kira-kira 15 replika sedemikian.
Sama ada dalam skema pertama atau kedua, jika satu DC tidak tersedia, aplikasi boleh menerima data dalam kedua.
Perlu diingat bahawa replikasi dalam Tarantool agak fleksibel dan boleh dikonfigurasikan semasa runtime. Dalam sistem lain, kesukaran timbul. Sebagai contoh, menukar parameter max_wal_senders dan max_replication_slots dalam PostgreSQL memerlukan permulaan semula wizard, yang dalam beberapa kes boleh menyebabkan terputusnya sambungan antara aplikasi dan DBMS.
Cari dan anda akan dapati!
Mengapa kita tidak melakukannya "seperti orang biasa", tetapi memilih cara yang tidak biasa? Ia bergantung kepada apa yang dianggap normal. Ramai orang biasanya membuat gugusan daripada Mongo dan menyebarkannya ke tiga DC yang diedarkan secara geo.
Pada masa itu, kami sudah mempunyai dua projek Redis. Yang pertama ialah cache, dan yang kedua ialah storan berterusan untuk data yang tidak terlalu kritikal. Ia agak sukar dengan dia, sebahagiannya kerana kesalahan kami. Kadang-kadang jumlah yang agak besar berada dalam kunci, dan dari semasa ke semasa tapak menjadi tidak sihat. Kami menggunakan sistem ini dalam versi tuan-hamba. Dan terdapat banyak kes di mana sesuatu berlaku kepada tuan dan replikasi rosak.
Iaitu, Redis adalah baik untuk tugas tanpa kewarganegaraan, bukan tugas kenegaraan. Pada dasarnya, ia membenarkan menyelesaikan kebanyakan masalah, tetapi hanya jika ia adalah penyelesaian nilai kunci dengan sepasang indeks. Tetapi Redis pada masa itu agak sedih dengan kegigihan dan replikasi. Di samping itu, terdapat aduan mengenai prestasi.
Kami memikirkan tentang MySQL dan PostgreSQL. Tetapi yang pertama entah bagaimana tidak sesuai dengan kami, dan yang kedua adalah produk yang agak canggih itu sendiri, dan tidak sesuai untuk membina perkhidmatan mudah di atasnya.
Kami mencuba RIAK, Cassandra, malah pangkalan data graf. Ini semua adalah penyelesaian yang agak khusus yang tidak sesuai untuk peranan alat universal umum untuk mencipta perkhidmatan.
Akhirnya kami menetap di Tarantool.
Kami beralih kepadanya apabila ia berada dalam versi 1.6. Kami berminat dengannya dengan simbiosis nilai kunci dan kefungsian pangkalan data hubungan. Terdapat indeks sekunder, urus niaga dan ruang, ini seperti jadual, tetapi tidak mudah, anda boleh menyimpan bilangan lajur yang berbeza di dalamnya. Tetapi ciri pembunuh Tarantool ialah indeks sekunder yang digabungkan dengan nilai kunci dan transaksi.
Komuniti berbahasa Rusia yang responsif, sedia membantu dalam sembang, turut memainkan peranan. Kami secara aktif menggunakan ini dan hidup secara langsung dalam sembang. Dan jangan lupa tentang berterusan yang baik tanpa kesilapan dan kesilapan yang jelas. Jika anda melihat sejarah kami dengan Tarantool, kami mengalami banyak kesakitan dan kegagalan dengan replikasi, tetapi kami tidak pernah kehilangan data kerana kesalahannya!
Perlaksanaan bermula dengan kasar
Pada masa itu, timbunan pembangunan utama kami ialah .NET, yang tiada penyambung untuk Tarantool. Kami segera mula melakukan sesuatu dalam Go. Ia juga berfungsi dengan baik dengan Lua. Masalah utama pada masa itu ialah dengan penyahpepijatan: dalam .NET semuanya hebat dengan ini, tetapi selepas itu sukar untuk terjun ke dunia Lua terbenam, apabila anda tidak mempunyai penyahpepijatan kecuali log. Di samping itu, atas sebab tertentu replikasi secara berkala runtuh, jadi saya terpaksa menyelidiki struktur enjin Tarantool. Sembang membantu dengan ini, dan pada tahap yang lebih rendah, dokumentasi; kadangkala kami melihat kod. Pada masa itu, dokumentasi adalah begitu-begitu.
Jadi, dalam tempoh beberapa bulan, saya berjaya mendapatkan fikiran saya dan mendapat hasil yang baik daripada bekerja dengan Tarantool. Kami menyusun perkembangan rujukan dalam git yang membantu dengan pembentukan perkhidmatan mikro baharu. Sebagai contoh, apabila tugas timbul: untuk mencipta perkhidmatan mikro lain, pembangun melihat kod sumber penyelesaian rujukan dalam repositori, dan ia mengambil masa tidak lebih daripada seminggu untuk mencipta yang baharu.
Ini adalah masa yang istimewa. Secara konvensional, anda boleh pergi ke pentadbir di meja sebelah dan bertanya: "Beri saya mesin maya." Kira-kira tiga puluh minit kemudian kereta itu sudah ada bersama awak. Anda menyambungkan diri anda, memasang segala-galanya dan lalu lintas telah dihantar kepada anda.
Hari ini ini tidak akan berfungsi lagi: anda perlu menambah pemantauan dan pengelogan ke perkhidmatan, menutup fungsi dengan ujian, memesan mesin maya atau penghantaran ke Kuber, dsb. Secara umum, ia akan menjadi lebih baik dengan cara ini, walaupun ia akan mengambil masa yang lebih lama dan lebih menyusahkan.
Bahagikan dan perintah. Apa urusan dengan Lua?
Terdapat dilema yang serius: sesetengah pasukan tidak dapat melancarkan perubahan pada perkhidmatan dengan banyak logik dalam Lua dengan pasti. Ini sering disertai dengan perkhidmatan yang tidak berfungsi.
Iaitu, pemaju sedang menyediakan beberapa jenis perubahan. Tarantool mula melakukan penghijrahan, tetapi replika masih dengan kod lama; Beberapa DDL atau sesuatu yang lain tiba di sana melalui replikasi, dan kod itu hanya runtuh kerana ia tidak diambil kira. Akibatnya, prosedur kemas kini untuk pentadbir telah dibentangkan pada helaian A4: hentikan replikasi, kemas kini ini, hidupkan replikasi, matikan di sini, kemas kini di sana. Mimpi ngeri!
Akibatnya, kini kami paling kerap cuba untuk tidak melakukan apa-apa di Lua. Hanya gunakan iproto (protokol binari untuk berinteraksi dengan pelayan), dan itu sahaja. Mungkin ini adalah kekurangan pengetahuan di kalangan pemaju, tetapi dari sudut pandangan ini sistem adalah kompleks.
Kami tidak selalu mengikuti skrip ini secara membabi buta. Hari ini kita tidak mempunyai hitam dan putih: sama ada semuanya ada dalam Lua, atau semuanya ada dalam Go. Kami sudah faham bagaimana kami boleh menggabungkannya supaya kami tidak menghadapi masalah penghijrahan nanti.
Di manakah Tarantool sekarang?
Tarantool digunakan dalam perkhidmatan untuk mengira kos akhir barangan dengan mengambil kira kupon diskaun, juga dikenali sebagai "Promoter". Seperti yang saya katakan sebelum ini, dia kini bersara: dia digantikan dengan perkhidmatan katalog baharu dengan harga pra-kiraan, tetapi enam bulan lalu semua pengiraan dibuat dalam Promotizer. Sebelum ini, separuh daripada logiknya ditulis dalam Lua. Dua tahun lalu, perkhidmatan itu telah bertukar menjadi kemudahan storan, dan logiknya telah ditulis semula dalam Go, kerana mekanik diskaun telah berubah sedikit dan perkhidmatan itu tidak mempunyai prestasi.
Salah satu perkhidmatan yang paling kritikal ialah profil pengguna. Iaitu, semua pengguna Wildberries disimpan dalam Tarantool, dan terdapat kira-kira 50 juta daripadanya. Sistem yang dipecahkan oleh ID pengguna, diedarkan merentasi beberapa DC yang disambungkan ke perkhidmatan Go.
Menurut RPS, Promoter pernah menjadi ketua, mencapai 6 ribu permintaan. Pada satu ketika kami mempunyai 50-60 salinan. Kini peneraju dalam RPS ialah profil pengguna, kira-kira 12 ribu. Perkhidmatan ini menggunakan sharding tersuai, dibahagikan dengan julat ID pengguna. Perkhidmatan ini menyediakan lebih daripada 20 mesin, tetapi ini terlalu banyak; kami merancang untuk mengurangkan sumber yang diperuntukkan, kerana kapasiti 4-5 mesin sudah cukup untuknya.
Perkhidmatan sesi adalah perkhidmatan pertama kami pada vshard dan Cartridge. Menyediakan vshard dan mengemas kini Kartrij memerlukan sedikit usaha daripada kami, tetapi akhirnya semuanya berjaya.
Perkhidmatan untuk memaparkan sepanduk yang berbeza di laman web dan dalam aplikasi mudah alih adalah salah satu yang pertama dikeluarkan secara langsung di Tarantool. Perkhidmatan ini terkenal kerana ia berusia 6-7 tahun, ia masih beroperasi dan tidak pernah dibut semula. Replikasi master-master telah digunakan. Tiada yang pernah pecah.
Terdapat contoh menggunakan Tarantool untuk fungsi rujukan pantas dalam sistem gudang untuk menyemak semula maklumat dengan cepat dalam beberapa kes. Kami cuba menggunakan Redis untuk ini, tetapi data dalam memori mengambil lebih banyak ruang daripada Tarantool.
Perkhidmatan senarai menunggu, langganan pelanggan, cerita terkini dan barangan tertunda juga berfungsi dengan Tarantool. Perkhidmatan terakhir dalam memori mengambil masa kira-kira 120 GB. Ini adalah perkhidmatan yang paling komprehensif di atas.
Kesimpulan
Terima kasih kepada indeks sekunder yang digabungkan dengan nilai kunci dan transaksi, Tarantool sangat sesuai untuk seni bina berasaskan perkhidmatan mikro. Walau bagaimanapun, kami menghadapi kesukaran apabila melancarkan perubahan pada perkhidmatan dengan banyak logik dalam Lua - perkhidmatan sering berhenti berfungsi. Kami tidak dapat mengatasi perkara ini, dan lama-kelamaan kami sampai kepada gabungan Lua dan Go yang berbeza: kami tahu di mana untuk menggunakan satu bahasa dan di mana untuk menggunakan bahasa yang lain.
Apa lagi yang perlu dibaca mengenai topik tersebut
- Mencipta aplikasi beban tinggi dari awal menggunakan Tarantool
- Pilihan pemimpin yang dipercayai dalam Tarantool Cartridge
- Saluran Telegram Tarantool dengan berita tentang produk
- Bincangkan Tarantool dalam sembang komuniti
Sumber: www.habr.com