👨‍🎓 🕙 🌔 Bagaimana kami di Sportmaster memilih sistem caching. Bagian 1 🎍 👨🏽‍🎓 🐳

Halo! Nama saya Alexey Pyankov, saya seorang pengembang di Sportmaster. Dalam posting ini saya berbicara tentang bagaimana kerja di situs web Sportmaster dimulai pada 2012, inisiatif apa yang berhasil kami lakukan, dan sebaliknya, penggaruk mana yang kami kumpulkan.

Hari ini saya ingin berbagi pemikiran yang mengikuti cerita lain - memilih sistem caching untuk java backend di panel admin situs. Plot ini sangat penting bagi saya - meskipun ceritanya hanya berlangsung 2 bulan, tetapi 60 hari ini kami bekerja selama 12-16 jam dan tanpa hari libur. Saya tidak pernah berpikir dan membayangkan bahwa Anda dapat bekerja begitu banyak.

Karena itu, saya memecah teks menjadi 2 bagian, agar tidak mengunduh secara penuh. Sebaliknya, bagian pertama akan sangat mudah - persiapan, pengenalan, beberapa pertimbangan tentang apa itu caching. Jika Anda sudah menjadi pengembang yang berpengalaman atau telah bekerja dengan cache - dari sisi teknis, kemungkinan besar tidak ada yang baru dalam artikel ini. Tetapi bagi seorang junior, ulasan kecil semacam itu bisa menentukan arah mana yang harus dilihat, jika dia menemukan dirinya di persimpangan jalan.

Ketika versi baru situs web Sportmaster diluncurkan dalam produksi, data datang dengan cara, dengan kata lain, tidak terlalu nyaman. Dasarnya adalah tabel yang disiapkan untuk versi situs sebelumnya (Bitrix), yang harus diperketat di ETL, dibawa ke tampilan baru dan diperkaya dengan hal-hal kecil yang berbeda dari selusin sistem. Agar gambar atau deskripsi produk baru muncul di situs, Anda harus menunggu hingga hari berikutnya - hanya memperbarui di malam hari, 1 kali per hari.

Pada awalnya, ada begitu banyak kekhawatiran dari minggu-minggu pertama masuk ke dalam produksi sehingga ketidaknyamanan bagi manajer konten adalah hal yang remeh. Tetapi, segera setelah semuanya beres, pengembangan proyek berlanjut - beberapa bulan kemudian, pada awal 2015, kami mulai aktif mengembangkan panel admin. Pada 2015 dan 2016, semuanya berjalan dengan baik, kami akan merilisnya secara teratur, area admin mencakup sebagian besar persiapan data, dan kami sedang mempersiapkan fakta bahwa segera hal yang paling penting dan sulit akan dipercayakan kepada tim kami - lini produk (persiapan lengkap dan pemeliharaan data untuk semua produk). Tetapi pada musim panas 2017, tepat sebelum peluncuran lini produk, proyek ini akan berada dalam situasi yang sangat sulit - justru karena masalah caching. Saya ingin berbicara tentang episode ini di bagian kedua dari publikasi dua bagian ini.

Tetapi dalam posting ini saya akan mulai dari jauh, seperti beberapa pemikiran - ide tentang caching, yang akan bergulir sebelum proyek besar sebelumnya akan menjadi langkah yang baik.

Ketika tugas cache muncul

Tugas caching tidak hanya muncul. Kami adalah pengembang, kami menulis produk perangkat lunak dan kami ingin itu menjadi permintaan. Jika produk dalam permintaan dan sukses, pengguna tiba. Dan lebih banyak datang dan lebih banyak lagi. Jadi ada banyak pengguna dan kemudian produk menjadi sangat sarat.

