Hari baik!
Saya ingin berbagi dengan Anda kisah tentang penerapan cache pada basis data Tarantool dan fitur pekerjaan saya.
Saya bekerja sebagai pengembang Java di perusahaan telekomunikasi. Tugas utama: implementasi logika bisnis untuk platform yang dibeli perusahaan dari vendor. Dari fitur pertama, ini adalah pekerjaan sabun dan hampir tidak ada caching, kecuali dalam memori JVM. Semua ini tentu saja baik sampai jumlah instance aplikasi melebihi dua lusin ...
Dalam perjalanan kerja dan munculnya pemahaman tentang fitur platform, upaya dilakukan untuk melakukan caching. Pada saat itu, MongoDB sudah diluncurkan, dan sebagai hasilnya, kami tidak mendapatkan hasil positif khusus seperti dalam tes.
Dalam pencarian lebih lanjut untuk alternatif dan saran dari teman baik saya
mr_elzor , diputuskan untuk mencoba database Tarantool.
Dalam sebuah studi sepintas, hanya keraguan muncul di lua, karena saya belum menulis di atasnya dari kata "sepenuhnya." Tetapi menyingkirkan semua keraguan, dia mulai menginstal. Tentang jaringan tertutup dan firewall, saya pikir hanya sedikit orang yang tertarik, tetapi saya menyarankan Anda untuk mencoba menyiasatinya dan meletakkan semuanya dari sumber publik.
Server uji dengan konfigurasi: 8 Cpu, Ram 16 GB, HDD 100 Gb, Debian 9.4.
Instalasi sesuai dengan instruksi dari situs. Jadi saya mendapat opsi contoh. Idenya segera muncul dari antarmuka visual yang dengannya dukungan akan bekerja dengan nyaman. Selama pencarian cepat, saya menemukan dan mengkonfigurasi
tarantool-admin . Bekerja di Docker dan mencakup tugas dukungan 100%, setidaknya untuk saat ini.
Tapi mari kita bicara tentang yang lebih menarik.
Pikiran berikutnya adalah mengkonfigurasi versi saya di konfigurasi master - slave dalam server yang sama, karena dokumentasi hanya berisi contoh dengan dua server yang berbeda.
Setelah menghabiskan waktu untuk memahami lua dan menjelaskan konfigurasi, saya meluncurkan wizard.
Saya langsung jatuh pingsan dan tidak mengerti mengapa kesalahan itu terjadi, tetapi saya melihat bahwa itu ada dalam status "memuat".
Saya menjalankan slave:
Dan saya melihat kesalahan yang sama. Di sini, saya biasanya mulai tegang dan tidak mengerti apa yang terjadi, karena tidak ada dalam dokumentasi tentang hal itu sama sekali ... Tetapi ketika memeriksa statusnya, saya melihat bahwa itu tidak dimulai sama sekali, meskipun dikatakan bahwa statusnya "berjalan":
Tetapi pada saat yang sama, sang master mulai bekerja:
Memulai kembali budak tidak membantu. Saya bertanya-tanya mengapa?
Saya menghentikan tuan. Dan melakukan tindakan dalam urutan terbalik.
Saya melihat bahwa budak sedang mencoba untuk memulai.
Saya memulai wizard dan melihat bahwa wizard tidak naik dan umumnya beralih ke status yatim piatu, sementara budak umumnya jatuh.
Itu menjadi lebih menarik.
Saya melihat di log pada budak bahwa dia bahkan melihat master dan mencoba menyinkronkan.
2019-02-19 17:13:45.113 [20751] iproto/101/main D> binary: binding to 0.0.0.0:3302... 2019-02-19 17:13:45.113 [20751] iproto/101/main I> binary: bound to 0.0.0.0:3302 2019-02-19 17:13:45.113 [20751] iproto/101/main D> binary: listening on 0.0.0.0:3302... 2019-02-19 17:13:45.113 [20751] iproto D> cpipe_flush_cb: locking &endpoint->mutex 2019-02-19 17:13:45.113 [20751] iproto D> cpipe_flush_cb: unlocking &endpoint->mutex 2019-02-19 17:13:45.113 [20751] main D> cbus_endpoint_fetch: locking &endpoint->mutex 2019-02-19 17:13:45.113 [20751] main D> cbus_endpoint_fetch: unlocking &endpoint->mutex 2019-02-19 17:13:45.113 [20751] main/101/slave2 I> connecting to 1 replicas 2019-02-19 17:13:45.113 [20751] main/106/applier/replicator@tarantuldb-t D> => CONNECT 2019-02-19 17:13:45.114 [20751] main/106/applier/replicator@tarantuldb-t I> remote master 825af7c3-f8df-4db0-8559-a866b8310077 at 10.78.221.74:3301 running Tarantool 1.10.2 2019-02-19 17:13:45.114 [20751] main/106/applier/replicator@tarantuldb-t D> => CONNECTED 2019-02-19 17:13:45.114 [20751] main/101/slave2 I> connected to 1 replicas 2019-02-19 17:13:45.114 [20751] coio V> loading vylog 14 2019-02-19 17:13:45.114 [20751] coio V> done loading vylog 2019-02-19 17:13:45.114 [20751] main/101/slave2 I> recovery start 2019-02-19 17:13:45.114 [20751] main/101/slave2 I> recovering from `/var/lib/tarantool/cache_slave2/00000000000000000014.snap' 2019-02-19 17:13:45.114 [20751] main/101/slave2 D> memtx_tuple_new(47) = 0x7f99a4000080 2019-02-19 17:13:45.114 [20751] main/101/slave2 I> cluster uuid 4035b563-67f8-4e85-95cc-e03429f1fa4d 2019-02-19 17:13:45.114 [20751] main/101/slave2 D> memtx_tuple_new(11) = 0x7f99a4004080 2019-02-19 17:13:45.114 [20751] main/101/slave2 D> memtx_tuple_new(17) = 0x7f99a4008068
Dan upaya itu berhasil:
2019-02-19 17:13:45.118 [20751] main/101/slave2 D> memtx_tuple_new(40) = 0x7f99a40004c0 2019-02-19 17:13:45.118 [20751] main/101/slave2 I> assigned id 1 to replica 825af7c3-f8df-4db0-8559-a866b8310077 2019-02-19 17:13:45.118 [20751] main/101/slave2 D> memtx_tuple_new(40) = 0x7f99a4000500 2019-02-19 17:13:45.118 [20751] main/101/slave2 I> assigned id 2 to replica 403c0323-5a9b-480d-9e71-5ba22d4ccf1b 2019-02-19 17:13:45.118 [20751] main/101/slave2 I> recover from `/var/lib/tarantool/slave2/00000000000000000014.xlog' 2019-02-19 17:13:45.118 [20751] main/101/slave2 I> done `/var/lib/tarantool/slave2/00000000000000000014.xlog'
Itu bahkan dimulai:
2019-02-19 17:13:45.119 [20751] main/101/slave2 D> systemd: sending message 'STATUS=running'
Tetapi karena alasan yang tidak diketahui, ia kehilangan koneksi dan jatuh:
2019-02-19 17:13:45.129 [20751] main/101/slave2 D> SystemError at /build/tarantool-1.10.2.146/src/coio_task.c:416 2019-02-19 17:13:45.129 [20751] main/101/slave2 tarantoolctl:532 E> Start failed: /usr/local/share/lua/5.1/http/server.lua:1146: Can't create tcp_server: Input/output error
Mencoba memulai budak lagi tidak membantu.
Sekarang hapus file yang dibuat oleh instance. Dalam kasus saya, saya menghapus semuanya dari direktori / var / lib / tarantool.
Saya mulai menjadi budak pertama, dan baru kemudian menguasai. Dan lihatlah ...
Saya tidak menemukan penjelasan untuk perilaku ini, kecuali sebagai "fitur dari perangkat lunak ini."
Situasi ini akan muncul setiap kali jika server Anda telah sepenuhnya reboot.
Setelah analisis lebih lanjut dari arsitektur perangkat lunak ini, ternyata direncanakan untuk menggunakan hanya satu vCPU untuk satu contoh dan banyak lagi sumber daya tetap bebas.
Dalam ideologi n vCPU, kita dapat mengangkat master dan n-2 budak untuk membaca.
Mengingat bahwa pada server uji 8 vCPU kita dapat menaikkan master dan 6 instance untuk membaca.
Saya menyalin file untuk slave, memperbaiki port dan menjalankan, yaitu ditambahkan beberapa budak lagi.
Penting! Saat menambahkan contoh lain, Anda harus mendaftarkannya di wisaya.
Tetapi Anda harus terlebih dahulu memulai budak baru, dan baru kemudian restart master.
Contoh
Saya sudah memiliki konfigurasi yang berjalan dengan penyihir dan dua budak.
Saya memutuskan untuk menambahkan budak ketiga.
Saya mendaftarkannya di master dan me-restart master terlebih dahulu, dan ini yang saya lihat:
Yaitu tuan kita menjadi penyendiri, dan replikasi berantakan.
Memulai seorang budak baru tidak akan lagi membantu dan akan menghasilkan kesalahan:
Dan di log saya melihat entri informatif:
2019-02-20 09:20:10.616 [21601] main/101/slave4 I> bootstrapping replica from 3c77eb9d-2fa1-4a27-885f-e72defa5cd96 at 10.78.221.74:3301 2019-02-20 09:20:10.617 [21601] main/106/applier/replicator@tarantuldb-t I> can't join/subscribe 2019-02-20 09:20:10.617 [21601] main/106/applier/replicator@tarantuldb-t xrow.c:896 E> ER_READONLY: Can't modify data because this instance is in read-only mode. 2019-02-20 09:20:10.617 [21601] main/106/applier/replicator@tarantuldb-t D> => STOPPED 2019-02-20 09:20:10.617 [21601] main/101/slave4 xrow.c:896 E> ER_READONLY: Can't modify data because this instance is in read-only mode. 2019-02-20 09:20:10.617 [21601] main/101/slave4 F> can't initialize storage: Can't modify data because this instance is in read-only mode.
Kami menghentikan wizard dan memulai budak baru. Akan ada kesalahan, seperti pada awal pertama, tetapi kita akan melihat bahwa itu memuat status.
Tetapi ketika Anda memulai master, slave baru crash, dan master tidak berjalan dengan status running.
Dalam situasi ini, hanya ada satu jalan keluar. Seperti yang saya tulis sebelumnya, saya menghapus file yang dibuat oleh instance dan menjalankan slave terlebih dahulu, lalu master.
Semuanya dimulai dengan sukses.
Begitulah, melalui coba-coba, saya menemukan cara mengkonfigurasi dan memulai replikasi dengan benar.
Akibatnya, konfigurasi berikut ini dirakit:
2 server.
2 tuan. Cadangan panas.
12 budak. Semua aktif.Dalam logika tarantool, http.server digunakan
agar tidak
memblokir adaptor tambahan (ingat vendor, platform dan sabun) atau kencangkan perpustakaan untuk setiap proses bisnis.
Untuk menghindari perbedaan antara master, pada penyeimbang (NetScaler, HAProxy, atau lainnya favorit Anda), kami menetapkan aturan cadangan, mis. menyisipkan, memperbarui, menghapus operasi hanya pergi ke master aktif pertama.
Pada saat ini, yang kedua hanya mereplikasi catatan dari yang pertama. Budak sendiri terhubung ke master yang ditentukan pertama dari konfigurasi, yang merupakan apa yang kita butuhkan dalam situasi ini.
Pada lua, operasi CRUD diimplementasikan untuk nilai kunci. Saat ini, ini sudah cukup untuk menyelesaikan masalah.
Mengingat fitur bekerja dengan sabun, proses bisnis proxy diimplementasikan, di mana logika bekerja dengan tarantula via http diletakkan.
Jika data kunci ada, maka segera dikembalikan. Jika tidak, maka permintaan dikirim ke sistem master, dan disimpan dalam database Tarantool.
Akibatnya, satu proses bisnis dalam pengujian memproses hingga 4k permintaan. Dalam hal ini, waktu respons dari tarantula adalah ~ 1 ms. Waktu respons rata-rata hingga 3 ms.
Berikut ini beberapa informasi dari tes:
Ada 50 proses bisnis yang masuk ke 4 sistem master dan cache data dalam memori mereka. Duplikasi informasi dalam pertumbuhan penuh di setiap contoh. Mengingat bahwa java sudah menyukai memori ... prospeknya bukan yang terbaik.
Sekarang
50 proses bisnis meminta informasi melalui cache. Sekarang informasi dari 4 instance wizard disimpan di satu tempat, dan tidak di-cache di memori pada setiap instance. Dimungkinkan untuk secara signifikan mengurangi beban pada sistem master, tidak ada duplikat informasi, dan konsumsi memori pada contoh dengan logika bisnis telah menurun.
Contoh ukuran penyimpanan informasi dalam memori tarantula:
Pada akhirnya, angka-angka ini mungkin berlipat ganda, tetapi tidak ada "drawdown" dalam kinerja.
Dalam pertempuran, versi saat ini membuat permintaan 2k - 2.5k per detik dari beban nyata. Waktu respons rata-rata mirip dengan tes hingga 3 ms.
Jika Anda melihat htop di salah satu server dengan tarantool, kita akan melihat bahwa mereka "mendinginkan":
Ringkasan
Terlepas dari semua kehalusan dan nuansa basis data Tarantool, Anda dapat mencapai kinerja luar biasa.
Saya harap proyek ini akan berkembang dan saat-saat tidak nyaman ini akan diselesaikan.