Pada tahap pertama, kami tidak memikirkan pengoptimalan dan kinerja kode. Hal utama adalah fungsionalitas, dengan cepat meluncurkan pilot dan menguji hipotesis. Dan jika beban bertambah, kami memompa besi. Kami meningkatkannya dengan faktor dua, tiga, lima, biarkan 10 kali lipat. Di suatu tempat di sini - keuangan tidak lagi memungkinkan. Dan berapa kali jumlah pengguna akan bertambah? Ini tidak hanya 2-5-10, tetapi jika berhasil, akan dari 100-1000 dan hingga 100 ribu kali. Yaitu, cepat atau lambat, tetapi harus melakukan optimasi.

Katakanlah beberapa bagian dari kode (sebut saja bagian ini fungsi) bekerja tidak sopan untuk waktu yang lama, dan kami ingin mengurangi waktu eksekusi. Fungsi - bisa berupa akses ke database, bisa jadi merupakan eksekusi dari beberapa logika yang kompleks - yang utama adalah membutuhkan waktu yang lama. Seberapa banyak Anda bisa mengurangi waktu tunggu? Dalam batas - dapat dikurangi menjadi nol, tidak ada lagi. Dan bagaimana Anda bisa mengurangi runtime menjadi nol? Jawaban: umumnya tidak termasuk eksekusi. Sebagai gantinya, segera kembalikan hasilnya. Dan bagaimana Anda tahu hasilnya? Jawab: hitung, atau lihat ke suatu tempat. Menghitung adalah waktu yang lama. Dan untuk mengintip, misalnya, untuk mengingat hasil bahwa fungsi yang dihasilkan terakhir kali ketika dipanggil dengan parameter yang sama.

Artinya, implementasi fungsi tidak masalah bagi kami. Cukup mengetahui parameter apa yang bergantung pada hasil. Kemudian, jika nilai parameter disajikan dalam bentuk objek yang dapat digunakan sebagai kunci dalam beberapa penyimpanan, maka kita dapat menyimpan hasil perhitungan dan membacanya di waktu berikutnya. Jika hasil baca-tulis ini lebih cepat daripada menjalankan fungsi, kami memiliki keuntungan dalam kecepatan. Nilai keuntungan dapat mencapai 100, 1000, dan 100 ribu kali (10 ^ 5 lebih merupakan pengecualian, tetapi dalam kasus basis lag yang layak sangat mungkin).

Persyaratan Caching Utama

Hal pertama yang dapat menjadi persyaratan untuk sistem caching adalah kecepatan baca yang cepat dan, pada tingkat yang sedikit lebih rendah, kecepatan menulis. Ini benar, tetapi hanya sampai kita meluncurkan sistem dalam produksi.

Mari kita mainkan kasus seperti itu.

Misalkan kita menyediakan beban saat ini dengan besi dan sekarang kita secara bertahap memperkenalkan caching. Pengguna tumbuh sedikit, beban bertambah - kami menambahkan sedikit cache, kami kencangkan di sana-sini. Ini telah berlangsung selama beberapa waktu, dan sekarang fungsi-fungsi berat praktis tidak dipanggil - semua beban utama jatuh pada cache. Jumlah pengguna selama ini telah bertambah N kali.

Dan jika pasokan awal besi bisa 2-5 kali, maka dengan bantuan cache kita dapat mengencangkan produktivitas setiap 10 atau, dalam kasus yang baik, 100 kali, di beberapa tempat, mungkin 1000. Artinya, kami memproses pada besi yang sama Permintaan 100 kali lebih banyak. Hebat, layak mendapatkan jahe!

Tapi sekarang, pada satu titik, secara tidak sengaja, sistem crash dan cache crash. Tidak ada yang istimewa - lagipula, cache dipilih berdasarkan permintaan "membaca dan menulis dengan kecepatan tinggi, sisanya tidak masalah."

Mengenai beban awal, cadangan besi adalah 2-5 kali, dan beban selama ini tumbuh 10-100 kali. Dengan bantuan cache, kami menghilangkan panggilan untuk fungsi-fungsi berat dan karenanya semuanya terbang. Dan sekarang, tanpa cache - berapa kali sistem kami melorot? Apa yang akan terjadi pada kita? Sistem akan jatuh.

Bahkan jika cache kita tidak macet, tetapi hanya dihapus untuk sementara waktu, itu perlu dipanaskan, dan ini akan memakan waktu. Dan saat ini - beban utama akan jatuh pada fungsional.

Kesimpulan: proyek-proyek beban tinggi dalam produk memerlukan dari sistem caching tidak hanya kecepatan tinggi membaca dan menulis, tetapi juga keamanan data dan ketahanan terhadap kegagalan.

Pilihan tepung

Dalam proyek dengan panel admin, pilihannya seperti ini: pertama mereka menaruh Hazelcast, karena sudah terbiasa dengan produk ini dari pengalaman situs utama. Tapi, di sini pilihan ini tidak berhasil - untuk profil beban kami, Hazelcast bekerja tidak hanya secara perlahan, tetapi juga sangat lambat. Dan pada saat itu, kami sudah mendaftar untuk ketentuan penarikan ke prod.

Spoiler: bagaimana tepatnya keadaan muncul sehingga kita melewatkan kesulitan seperti itu dan mendapat situasi yang akut dan tegang - saya akan ceritakan pada bagian kedua - dan bagaimana kita berubah dan bagaimana kita keluar. Tapi sekarang - saya hanya akan mengatakan bahwa itu sangat stres, dan "berpikir - entah bagaimana saya tidak berpikir, kocok botolnya." "Mengocok botol" juga spoiler, tentang ini sedikit lebih jauh.

Apa yang telah kita lakukan:

Kami membuat daftar semua sistem yang diminta oleh google dan StackOverflow. Sedikit di atas 30
, . , - — , .
, , , . , – , .
17- , . « », .

Tapi ini adalah opsi ketika Anda harus memilih sistem yang "merangkak dalam kecepatan" dalam tes yang disiapkan sebelumnya. Dan jika belum ada tes seperti itu dan ingin memilih lebih cepat?

Kami akan mensimulasikan opsi seperti itu (sulit untuk membayangkan bahwa pengembang menengah + hidup dalam ruang hampa, dan pada saat pemilihan ia belum memutuskan produk mana yang akan dicoba di tempat pertama - karena itu, diskusi lebih lanjut lebih mungkin adalah ahli teori / filosofi / tentang seorang junior).

Setelah menentukan persyaratan, kami akan mulai memilih solusi dari kotak. Mengapa menemukan kembali roda: kami akan pergi dan mengambil sistem caching yang sudah jadi.

Jika Anda baru memulai dan Anda akan google, maka plus atau minus pesanan, tetapi secara umum, pedoman akan seperti itu. Pertama-tama, Anda menemukan Redis, itu didengar di mana-mana. Maka Anda akan menemukan bahwa ada EhCache sebagai sistem tertua dan paling terbukti. Kemudian akan ditulis tentang Tarantool - sebuah pembangunan domestik di mana ada aspek unik dari solusi. Dan juga Ignite, karena sekarang sedang naik popularitas dan menikmati dukungan dari SberTech. Pada akhirnya, ada Hazelcast, karena di dunia perusahaan sering muncul di tengah-tengah perusahaan besar.

Daftar ini tidak berakhir di sana, ada lusinan sistem. Dan kami hanya mengacaukan satu. Ambil 5 sistem yang dipilih untuk "kontes kecantikan" dan lakukan seleksi. Siapa yang akan menjadi pemenang?

Redis

Kami membaca apa yang mereka tulis di situs web resmi.
Redis adalah proyek sumber terbuka. Ini menawarkan penyimpanan data dalam memori, kemampuan untuk menyimpan pada disk, partisi otomatis ke dalam partisi, ketersediaan tinggi dan pemulihan dari jeda jaringan.

Tampaknya semuanya baik-baik saja, Anda dapat mengambilnya dan mengacaukannya - semua yang ia butuhkan adalah apa yang ia lakukan. Tapi mari kita cari demi minat pada kandidat lain.

Ehcache

EhCache - “cache yang paling banyak digunakan untuk Java” (terjemahan slogan dari situs resmi). Juga opensource. Dan di sini kita memahami bahwa Redis bukan di bawah java, tetapi umum, dan untuk berinteraksi dengannya, Anda memerlukan pembungkus. Dan EhCache akan lebih nyaman. Apa lagi yang dijanjikan sistem? Keandalan, ketelitian, fungsionalitas penuh. Ya, dan dia yang paling umum. Dan cache data terabyte.

Redis dilupakan, saya siap untuk memilih EhCache.

Tetapi rasa patriotisme mendorong saya untuk melihat apa yang membuat Tarantool baik.

Tarantool

Tarantool - Memenuhi penunjukan "Platform Integrasi Data Real-time." Kedengarannya sangat sulit, jadi kami membaca halaman itu secara mendetail dan menemukan pernyataan yang keras: "Tembolok 100% data dalam RAM." Ini seharusnya menimbulkan pertanyaan - lagipula, mungkin ada lebih banyak data daripada memori. Dekripsi adalah bahwa di sini tersirat bahwa Tarantool tidak menjalankan serialisasi untuk menulis data ke disk dari memori. Sebagai gantinya, ia menggunakan fitur tingkat rendah dari sistem ketika memori hanya memetakan ke sistem file dengan kinerja I / O yang sangat baik. Secara umum, mereka melakukannya dengan indah dan keren.

Mari kita lihat implementasinya: jalan raya korporat Mail.ru, Avito, Beeline, Megafon, Alfa-Bank, Gazprom ...

Jika masih ada keraguan tentang Tarantool, maka pengenalan implementasi Mastercard akan membunuh saya. Saya mengambil Tarantool.

Tapi bagaimanapun juga ...

Menyalakan

... ada Ignite , yang dinyatakan sebagai "platform komputasi dalam memori ... kecepatan dalam memori pada petabyte data." Ada juga banyak keuntungan: cache dalam-memori terdistribusi, penyimpanan nilai-kunci tercepat dan cache, penskalaan horizontal, ketersediaan tinggi, integritas yang ketat. Secara umum, ternyata yang tercepat adalah Ignite.

Implementasi: Sberbank, American Airlines, Yahoo! Jepang Dan kemudian saya masih menemukan bahwa Ignite tidak hanya diterapkan di Sberbank, tetapi tim SberTech mengirimkan orang-orangnya ke tim Ignite untuk menyelesaikan produk. Ini benar-benar menawan dan saya siap untuk mengambil Ignite.

Benar-benar tidak bisa dipahami mengapa, saya melihat poin kelima.

Siaran Hazel

Saya pergi ke situs web Hazelcast , membacanya. Dan ternyata solusi tercepat untuk caching terdistribusi adalah Hazelcast. Dia adalah urutan besarnya lebih cepat dari semua solusi lain dan secara umum dia adalah pemimpin di bidang kisi data di memori. Terhadap latar belakang ini, ambil yang lain - jangan menghargai diri sendiri. Ini juga menggunakan penyimpanan data yang berlebihan untuk operasi berkelanjutan dari cluster tanpa kehilangan data.

Semuanya, saya siap untuk mengambil Hazelcast.

Perbandingan

Tetapi jika Anda melihat, maka kelima kandidat itu begitu dicat sehingga masing-masing dari mereka adalah yang terbaik. Bagaimana memilih? Kita bisa melihat mana yang paling populer, mencari perbandingan, dan sakit kepala akan berlalu.

Kami menemukan seperti tinjauan , memilih 5 sistem kami.

Di sini mereka disortir: di puncak Redis, di tempat kedua adalah Hazelcast, Tarantool dan Ignite mendapatkan popularitas, EhCache telah dan tetap ada.

Tapi mari kita lihat metode perhitungan : tautan ke situs web, minat umum pada sistem, tawaran pekerjaan - hebat! Yaitu, ketika sistem saya jatuh, saya akan mengatakan: “Tidak, itu dapat diandalkan! Berikut ini banyak tawaran pekerjaan ... ". Perbandingan sederhana seperti itu tidak akan berhasil.

Semua sistem ini bukan hanya sistem caching. Mereka masih memiliki banyak fungsi, termasuk ketika bukan data yang ditransfer ke klien untuk diproses, melainkan: kode yang perlu dijalankan pada data yang dipindahkan ke server, dieksekusi di sana, dan hasilnya dikembalikan. Dan sebagai sistem terpisah untuk caching, mereka tidak begitu sering dipertimbangkan.

Yah, jangan menyerah, kami menemukan perbandingan langsung sistem. Ambil dua opsi teratas - Redis dan Hazelcast. Kami tertarik pada kecepatan, kami dapat membandingkannya dengan parameter ini.

Hz vs Redis

Kami menemukan perbandingan seperti itu :

Biru adalah Redis, merah adalah Hazelcast. Hazelcast menang di mana-mana, dan alasannya diberikan: ini multi-utas, sangat dioptimalkan, setiap utas bekerja dengan partisi sendiri, sehingga tidak ada kunci. Dan Redis adalah single-threaded, tidak mengambil keuntungan dari CPU multi-core modern. Hazelcast memiliki I / O yang tidak sinkron, Redis-Jedis memiliki soket pemblokir. Pada akhirnya, Hazelcast menggunakan protokol biner, sedangkan Redis berorientasi teks, artinya tidak efisien.

Untuk berjaga-jaga, kami beralih ke sumber perbandingan lain. Apa yang akan dia tunjukkan pada kita?

Redis vs Hz

Perbandingan lain :

Di sini, sebaliknya, merah adalah Redis. Artinya, Redis mengungguli Hazelcast dalam kinerja. Dalam perbandingan pertama, Hazelcast menang, di yang kedua - Redis. Di sini, mereka menjelaskan dengan sangat tepat mengapa Hazelcast menang dalam perbandingan sebelumnya.

Ternyata hasil yang pertama benar-benar dicurangi: Redis diambil di kotak dasar, dan Hazelcast dipenjara karena kasus uji. Kemudian ternyata: pertama, tidak ada yang bisa dipercaya, dan kedua, ketika kita memilih suatu sistem, kita masih perlu mengkonfigurasinya dengan benar. Pengaturan ini mencakup lusinan, hampir ratusan parameter.

Mengocok botol

Dan seluruh proses yang baru saja kita lakukan, saya dapat menjelaskan dengan metafora seperti itu, "Kocok botolnya." Artinya, sekarang Anda tidak bisa memprogram, sekarang yang utama adalah bisa membaca stackoverflow. Dan di tim saya ada seseorang, seorang profesional, yang bekerja begitu saja pada saat-saat kritis.

Apa yang dia lakukan? Dia melihat sesuatu yang rusak, melihat jejak tumpukan, mengambil beberapa kata-katanya (yang keahliannya dalam program), mencari di Google, menemukan stackoverflow di antara jawaban. Tanpa membaca, tanpa berpikir, di antara jawaban atas pertanyaan - ia memilih sesuatu yang paling mirip dengan kalimat "lakukan ini dan itu" (memilih jawaban seperti itu adalah bakatnya, karena tidak selalu jawaban yang mengumpulkan lebih banyak suka), ia menggunakan , terlihat: jika ada sesuatu yang berubah, maka baik-baik saja. Jika belum berubah, kami akan mundur. Dan kami ulangi mulai-periksa-cari. Dan dengan cara yang sangat intuitif, ia mencapai hal itu setelah beberapa waktu kodenya bekerja. Dia tidak tahu mengapa, dia tidak tahu apa yang telah dia lakukan, dia tidak bisa menjelaskan. Tapi! Infeksi ini berhasil. Dan "api padam." Sekarang kita mengerti apa yang telah kita lakukan. Ketika program bekerja, itu jauh lebih mudah.Dan secara signifikan menghemat waktu.

Metode ini dijelaskan dengan sangat baik dengan contoh seperti itu.

Dulu sangat populer untuk mengumpulkan perahu layar dalam botol. Pada saat yang sama, perahu layar itu besar dan rapuh, dan leher botolnya sangat sempit, Anda tidak bisa mendorongnya ke dalam. Bagaimana cara merakitnya?

Ada metode seperti itu, sangat cepat dan sangat efektif.

Kapal itu terdiri dari banyak hal kecil: tongkat, tali, layar, lem. Kami memasukkan semua ini ke dalam botol.
Kami mengambil botol dengan kedua tangan dan mulai gemetaran. Kami gemetaran, gemetar. Dan biasanya - Anda mendapatkan sampah lengkap, tentu saja. Tapi terkadang. Terkadang Anda mendapat kapal! Lebih tepatnya, sesuatu yang mirip dengan kapal.

Kami menunjukkan ini kepada seseorang: "Serge, lihat!?". Dan memang, dari jauh - seolah-olah sebuah kapal. Tapi kemudian Anda tidak bisa membiarkan ini pergi.

Ada cara lain. Orang-orang menggunakan yang lebih maju, peretas seperti itu.

Memberi orang itu tugas, dia melakukan segalanya dan pergi. Dan Anda melihat - tampaknya harus dilakukan. Dan setelah beberapa saat, ketika perlu untuk memperbaiki kode - itu mulai karena itu ... Ada baiknya dia sudah berhasil lari jauh. Ini adalah orang-orang yang, menggunakan contoh botol, akan melakukan ini: Anda tahu, di mana bagian bawahnya - belokan kaca. Dan tidak sepenuhnya jelas apakah itu transparan atau tidak. Kemudian "peretas" memotong bagian bawah ini, masukkan kapal di sana, lalu tempel bagian bawah lagi, dan seolah-olah diperlukan.

Dari sudut pandang pengaturan masalah, semuanya tampak benar. Tapi ini adalah contoh kapal: mengapa kapal ini secara umum, siapa yang membutuhkannya? Itu tidak membawa fungsi apa pun. Biasanya kapal semacam itu adalah hadiah bagi orang-orang berpangkat tinggi yang menaruhnya di rak di atas diri mereka, sebagai semacam simbol, sebagai tanda. Dan sekarang, jika orang seperti itu, kepala bisnis besar atau pejabat tinggi, bagaimana bendera itu berdiri seperti sampah, di mana lehernya dipotong? Akan lebih baik jika dia tidak pernah tahu tentang itu. Jadi, bagaimana kapal-kapal ini akhirnya dibuat yang bisa disajikan kepada orang penting?

Satu-satunya tempat, kunci, yang benar-benar tidak ada yang bisa dilakukan, adalah bangunan. Dan lambung kapal hanya melewati leher. Padahal kapal itu keluar dari botol. Tapi itu bukan hanya untuk merakit kapal, itu adalah kerajinan perhiasan asli. Tuas khusus ditambahkan ke komponen, yang memungkinkan mereka untuk diangkat kemudian. Sebagai contoh, layar dilipat, dengan lembut melayang masuk, dan kemudian dengan bantuan penjepit itu adalah perhiasan, yang pasti, mereka ditarik dan diangkat. Hasilnya adalah sebuah karya seni yang dapat disajikan dengan hati nurani dan kebanggaan yang jelas.

Dan jika kita ingin proyek itu berhasil, harus ada setidaknya satu perhiasan di tim. Siapa pun yang peduli dengan kualitas produk dan memperhitungkan semua aspek, tanpa mengorbankan satu pun, bahkan di saat-saat stres, ketika keadaan memerlukan hal yang mendesak sehingga merugikan yang penting. Semua proyek sukses yang berkelanjutan, yang telah teruji oleh waktu, dibangun berdasarkan prinsip ini. Mereka memiliki sesuatu yang sangat tepat dan unik, sesuatu yang menggunakan semua fitur yang tersedia. Dalam contoh kapal dalam botol, dimainkan bahwa lambung kapal melewati leher.

Kembali ke tugas memilih server caching kami, bagaimana metode ini dapat diterapkan? Saya mengusulkan opsi seperti itu dari semua sistem yang ada - jangan kocok botolnya, jangan pilih, tetapi lihat apa, pada prinsipnya, mereka memiliki sesuatu yang harus dicari ketika memilih suatu sistem.

Tempat mencari leher botol

Mari kita coba untuk tidak mengguncang botol, untuk tidak memilah-milah segala sesuatu yang pada gilirannya, tapi mari kita lihat tugas apa yang muncul, jika tiba-tiba, untuk tugas Anda - untuk merancang sistem seperti itu sendiri. Tentu saja, kami tidak akan merakit sepeda, tetapi kami akan menggunakan skema ini untuk mengarahkan diri sendiri pada poin apa yang harus diperhatikan dalam deskripsi produk. Kami menguraikan skema seperti itu.

Jika sistem terdistribusi, maka kami akan memiliki beberapa server (6). Katakanlah empat (lebih mudah untuk ditempatkan di gambar, tetapi, tentu saja, ada beberapa jumlahnya). Jika server berada pada node yang berbeda, itu berarti bahwa beberapa kode berputar pada mereka semua, yang bertanggung jawab untuk memastikan bahwa node-node ini membentuk sebuah cluster dan, jika terjadi break, terhubung, saling mengenali satu sama lain.

Masih membutuhkan logika kode (2), yang sebenarnya tentang caching. Klien berinteraksi dengan kode ini melalui beberapa API. Kode klien (1) dapat berada dalam JVM yang sama, dan mengaksesnya melalui jaringan. Logika yang diimplementasikan di dalam adalah keputusan yang akan ditinggalkan objek dalam cache, yang akan dibuang. Kami menggunakan memori (3) untuk menyimpan cache, tetapi jika perlu, kami juga dapat menyimpan sebagian data pada disk (4).

Mari kita lihat di bagian mana beban akan terjadi. Sebenarnya, setiap panah dan setiap simpul akan dimuat. Pertama, antara kode klien dan api, jika itu adalah interaksi jaringan, penurunan permukaan bisa sangat terlihat. Kedua, dalam kerangka api itu sendiri - setelah ditimpa dengan logika yang kompleks, kita bisa lari ke CPU. Dan akan lebih baik jika logika tidak mendorong memori sekali lagi. Dan masih ada interaksi dengan sistem file - dalam versi yang biasa, serial / dipulihkan dan ditulis / dibaca.

Interaksi lebih lanjut dengan cluster. Kemungkinan besar, itu akan berada di sistem yang sama, tetapi bisa secara terpisah. Di sini, Anda juga perlu mempertimbangkan transfer data untuk itu, kecepatan serialisasi data dan interaksi antara cluster.

Sekarang, di satu sisi, kita dapat membayangkan "roda gigi apa yang akan berputar" dalam sistem cache ketika memproses permintaan dari kode kita, dan di sisi lain, kita dapat memperkirakan apa dan berapa banyak permintaan yang akan dihasilkan oleh kode kita pada sistem ini. Ini cukup untuk membuat pilihan yang kurang lebih bijaksana - untuk memilih sistem untuk use case kita.

Hazelcast

Mari kita lihat bagaimana dekomposisi ini berlaku untuk daftar kami. Misalnya, Hazelcast.

Untuk memasukkan / mengambil data dari Hazelcast, kode klien mengakses (1) api. Hz memungkinkan Anda untuk memulai server sebagai tertanam, dan dalam hal ini, mengakses api adalah panggilan metode di dalam JVM, Anda dapat membacanya secara gratis.

Untuk mengerjakan logika di (2), Hz bergantung pada hash dari array byte kunci serial - yaitu, serialisasi kunci akan terjadi dalam hal apa pun. Ini adalah biaya tak terelakkan untuk Hz.
Strategi penggusuran diterapkan dengan baik, tetapi untuk kasus-kasus khusus - Anda dapat menghubungkannya sendiri. Anda tidak perlu khawatir tentang bagian ini.

Penyimpanan (4) dapat dihubungkan. Baik. Interaksi (5) untuk embedded dapat dianggap instan. Pertukaran data antar node dalam cluster (6) - ya, benar. Ini berkontribusi pada ketahanan dengan mengorbankan kecepatan. Fitur Hz dari Near-cache memungkinkan menurunkan harga - data yang diterima dari node lain dari cluster akan di-cache.

Apa yang dapat dilakukan dalam kondisi seperti itu untuk meningkatkan kecepatan?

Misalnya, untuk menghindari serialisasi kunci pada (2), di atas Hazelcast, masukkan cache lain untuk data terpanas. Di Sportmaster, Caffeine dipilih untuk tujuan ini.

Untuk memutar di level (6), Hz menawarkan dua jenis penyimpanan: IMap dan ReplicatedMap.

Perlu dikatakan bagaimana Hazelcast masuk ke tumpukan teknologi Sportmaster.

Pada 2012, ketika kami mengerjakan pilot pertama dari situs masa depan, Hazelcast yang ternyata menjadi tautan pertama yang dikeluarkan mesin pencari. Kenalannya dimulai "pertama kali" - kami terkesan oleh fakta bahwa hanya dua jam kemudian, ketika kami memasukkan Hz ke dalam sistem, itu berhasil. Dan itu bekerja dengan baik. Sampai akhirnya kami menambahkan beberapa tes, kami senang. Dan pasokan semangat ini cukup untuk mengatasi kejutan yang dilontarkan Hz dari waktu ke waktu. Sekarang tim Sportmaster tidak punya alasan untuk menolak dari Hazelcast.

Tetapi argumen seperti "tautan pertama di mesin pencari" dan "HelloWorld yang dirakit dengan cepat", tentu saja, merupakan pengecualian dan fitur saat momen di mana pilihan itu terjadi. Tes-tes ini untuk sistem yang dipilih dimulai dengan rilis di prod, dan pada tahap ini Anda harus memperhatikan ketika memilih sistem apa pun, termasuk cache. Sebenarnya, dalam kasus kami, kami dapat mengatakan bahwa kami memilih Hazelcast secara kebetulan, tetapi kemudian ternyata kami memilih yang tepat.

Untuk produksi, ini jauh lebih penting: pemantauan, kegagalan pemrosesan pada masing-masing node, replikasi data, biaya penskalaan. Artinya, ada baiknya memperhatikan tugas-tugas yang akan muncul hanya ketika sistem didukung - ketika beban sepuluh kali lebih tinggi dari yang direncanakan, ketika kita secara tidak sengaja mengisi sesuatu ke arah yang salah, ketika Anda perlu meluncurkan versi baru dari kode, mengganti data dan melakukannya tanpa disadari untuk klien.

Untuk semua persyaratan ini, Hazelcast pasti cocok.

Bersambung

Tapi Hazelcast bukan obat mujarab. Pada 2017, kami memilih Hazelcast untuk cache di panel admin, hanya mengandalkan kesan baik dari pengalaman masa lalu. Ini memainkan peran penting dalam lelucon yang sangat jahat, itulah sebabnya kami berada dalam situasi yang sulit dan “heroik” keluar darinya selama 60 hari. Tetapi lebih lanjut tentang itu di bagian selanjutnya.

Sementara itu ... Selamat Kode Baru!

Bagaimana kami di Sportmaster memilih sistem caching. Bagian 1